Robert wrote:
> .pyxbld/.pyxdep mechanism was already in 0.11.1 and long before
> probably and allowed already to define a specific Extension class
> (to tell about other .c files, dependencies etc).
>
> I just added the setup_args, to allow crucial things like --debug,
> --inplace, --compiler and all ... which one might have special in
> pyximport mode too: its typically a debug situation.
Ahh ok. Speaks about how little I really know about pyximport.
>> One thing I was thinking about is embedding the information in the pyx
>> file itself. Something like this perhaps:
>>
>> from cython import pyxbuild
>> pyxbuild.include_path = [...]
>> pyxbuild.libraries = [...]
>>
>> .. rest of pyx file...
>>
>> What do you think?
>
>
> If the pyx meta importer must parse the .pyx source code (before
> he can even check the dependencies), it is very slow.
You're likely right. The idea would still hold for something like
special comments at the top of the pyx file or similar (only allowed on
the first few lines).
>
> Also including such special build info into the source file is a
> questionable intermix.
> Consider, you give the source file to somebody else with different
> environment ...
Well, in that case I'd say one should use a proper build system. Anyway,
it seems like .pyxbld is here to stay so that would keep being an
alternative.
All I'm looking for is a way to make the overhead of getting Cython code
up and running lower than it is today.
Anyway, this needn't be discussed before somebody is ready to do it,
which I'm not, now that I see that pyxbld is already there :-)
> Questioning its format:
>
> It could be more *like* a setup.py. But it cannot not just be a
> normal free one.
> Because: pyximport must inject/weave in the pyximport.install()
> args, the .pyxdep, must be able to tell separate default paths
> (to not necessarily affect the regular build system). it must
> direct/know location/take over the produced files; reload_support
> mode, etc.
>
> Thus pre-defining a single setup() call more or less (but not
> executing directly) is perhaps the "simple case", the task of the
> .pyxbld.
>
> so I think a make_extension and make_setup_args inside the .pyxbld
> is principally quite the right thing. sb who knows to write a
> setup.py/setup(), will face quite the same format here - just
> canalized.
>
> Also, because its imported (and makeXX funktions are called), one
> can still let execute *any* python code (before the build as of
> now only). So its very flexible.
>
> The current hierarchy of usage (and quite the evolution history):
> 1) pyximport.install() args - general behavior
> 2) .pyxdep - simple, only dependencies
> 3) .pyxbld/make_extension - other .c files...; can
> extend/override/replace (2) and (1)
> 4) NEW .pyxbld/make_setup_args - alter higher options; can
> extend/override/replace (3),(2),(1)
> 5) arbitrary effective python code in .pyxbld globally or
> in the makeXX functions
>
> I do not really have a better principal idea, and the mechanism is
> flexibile and can be further evolved (e.g. a function called back
> at compile/post build time or so). details could be straightened out.
>
>
> If one is concerned about not doubling build/dependency info:
> The .pyxbld file can be used/included right *from* a setup.py
> script because of the compatibility, like:
>
> #setup-cyex.py --------------------------------------
>
>
> from distutils.core import setup
> from Cython.Distutils import build_ext
> execfile("cyex.pyxbld")
>
> setup(
> cmdclass = {'build_ext': build_ext},
> ext_modules = [make_ext('cyex','cyex.pyx')],
> ##**make_setup_args()
> )
>
>
> #cyex.pyxbld ----------------------------------------
> def make_ext(modname, pyxfilename):
> from distutils.extension import Extension
> return Extension(name = modname,
> sources=[pyxfilename, 'hello.c'],
> depends=['hello.h'],
> )
>
> def make_setup_args():
> # args like for distutils Distribution/setup()
> return dict(
> script_args=[
> ##"--compiler=mingw32",
> ##"--verbose",
> "--inplace",
> "--debug",
> ])
> -------------------------------------------------------
>
>
> thats maybe even natural to have the specific build/dep info for
> each .pyx right next in the .pyxbld . A (quite constant) setup.py
> for the general distutils project integration...
>
>
> Robert
>
>
>
>
>
>
>
> _______________________________________________
> Cython-dev mailing list
> [email protected]
> http://codespeak.net/mailman/listinfo/cython-dev
--
Dag Sverre
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
