Re: [Visualpython-users] History and Status?

[Jonathan B. <jbr...@ea...>]

On Tue, 2003-02-18 at 16:34, Arthur wrote:
> It terms of concrete effort, I will be pursuing the extension to the
> setup.py for VPython I did, so that it will be workable with Linux. Other
> than my own learning curve to refamiliarize myself with certain Linux
> issues, should not be a big deal.  As Bruce notes, the actual Linux setup.py
> is essentially  already there - its really just a matter of testing for
> platform and branching appropriately.
> 
> Should be able to get it to be basically functional, with the place of docs,
> demso somewhere - as a draft - pending more discussion.
> 
> But the iterator thingy (technical term) issue is on my mind.
> 
> I am working with a recent Linux install, therefore gcc3.xx.
> 
> Am I correct in assuming that the fix to the CXX file needed to compile on
> gcc > 3 does not break anything if compiling under a gcc < 3.  Which would
> raise the question why it was there at all.  There is probably a way to test
> for gcc version and fork accordingly, but I don't know if its necessary.

Unfortunately, No.  Most GCC < 3 are broken by the current setup. 
Namely the stock versions distributed with RH7 and Debian woody (at the
minimum).  It's not as simple as testing for __GNUC__ < 3, because at
least one of the 2.95 builds supported only the ISO version, and would
subsequently fail.  Most G++ 3.x distributions' verson of libstdc++
support both the old random_access_iterator<> and newer iterator<>.  The
problem is that Apple distributes their G++ with a C++ standard library
that is not backwards compatable in this respect.

In the Great ISO Migration, some older distributions are only partially
in compliance.  Most current distributions are fully compliant or nearly
so, and are also backwards-compatable (stock g++3.2.x with corrisponding
libstdc++).  A handful of current distributions are fully or nearly
fully ISO compliant and are NOT backwards compatable (Apple special
distro).  Ironically, the last group is the one causing causing us the
trouble.

Is it possible to run a shell command from within setup.py, and capture
the return value to set a CXXFLAG?  If so, then a solution could look
like this:

Provide a file named iterator_traits_test.cpp:
--------iterator_traits_test.cpp--------------
#include <iterator>

std::iterator< std::random_access_iterator_tag, int, int> test;

----------------------------------------------
From within setup.py, shell execute
g++ -c iterator_traits_test.cpp
If it returns 0, add -DSTL_HAS_ITERATOR_TRAITS to CXXFLAGS.

This would work in conjunction with removing the default definition in
CXX_Config.h, and changing the conditional within that file to #ifdef
vice #if.  It would also virtually require using setup.py to build. 
Everything is a trade-off.

OTOH, if what I described is possible for the iterator thing, than it
could be used to capture all of our platform differences with only one
setup.py.

-Jonathan