From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-08-29 02:34:37
I'm at last got to this email of yours... but better late, then never.
Christopher Currie wrote:
> > Now back to Darwin :-) Your toolset is fine, but I have a question.
> > Should this really be a separate toolset, or just some conditional logic
> > in gcc.jam? Does it make sense to use both unmodifed gcc and darwin
> > toolset in OSX? If so, then it's better be separate toolset. In other
> > case, I'm not sure. What do you think?
> I created a separate darwin toolset for two reasons:
> 1. That's the way it was done for BBv1, so when we migrate Boost it
> would be consistent
> 2. The MacOS linker is quite a bit different than any other linker.
> Certain flags that are supported by the GNU linker and other UNIX-like
> linkers (such as -Bstatic and -Bdynamic to control library linkage) are
> not supported by the MacOS linker.
Ok, the points are reasonable and it's hard to argue without experience.
I certainly would not like the V1 situation where almost every variantion is a
new toolset (like msvc-stlport), but in this case I've no strong opinion.
> I figured it was simpler and cleaner to have the Darwin toolset inherit
> from GCC, rather than have lots of conditional compilation everywhere.
> I agree it would be convenient if at some point we could detect MacOS in
> the GCC toolset and then do the right thing. Is there, perhaps, value in
> separating compiler toolsets from linker toolsets? An alternative could
> be having the GCC toolset import the darwin toolset, and somehow make it
> the default if it detects MacOS.
If darwin remains the only toolset which need such special things, it's
probably left as is. Otherwise, we'd need to consider better ways.
And now for the most pleasant part. Your darwin toolset is comitted to CVS.
I've made only one tweak: added the link to the email of yours that I'm
responding now, for future reference.
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