Re: feature wish for boost 1.32.1 or 1.33.0: pkg-config support

From: Larry Evans (cppljevans_at_[hidden])
Date: 2004-12-16 15:39:07

On 12/16/2004 02:46 AM, Andreas Pokorny wrote:
> On Wed, Dec 15, 2004 at 07:36:13PM -0700, Larry Evans 
<cppljevans_at_[hidden]> wrote:
[snip]

>>the idea is to record all the files and their versions used to run
>>some program. Of course when referencing a *.release.log file on
>>the rhs of a Jamfile dependency statement, the dependency should
>>only include files from the library, not those specific to the test
>>(e.g. for_each.cpp in the libs/mpl/test directory).

[snip]

> Could you explain how that helps to find the include and library
> directories of a boost package, in a matching version, on a foreign
> system?

It doesn't help find them, it just records what's in them
(once they're found, I guess). It's more a developer's tool
for a library rather than one for the user of that library
or "sublibrary" (e.g. boost/graph ). This is what prompted
my original post at:

http://lists.boost.org/MailArchives/boost/msg76550.php

where I said:

something that would *also* record the variants

I thought what I'd requested was similar enough to justify
a response.

Maybe a "use case" description would better explain the need.
Assume there are several parts to a current development.
Each part has test cases associated with it. After "furiously"
developing a subpart, I move development to the main part after
assuring my "boss" that the subpart has be tested and passed.
However, the development of the main part required modifcation to the
subpart. After several weeks (or months :( ) of development, the
main part works, which I proudly show to the boss, who suggests trying
one more input. I do and it fails due to the changes in the subpart
made during development of the main part. The boss, who needs to use
the subpart in another project, is now not to happy, especially since
I can't remember the versions of the files used in the subpart when it
passed the subpart's test. Having this information recorded in the
subpart.release.log would've mollified the boss.

This actually happened and prompted the first version of this
release.log feature.

> Or what needs to be done to integrate that into a small command
> line tool.

I used a bunch of perl scripts within a gnumake Makefile to do it.
used the output from gcc -MDD to record the dependencies and when a
release occurred, I'd take this information and ci all the dependent
files which had changed and record the versions and files in the
release.log file. I was hoping to do something similar with bjam's
extension mechanism ( http://www.boost.org/doc/html/bbv2/extender.html
), but I haven't gotten around to it :(

[snip]