
I am just trying to compile the latest CVS updates on NumPy, and am getting very cranky about the dependence of build process on distutils. let me say it politely, using distutils at this point is for the birds. maybe for distributing released versions to the general public, where the distutils setup.py script has been tested on many platforms, is a long term solution. but for right now, i miss the Makefile stuff. an example: (gustav)~/system/numpy/Numerical/: python setup.py build running build [snip] /usr/bin/egcc -c -I/usr/include/python1.5 -IInclude -O3 -mpentium -fpic Src/_numpymodule.c Src/arrayobject.c Src/ufuncobject.c Src/ufuncobject.c:783: conflicting types for `PyUFunc_FromFuncAndData' /usr/include/python1.5/ufuncobject.h:100: previous declaration of `PyUFunc_FromFuncAndData' Src/ufuncobject.c: In function `PyUFunc_FromFuncAndData': Src/ufuncobject.c:805: structure has no member named `doc' Src/ufuncobject.c: In function `ufunc_getattr': Src/ufuncobject.c:955: structure has no member named `doc' [blah blah blah] if this was from running make, i could be inside xemacs and click on the damn error and go right to the line in question. now, i gotta horse around, its a waste of time. another example, i posed to c.l.p a week or so ago. where it turned out that distutils doesnt know enough that, for example, arrayobject.h in distribution is newer than the one in /usr/include/python1.5 so breaks the build when API changes have been made. distutils should at leaast get the order of the -I's correct. but we're not a distutils SIG, we're NumPy, right? can we please go back, at least for now, to using -- or at a minimum distributing -- the Makefile's? les schaffer

Les Schaffer writes:
let me say it politely, using distutils at this point is for the birds.
Hmm, I'd hate to hear the impolite form! ;-)
but for right now, i miss the Makefile stuff.
an example:
(gustav)~/system/numpy/Numerical/: python setup.py build
<snip>
No, you don't have to horse around! Of course you can use xemacs and compile mode. (I wouldn't dream of building anything from an xterm window!) Just do M-x compile and set the compilation command to "python setup.py build", then you can click on the errors. Or create a trivial Makefile with these contents: numpy: python setup.py build install: python

Ooops, that message was somehow truncated, the last line should obviously have read: install: python setup.py install

Hmm, I'd hate to hear the impolite form! ;-)
isn't it nice when cranky-heads are dealt with politely? ;-)
Just do M-x compile and set the compilation command to "python setup.py build", then you can click on the errors.
ahhhh... hadnt thought of that. thanks.... here is a one line fix to build_ext.py in the distutils distribution that switches the order of the includes, so that -IInclude comes before -I/usr/lib/python1.5 in the build process, so API changes in the .h files don't hose the build before the install. les schaffer (gustav)/usr/lib/python1.5/site-packages/distutils/command/: diff -c build_ext.py~ build_ext.py *** build_ext.py~ Sun Jan 30 13:34:12 2000 --- build_ext.py Tue Mar 28 13:30:03 2000 *************** *** 99,105 **** self.include_dirs = string.split (self.include_dirs, os.pathsep) ! self.include_dirs.insert (0, py_include) if exec_py_include != py_include: self.include_dirs.insert (0, exec_py_include) --- 99,105 ---- self.include_dirs = string.split (self.include_dirs, os.pathsep) ! self.include_dirs.append(py_include) if exec_py_include != py_include: self.include_dirs.insert (0, exec_py_include)

Les Schaffer writes:
let me say it politely, using distutils at this point is for the birds.
Hmm, I'd hate to hear the impolite form! ;-)
but for right now, i miss the Makefile stuff.
an example:
(gustav)~/system/numpy/Numerical/: python setup.py build
<snip>
No, you don't have to horse around! Of course you can use xemacs and compile mode. (I wouldn't dream of building anything from an xterm window!) Just do M-x compile and set the compilation command to "python setup.py build", then you can click on the errors. Or create a trivial Makefile with these contents: numpy: python setup.py build install: python

Ooops, that message was somehow truncated, the last line should obviously have read: install: python setup.py install

Hmm, I'd hate to hear the impolite form! ;-)
isn't it nice when cranky-heads are dealt with politely? ;-)
Just do M-x compile and set the compilation command to "python setup.py build", then you can click on the errors.
ahhhh... hadnt thought of that. thanks.... here is a one line fix to build_ext.py in the distutils distribution that switches the order of the includes, so that -IInclude comes before -I/usr/lib/python1.5 in the build process, so API changes in the .h files don't hose the build before the install. les schaffer (gustav)/usr/lib/python1.5/site-packages/distutils/command/: diff -c build_ext.py~ build_ext.py *** build_ext.py~ Sun Jan 30 13:34:12 2000 --- build_ext.py Tue Mar 28 13:30:03 2000 *************** *** 99,105 **** self.include_dirs = string.split (self.include_dirs, os.pathsep) ! self.include_dirs.insert (0, py_include) if exec_py_include != py_include: self.include_dirs.insert (0, exec_py_include) --- 99,105 ---- self.include_dirs = string.split (self.include_dirs, os.pathsep) ! self.include_dirs.append(py_include) if exec_py_include != py_include: self.include_dirs.insert (0, exec_py_include)
participants (2)
-
Charles G Waldman
-
Les Schaffer