From: Reece Dunn (msclrhd_at_[hidden])
Date: 2006-06-13 16:55:06
Chad Carr wrote:
> > Chad Carr wrote:
> >> I am attempting to build a pam module that works on OS X and cannot
> >> figure out for the life of me how to get the -bundle option to link.dll
> >> in the darwin toolset. Indeed, the -dynamiclib option appears to be
> >> hardcoded in the toolset,
> > You will need to modify the darwin toolset:
> Thanks for the very detailed description. I have done the needful and
> produced the attached patch. It is exactly as you said except that I
> changed the feature values to true and false (defaulting to false) to
> more closely match the core boost build features and the feature name to
> <bundle> since it is likely that the Jamfile writer will end up writing
> a line like this anyway:
> lib foo : foo.c : <toolset>darwin:<bundle>true ;
I'm glad that it worked :). The reason I chose mac-bundle was to avoid a
possible conflict with features imported from other toolsets. Unlikely, but
still, bundle is fairly generic.
> Additionally, I did not make the feature propagated. A library that
> uses -bundle seems to be the top of the chain, that is nothing else can
> link to it using normal means.
That makes sense. My only defense is that I copied it from a feature I
had from msvc :).
> I had assumed that I could get what I needed by modifying the darwin
> toolset (I had pinpointed the problem quite a while ago). First
> question: is it normal to need to override core toolset functionality?
It all depends on what you are trying to do. It should be possible in most
cases to add the features to user-config.jam, but things get messy (and
is untested :)):
feature fancy-darwin-feature : no-thanks okay ;
# should really be in darwin.jam
flags darwin.compile : <toolset>darwin/<fancy-darwin-feature>okay : -fancy ;
However, I did have:
feature char-set : narrow multibyte wide : composite ;
feature.compose <char-set>wide : <define>UNICODE <define>_UNICODE ;
in my user-config.jam before I moved it into my local BBv2 codebase. If
the toolset does not have support for a flag you need, you will end up
hacking that toolset. I have modified msvc.jam locally (available on my website
www.reece-dunn.co.uk) that adds C++/CLI, experimental WinCe and additional
compiler options to the toolset.
> After all, I am writing a piece of software for public release (probably
> a few months from now) and planned to depend on boost build v2 for
> distribution. With this minor exception, so far, it has proved to be a
> vastly superior alternative to autotools. I am a happy camper.
:) I am a huge fan of BBv2 - I use it at home for all the C++ development I do.
> Second question: if override is normal, then what is the recommended way
> to distribute the changes? I.e. should I patch the user's darwin.jam in
> my configure script, distribute a totally new file (both of these seem
> horribly rude), embed the entire boost build system in my project (du
> -sh shows 3.6 M, plus I am pretty sure that is not what is intended), or
> somehow override the darwin.jam toolset with my own file?
One possibility is to require a fixed version of BBv2, for example v1.01
of your project uses BBv2 from Boost 1.33.1 (or BBv2 m10). That way
you could use the patch approach, distributing that as part of your
release. That way you don't get the problem of patches failing to apply.
Then, when you release the next version, you can update the BBv2
> The last
> option certainly seems like the best, but I cannot for the life of me
> figure out how to create a file darwin.jam in my project that can be
> found by the toolset.using rule instead of the default in the tools
> directory. I have read quite a bit of documentation and cannot seem to
> find instructions anywhere. No problem looking at source, mind you, but
> I have done a bit of that as well to no avail.
I think that BBv2 scans the home directory (where the user-config.jam
file can be placed) when searching for toolsets. This is one of the things
about BBv2 where functionality is lacking: I cannot provide a foo.jam in
a subproject, then import that locally - or at least I don't know how to
yet! That is, it would be difficult moving the bash build process to BBv2 :)!
Vlladimir Prus will be able to answer this better than I can as he knows
more about how the BBv2 internals work.
> Third question: if it is not normal, and the functionality should be
> included in the base boost build system, I'd like to kindly submit the
> patch attached for your review. I notice that the v1 system had similar
> functionality (although much more complex; I can only assume that this
> is a function of the much simpler v2 syntax).
V2 simplifies things over its V1 predecessor. However, there are some
areas where V1 has more functionality. One example is that V1 gcc has
support for passing the CPU/architecture flags to the compiler.
Patches are always welcome. These are usually applied by either Vladimir
Prus (who has done a lot of work on V2), Rene Rivera (who is more
focused toward BJam, but still contributes to BBv2), Dave Abrahams
and a few others.
> Additionally, I need to answer the second question anyway to cover
> distribution until such time as the patch becomes available in general
I think the method that you choose will depend on a lot of factors,
including who your users are. For example, I have a branch of BBv2
that is just 814KB and the BJam sources are 756KB! It is feasible to
distribute the following:
or use a Boost.Build-only distribution from sourceforge. NOTE: My
distribution above does not include the documentation or tests, but
the sourceforge version will.
Express yourself instantly with MSN Messenger! Download today it's FREE!
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