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

From: Andreas Pokorny (diemumiee_at_[hidden])
Date: 2004-12-16 04:46:28

On Wed, Dec 15, 2004 at 07:36:13PM -0700, Larry Evans <cppljevans_at_[hidden]> wrote:
> 
> On 12/15/2004 04:49 PM, Larry Evans wrote:
> [snip]
> > 
> > so the above dependency for version 1.1.3 of mpl could be expressed:
> > 
> > dependency mpl
> > : boost-root.ln/release/gcc/debug/libs/mpl/test.release.log.~1.1.3~
> > 
> > where, there would be a versioned test.log file with entries
> > as described in */msg76550.php for productions.release.log.
> 
> I realized that maybe "version 1.1.3 of mpl" doesn't make much sense.
> Well what I meant was the version of all the mpl files used
> to run whatever tests were in boost-root.ln/libs/mpl/test. For
> example, the developer makes some changes and then runs the
> tests to verify their correctness. If they pass, he decides
> to create a mpl release to signify that the current version of
> the mpl files pass the tests in libs/mpl/test. These mpl
> files used to run the test and their versions are recorded
> in:
> boost-root.ln/release/gcc/debug/libs/mpl/test.release.log.~1.1.3~
> It would be clearer if an actual test in the directory were used.
> For example, instead of test.release.log, the filename could
> consist of the Jamfile and the target in the Jamfile. For instance:
> 
> boost-root.ln/release/gcc/debug/libs/mpl/test/Jamfile.for_each.release.log
> 
> Ok, the naming convention needs work, but 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).
> 
> Please let me know if that's unclear.

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? Or what needs to be done to integrate that into a small command
line tool.

I now believe that my formulation in the first mail was too vague. I was
thinking about a small tool, that prints versions of the installed boost
libraries, directories, librarynames or better: linker parameters that
need to be appended to the compiler command to build an application that
uses boost. This should also allow installing several versions of boost.

Suggested parameters:
-toolset=<t> parameters will be formated to work with t
-min-version=<n.n.n> 
-max-version=<n.n.n> 
-libraries=<l1>,<l2>.. checks for listed libraries / prints parameters
for printed libraries
-lflags prints linker flags or returns a fixed error message,
-cflags prints compiler flags or returns a fixed error message
-debug linker flags will use debug library
-static linker flags will use the static libraries
-mt flags for multi and single threading model
-st
-existance checks if required flags can be met

The application should also exit with a status that either indicates
success or failure.

Regards,
Andreas Pokorny

 --r5Pyd7+fXNt84Ff3 Content-Type: application/pgp-signature
Content-Disposition: inline

[Attachment content not displayed.] --r5Pyd7+fXNt84Ff3--