Dag Sverre Seljebotn wrote:
> Robert wrote:
>> 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 :-)
yes, special comments (a new language) would also require the
person to lookup the docs for an example. And there he can as well
read about .pyxbld/def make_ext().." .. Perhaps just a matter of
convention and a good doc string
>
>> Questioning its format:
>>
>> It could be more *like* a setup.py. But it cannot not just be a
>> normal free one.... Thus pre-defining a single setup() call more or less
>> (but not
>> ...
>> 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",
>> ])
>> -------------------------------------------------------
or: the cyex.pyxbld (with if '__main__'...setup(...) in it) could
become the setup script by Cython convention:
python cyex.pyxbld build_ext
It would then be at the same time, as imported module, the
definition file for pyximport.
-------------------------
or: the naked cyex.pyxbld (quite naked: not existing / nothing in
it / or the make_ext and optionally make_setup_args)
and:
cython cyex.pyx => translates to .c
cython cyex.pyxbld => build_ext's the cyex.so/.pyd; or even
auto-creates the .pyxbld, if not existing
cython -b cyex.pyx => translates AND builds the DLL; when no
cyex.pyxbld, then default settings
maybe thats quite intuitive? and no need for writing full setup
script infrastructure for any/each module before really
distributing something?
the thing is, that .pyx is about only ONE DLL anyway.
And as one has typically anyway more .pyx'es in a folder, then
the one and only good old "setup.py" could just integrate all the
.pyx/.pyxbld => "the project/package" .
##### setup.py ##################
from distutils.core import setup
from Cython.Distutils import build_ext
extensions = build_ext.collect("cyex.pyx","nextex.pyx",...)
setup(
ext_modules = extensions,
)
#########################
and the .pyxbld's with details do not need to exist until extra .c
files..
Robert
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
