Boost logo

Boost-Build :

From: Matthew Herrmann (matthew.herrmann_at_[hidden])
Date: 2006-03-02 18:49:07

Hi Volodya,

I'm on the digest so so the attachment was scrubbed unfortunately and I
couldn't get it from the archives. I did conduct some more tests on my end
and have pared back the code needed to do the check. I also tested the
<dependency> against the latest trunk versions and saw the same behaviour.

Attached is the minimal example I could produce. I got the same behaviour on
the CVS trunk source and the last stable boost release.

...found 9 targets...
...updating 2 targets...
gcc.compile.c++ bin/gcc/debug/test.o

    "g++" -Wall -ftemplate-depth-100 -O0 -fno-inline -g -fPIC -c -o
"bin/gcc/debug/test.o" "test.cpp" bin/gcc/debug/

    "g++" -o "bin/gcc/debug/" -Wl,-h -Wl, -shared
"bin/gcc/debug/test.o" -g

...updated 2 targets...

I found that by listing the check script as one of the first sources, it will
in general be checked before others and will prevent building the dependent
sources. It would be good to find a way to do this reliably in boost build,
as it's essentially a pre-build step, and is essential if trying to glue
together third-party makefiles and bjam without a wrapper shell script.

On further thought, installation checks that I am doing to ensure users have
installed required prerequisites can be done simply by inserting dummy
<dependency> tags into the requirements:

alias mylib
    : <dependency>/usr/local/lib/mylib
    : <include>...

The only flaw is that the user doesn't get a customisable diagnostic. Using
this approach, other more complex checks or pre-build steps could possibly be
added with the ability to run scripts at dependency generation time:

alias mylib
     : <dependency>`src/make` <-- not valid syntax, just a suggestion

Thanks for your help,

Best Regards,

Date: Tue, 28 Feb 2006 10:18:16 +0300
From: Vladimir Prus <ghost_at_[hidden]>
Subject: Re: [Boost-build] "null" output file type
On Tuesday 28 February 2006 00:59, Matthew Herrmann wrote:

> I am using OBJ as an output as it is a valid source for a library, and this
> was how I could 'wedge' in the test script execution to the compilation
> dependency model. If I move the .check file to being a dependency
> requirement instead of a source, bjam doesn't call my script.

Can you take a look at the attached? When I run

  bjam -n mylib

there, the configure script is executed just fine.

> With the
> current approach I am using, the script is being called, but unfortunately
> does not prevent other sources such as the CPP files from being compiled on
> failure,

Yes, the <dependency> applies onto to top-level targets of 'lib', the object
files will be still produced.

- Volodya

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at