Dag Sverre Seljebotn wrote:
>> Robert wrote:
>>
>> I've done a few more tests on Linux and Win, and it does so far on
>> my side in all modes - for practical edit-run/reload debugging
>> purposes. The reload_support=False is anyway default.
>>
>> the little 3+.patch in attachment in addition to pyxi3.patch
>> http://trac.cython.org/cython_trac/ticket/312
>> (or manually against 0.11.1)
>> finally would solve the mentioned "reload(my) -> ImportError: No
>> module named my" problem of 0.11.1 or of reload_support=False
>> default mode
>>
>> I leave it open so far from my side.
>
> Thanks. I wanted to discuss some things a bit more, which is why it didn§t
> make it.
>
> The thing is that when a new format is introduced (pyxbld in this case),
> we have to make sure it is the right one because once it's there we must
> be backwards compatible.
.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.
The mode of pyximport compilation is often anyway different from
the regular setup.py script for the final project. And pyximport
uses its own temp and build files/folder by default (correctly).
>
> In my opinion, pyximport is for the "simple cases" where you do not really
still it must allow to define the basic dependencies, and other .c
files ...
=> the info for a setup() build_ext call
> want a build system. The pyxbld file however is verbose enough that one
> might perhaps as well write a setup.py...or have pyximport invoke a
> setup.py...
indeed the .pyxbld is a kind of setup.py, related to the .pyx
Just: its stuff is imported (and (pre)compiled!) and is not run as
script. fast, no new process/time delay for mere dependency checks
unless a compiler run...
at the moment of import, just a module name exist, modname.pyx is
found => associate .pyxbld.
Or info must be parsed from source code ..
>
> 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.
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 ...
so I'd say, a separate, fast, imported and compiled .pyxbld(c)
next to the .pyx, as it was, is primarily the right natural thing.
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
