Re: Fails for gcc-cygwin-3.4.4

[ followups to the boost-build list, please ]

Roland Schwarz <roland.schwarzchello.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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

David Abrahams wrote:
> [ followups to the boost-build list, please ]
> 
> Roland Schwarz <roland.schwarzchello.at> writes:

>>  only builds on top of this. :-(
> 
> On top of what?

Oh sorry, perhaps my English is not good enough. What I
tried to say:

1) I said cygwin/mingw support in Boost.Build v2 is (uhm)
sub-optimal.

2) The previous poster (I think it was you) said that
"Python support in 
BBv2 on Windows and Cygwin is a total mess".

3) My conclusion was that 2) only builds on top of this (
where this is 
point 1) ).


>> 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.

Hmm, at least I do see
intel.jam
intel-linux.jam
intel-win.jam

files in the tool directory, where intel alone just
automagically 
forwards, depending on the OS. But I might just
misunderstand what a 
toolset name really is.

>> 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.

I guessed that. It indeed is the runtime lib which is more
kind of 
target OS. (property rtlib=native,cygwin,mingw ? But target
OS I believe 
is better.)

> 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.

This sounds very reasonable to me.

>    That is,
>    when building from a cygwin bjam, the default would
be not to pass
>    -mno-cygwin, and when building from a Win32 bjam, 

Sorry don't understand. What exactly do you mean by a
"cygwin bjam" or 
"win32 bjam"?

What would be the default when I invoke from CMD.EXE (I
guess win32 
bjam, but could also be cygwin bjam) using
C:Cygwinbing++.exe?

> the default would
>    be to pass -mno-cygwin.  In either case, the default
would be
>    overridable by passing target-os=...

Hmm, would this allow e.g

   bjam toolset=gcc-3.4.4-cygwin,gcc-3.4.4 stage

if I want both cygwin and "native" 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:
[snipped examples]
>   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
> 

We need something

1) library authors can use to mark up in
explicit-failures-markup.xml
2) library authors can use in Jamfiles.

For 1) a kind of simple pattern matching is available. e.g.
gcc-cygwin*
(Will the subfeature be visible in this context?)

For 2) a similar substring matching sometimes looks
advantageous. But I 
do not know if this just would be kind of opening Pandoras
box.

Roland

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build