Re: [boost] [Python] Fails for gcc-cygwin-3.4.4

From: David Abrahams (dave_at_[hidden])
Date: 2007-02-21 12:38:01

[ followups to the boost-build list, please ]

Roland Schwarz <roland.schwarz_at_[hidden]> 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