From: Hugo Duncan (hugoduncan_at_[hidden])
Date: 2007-10-07 10:39:27
Vladimir Prus wrote:
> Hugo Duncan wrote:
>> Annoyance number two is that it seems very fragile. Eaxmples: the
>> reliabilty of cross (sub-)project dependencies seems very sensitive to
>> exact way they are specified, and I have had to delete precompiled
>> files several times because they were not be correctly regenerated.
> Can you explain this in more detail?
The problems with precompiled headers I have not been able to reproduce
>> Apart from that I have tried several times to extend boost.build, for
>> example to run wix, or to build fortran, or to generate lib files from
>> dll's. My experience is that it is difficult to extend BB without being
>> intimately familiar with its implementation. Every time I have failed
>> imlement all the functionality that I was after, so I have given up on
>> doing this, and resort to makefiles for anything that isn't directly
>> supported by BB.
> Again, it would be nice if every time you run into such roadblock, you
> report it.
> At the very least, the extender's manual surely has to be augmented with
> new information,
> but what information, exactly, is more like a question to users.
Basic customisation works very well. Defining tools and registering
generators is simple. Anthing more, such as the example in the manual's
"Custom generator classes" section, requires use of functions like
"generators.construct", "construct-result", or "virtual-target.traverse"
that are not really documented at all. I would say that this part of the
extender interface is thus poorly defined at the moment - it simply uses
To continue an example from above - to create a lib file from a dll I need
to run the dumpbin and lib tools for msvc. The msvc toolset defines the
paths to these tools, but I haven't worked out how to access that
information. The script I use at the moment is attached, and is used to
build lapack for use with ublas.
Thanks for your reply and all your work on Boost Build,
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