From: David Abrahams (dave_at_[hidden])
Date: 2002-11-29 17:58:24
"Jørn Jensen" <jornj_at_[hidden]> writes:
> Hello Dave,
> I sent a question like this to the jamboost archive which I subscribe too.
> But I never got any replies and thought I was ignored for asking stupid
> questions. So I gave up on the whole issue for a while, until I saw the
> light today when I understood how <linkflags>, <library-path> and
> <find-library> actually work. They modify variables..
> Then, an hour later, I scan some google searches and find that you answered
> on my original question (me aka jornj2001_at_[hidden]). I never got that mail,
> and I have not been able to trace it in my quite big mail log.
I don't know why this didn't go to the Jamboost list, but since it
seems to be entirely devoid of nontechnical content I don't see a
reason not to copy it there...
> I wrote:
>>> My apologies if this is obvious, but I suspect there is a bug in the
>>> current jamboost, boost_1_29_0, on linux with gcc. Or with the
>>> documentation that specifies that I should use LINKLIBS.
>> Which documentation tells you to do that?
> I have not been able to find the documentation that referred to
> LINKLIBS. And at this point I can't remember any of it. :-( I have
> a lot of links in my bookmark list with references to mail archives
> for Jam/MR, various Jambases and Boost Build System. Sorry about
> that. At the time I wrote it, I obviously thought I had seen a
> reference to it somewhere. And now I am unable to find
> it. Embarassing, but I cannot find it anymore.
Maybe in the regular Jam/MR Jambase documentation. Anyway, Boost.Build
basically doesn't use any of the Jambase idioms.
> Anyway, thank you for your answer, I only wish it had somehow reached me
> earlier. Heh.
> My problem when reading the BJam documentation on the net is that I
> know how to do it with 'make', and I had a hard time understanding
> 'how to accomplish X' in Jam. Some of the documentation is more
> list-oriented than problem-oriented. Features are listed, but not
> how to solve problems, which was my angle. Of course, it could be
> that I was half blind by previous misconceptions of 'how things
> worked'. The differences between Jam and BJam (different rule names
> etc.) was also quite confusing. The examples that are provided are
> all quite straight forward, assuming you have all your files within
> the same build system and in a relatively sane directory structure.
> Unfortunately, I don't :-)
> What I like about BJam is that it is very easy to specify how to
> build a library or a dll and get all the platform specific out. I
> also like the optimistic dependency system that doesn't break if the
> header file is gone.
> I have been able to convert one of my bigger Makefiles into a
> Jamfile, and it looks good. I have not modified any of the Jambase
> files and have added no new rules to accomplish it. This is good.
> My three next quests are:
> * Figuring out how I can make the existing make (we have a pretty
> big system here) can be made to interface with files made with
> bjam. This probably involves installing the files into a location
> that can be reached by our existing system without too much grist. I
> read one mailing that directed the questioner to have a look at the
> stage keyword.
> * Experiment more with the 'run' rule in testing.jam and figure out
> why I cannot specify something like this:
> run FooTest.cpp <dll>Foo. So far I have not been able to make the
> FooTest.test target link with the libFoo.so at all, it is just
Yeah, we seem to be having the same problem in the Boost.Python
embedding test. I've asked Rene, who's been maintaining this part of
Boost.Build v1, to look at it.
> * Somehow justify the time I have spent figuring this out. :-)
Gee, sorry ;-(
If you want to make it better, you could contribute a Wiki page on
You might look here:
-- David Abrahams dave_at_[hidden] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk