Python/Cygwin support in v2

1. cygwin-condition: there's a comment now, but it's still
quite
   unclear.  How should this argument be used?  We need an
example.

   I'm beginning to think it should look something like:

         <toolset>gcc

   The comment says, "should be a set of properties
which are present
   when we're building with cygwin gcc," but (if my
theory above is
   correct) that fails to indicate the primary
distinguishing feature
   of the argument, which is that it must identify the
cygwin-gcc
   toolset.

2. Also the comment says: "This argument is not used
yet," but it
   clearly /is/ used.  Code branches are followed based on
its
   value.

3. The logic in this file that is used when the cygwin
branch is
   followed seems to have been copy/pasted from the v1
python support,
   with all kinds of ends left dangling.  For example, what
do all the
   CYGWIN_PYTHON_DEBUG_* variable settings do?  Nothing
AFAICT.
 
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

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

On Monday 11 December 2006 02:34, David Abrahams wrote:
> 
> 1. cygwin-condition: there's a comment now, but it's
still quite
>    unclear.  How should this argument be used?  We need
an example.
> 
>    I'm beginning to think it should look something
like:
> 
>          <toolset>gcc
> 
>    The comment says, "should be a set of
properties which are present
>    when we're building with cygwin gcc," but (if
my theory above is
>    correct) that fails to indicate the primary
distinguishing feature
>    of the argument, which is that it must identify the
cygwin-gcc
>    toolset.

Ideally, the purpose of this argument is to be able to
configure several versions
of python, and use a specific version only when specific
properties are in build properties.
 
> 2. Also the comment says: "This argument is not
used yet," but it
>    clearly /is/ used.  Code branches are followed based
on its
>    value.

That comment is not longer occurate.


> 3. The logic in this file that is used when the cygwin
branch is
>    followed seems to have been copy/pasted from the v1
python support,
>    with all kinds of ends left dangling.  For example,
what do all the
>    CYGWIN_PYTHON_DEBUG_* variable settings do?  Nothing
AFAICT.

Yeah, looks like cygwin support was never ported, because I
don't have
cygwin to test anything. I think there are two possible
issues:

1. We want to be able to configure several versions of
python -- cygwin python,
msvc python, maybe mingw python. If that's needed, then
declarations of all targets
in init-nt should include condition. Also:

        flags python.capture-output PYTHON : $(interpreter)
;

should become:

        flags python.capture-output PYTHON $(condition:J=/)
: $(interpreter) ;

2. If we need cygwin-specific configuration logic we need to
know when
cygwin python is initialized. Perhaps new value of 'flavour'
feature -- 'cygwin',
can be used. So, for

	python 2.3 : /whatever : : :
<toolset:gcc-flavour>cygwin ;

we'll know that cygwin python is initialized and adjust
configuration code.

Does this help?

- Volodya




- Volodya

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