target-os not always set up?

[Dave Abrahams]

In order to get the right suffix on python extensions built for cygwin, it seems to me that the following ought to have been enough:

type.set-generated-target-suffix PYTHON_EXTENSION : : so ;
type.set-generated-target-suffix PYTHON_EXTENSION : <target-os>windows : pyd ;
type.set-generated-target-suffix PYTHON_EXTENSION : <target-os>cygwin : dll ;

but if I do that, cygwin PYTHON_EXTENSIONs end up with a .so extension

Instead, I had to do:

type.set-generated-target-suffix PYTHON_EXTENSION : : so ;
type.set-generated-target-suffix PYTHON_EXTENSION : <os>windows : pyd ;
type.set-generated-target-suffix PYTHON_EXTENSION : <os>cygwin : dll ;
type.set-generated-target-suffix PYTHON_EXTENSION : <os>cygwin <target-os>windows : pyd ;
type.set-generated-target-suffix PYTHON_EXTENSION : <os>windows <target-os>cygwin : dll ;

[grafik]

Note, the target-os feature is declared as propagated and link-incompatible, with an explicit default value. So as far as I understand the feature mechanics it's not a problem with the declaration, i.e. it's not an optional feature.

[Dave Abrahams]

This is doubly weird because there is no <os> feature AFAICT; the proper selection would have been <host-os>

[Dave Abrahams]

OK, there is an <os> feature, but it has the same format as the result of [ os.name ]. As it turns out, however, [ default-host-os] is returning "unix" from cygwin builds of bjam.

[grafik]

So the problem is that [ os.name ] returns something other than "cygwin" for the cygwin built bjam? I say this because the default-host-os logic is to try and match that name if it's in the known list. What does os.name return for a cygwin bjam?

[Dave Abrahams]

Fixed locally and I will check it in, but please see #124