Hi,
I figured out how to make scons work with cython and C++ code and I thought
I'd share it here in case other people are interested in the solution.
It was pretty
simple. All I had to do was to add the following three lines to Dag's
original SConstruct
file cited below:
env.Replace(CYTHONFLAGS=['--cplus'])
env.Replace(CYTHONCFILESUFFIX='.cpp')
env.Replace(CXXFILESUFFIX='.cpp')
Kilian
On Mon, Aug 23, 2010 at 11:02 AM, killian koepsell <koeps...@gmail.com> wrote:
> Hi,
>
> I just found this thread which is a couple of months old.
>
> I would like to use scons with cython and C++ and the email below
> indicates that this is possible.
> Has there been any progress on this? Where can I find an example how
> to specify C++ as the language in scons?
>
> Thanks,
> Kilian
>
> On Wed, Oct 21, 2009 at 1:56 AM, Dag Sverre Seljebotn
> <da...@student.matnat.uio.no> wrote:
>> OK, as requested I've uploaded the scons scripts I use. They're mostly
>> taken from David Cournapeau's numscons, but works with normal scons.
>> I'll start with a small user guide and then go to the TODO-list:
>>
>> 1) Copy Tools/site_scons to your project dir (sits in cython-devel hg trunk)
>> 2) Make SConstruct (not the nicest example, but...):
>>
>> env = Environment(PYEXT_USE_DISTUTILS=True)
>> # The above flag makes Python extensions look up compiler flags and
>> include paths etc. from distutils)
>> env.Tool("pyext")
>> env.Tool("cython")
>> env.Append(PYEXTINCPATH=[numpy.get_include()])
>> # Override location of Cython and set some flags
>> env.Replace(CYTHON="python /uio/arkimedes/s07/dagss/cython/devel/cython.py",
>> CYTHONFLAGS=['-a', '-I/uio/arkimedes/s07/dagss/cmb/cmblib'])
>>
>> # Specify an extension to be compiled
>> env.PythonExtension('mapdatautils', ['mapdatautils.pyx'])
>>
>> # A more complicated example linking in Fortran code and libraries using
>> ifort.
>> # ifort must then be used to finally link the extension...
>> env2 = env.Environment(F90="ifort")
>> # Also omit -O2 and add Cython refnanny. This is hacky, see TODO.
>> env2.Replace(PYEXTCFLAGS=['-fno-strict-aliasing', '-DNDEBUG', '-Wall',
>> '-fwrapv', '-g', '-Wstrict-prototypes',
>> '-DCYTHON_REFNANNY'],
>> objs += env2.SharedObject(['comp_normalised_Plm.f90'])
>> objs += env2.PythonObject(['healpix.pyx']) # note the use of PythonObject
>>
>> env2.PythonExtension('healpix', objs,
>> LIBS=['healpix', 'cfitsio'],
>> PYEXTLINKFLAGS=['-shared', '-openmp'],
>> PYEXTLINK='$F90')
>>
>>
>> OK, on to the TODO-list:
>> - Currently the choice for extension module compilation is between
>> PYEXT_USE_DISTUTILS and a set of sensible defaults. Instead I think one
>> should be given the choice of a PYTHON to use, and then launch that
>> PYTHON executable to fetch distutils information.
>> - It should be possible to avoid the replacement of PYEXTCFLAGS above,
>> perhaps by seperating between optional (-O2) and non-optional
>> (-fno-strict-aliasing) flags and put them in seperate vars?
>> - The support for C++-generated Cython code is too weak (one has to
>> specify it in two seperate vars...not shown above)
>> - Dependency tracking (none at all for pyx files currently)
>> - I'm uncertain about having to specify PYEXT_USE_DISTUTILS (or, in
>> time, PYTHON) prior to loading the pyext tool...is this normal? Or
>> should the distutils settings be looked up at compilation time rather
>> than configuration time? (But then one wouldn't be able to dynamically
>> modify e.g. PYEXTCFLAGS, only "leave it unset to be filled in"...).
>>
>> Help and input appreciated, I know way too little scons to pull this off
>> the right way! But it does what I needed to for, and is already a lot
>> better than jumping between my shell scripts, makefiles and setup.py's...
>>
>> Dag Sverre
>> _______________________________________________
>> Cython-dev mailing list
>> Cython-dev@codespeak.net
>> http://codespeak.net/mailman/listinfo/cython-dev
>>
>
_______________________________________________
Cython-dev mailing list
Cython-dev@codespeak.net
http://codespeak.net/mailman/listinfo/cython-dev
