[ followups to the boost-build list, please ] Roland Schwarz <roland.schwarz@chello.at> writes:
David Abrahams wrote:
Boost.Python has always worked with Cygwin GCC, but if you don't use -mno-cygwin, you have to use the cygwin version of Python (the one installed when you select it in the Cygwin installer). Currently the Python support in BBv2 on Windows and Cygwin is a total mess, which may explain why it isn't working for you. I'm trying to fix that up now.
IMHO -mno-cygwin _is_ _not_ cygwin, but mingw!
Whatever; when I say "Cygwin GCC" I mean the build of GCC you get when you install Cygwin.
Currently the cygwin/mingw support in bbv2 also is a mess. Python
You mean Boost.Python?
only builds on top of this. :-(
On top of what?
Open questions:
1) should cygwin / mingw tag be a *) part of the toolset name like in intel-win intel-linux
No. win/linux is not really part of the toolset name; it's a subfeature of toolset=intel. However, that role should more properly be played by the "target-os" feature IMO.
*) part of the version e.g. gcc-3.4.4-cygwin *) be an independant feature (like is now)
2) Shouldn't cygwin/mingw rather be modelled as a stdlib property? stdlib=native/cygwin/mingw
No; it has almost nothing to do with the C++ standard library.
3) We will need canonical toolset names for use in Jamfile's. The current situation where users can invent arbitrary version-names defeats this.
Volodya and I discussed this just now. We agree with you about point 3. Here's what we came up with, to address this issue. * -mno-cygwin really should be controlled by target-os. Cygwin and Win32 are best viewed as different OSes, since Cygwin provides a POSIX API. When using a version of Cygwin GCC that supports -mno-cygwin, by default it should target the host OS. That is, when building from a cygwin bjam, the default would be not to pass -mno-cygwin, and when building from a Win32 bjam, the default would be to pass -mno-cygwin. In either case, the default would be overridable by passing target-os=... * If we drop the ability to arbitrarily choose a version string, we need a way to identify different configurations of a toolset that may have the same version number. For example: - You may have both Cygwin and MinGW gcc 3.4 installed - You may want to experiment with a special gcc build having C++0x features - You may need a convenient way to identify a special configuration of an existing toolset. The solution we came up with is to add an optional argument to "using" that allows you to create a special toolset subfeature on-the-fly, something like: using gcc : 3.4 : /usr/local/conceptgcc/bin/g++ : conceptgcc ; This feature could then also be used to identify the toolset on the command-line, something like: bjam toolset=conceptgcc -- Dave Abrahams Boost Consulting www.boost-consulting.com