But what if someone installs their own, better version of curses, e.g. in /usr/local? Maybe you should only disable it if it's darwin *and* if it's in a standard location? Or if the header file contains a certain characteristic string?
In that case, the user could still put the appropriate instructions into Modules/Setup, which they'd probably do anyway, since they need special -I/-L options. So I agree with the notion that setup.py should only do so much autoconfiguration, and leave special cases to manual configuration through Modules/Setup. However, I dislike the frequent usage of platform in setup.py, where this patch adds another instance of. I believe the autoconf approach "test for features, not system names" is much more flexible. If the curses module requires certain feature, find a way of testing whether the features are present, and only compile _curses if they are. Then it would not be necessary to check whether the system name is "darwin1". This is problematic in particular as different spellings of the platform are expected: It is "darwin1" in some places, and "Darwin1.2" atleast in another place. Regards, Martin
However, I dislike the frequent usage of platform in setup.py, where this patch adds another instance of. I believe the autoconf approach "test for features, not system names" is much more flexible. If the curses module requires certain feature, find a way of testing whether the features are present, and only compile _curses if they are. Then it would not be necessary to check whether the system name is "darwin1". This is problematic in particular as different spellings of the platform are expected: It is "darwin1" in some places, and "Darwin1.2" atleast in another place.
Does distutils have a way to grep a .h file for a certain string? I'm sure that we could come up with a suitable string to check for (a function or macro defined in recent curses versions but not in old curses versions); but I'd hate to have to write the test by hand. --Guido van Rossum (home page: http://www.python.org/~guido/)
Does distutils have a way to grep a .h file for a certain string? I'm sure that we could come up with a suitable string to check for (a function or macro defined in recent curses versions but not in old curses versions); but I'd hate to have to write the test by hand.
Even if it works, we may find that this approach causes the module not to be build on systems which would support it. The problem is that curses.h may include other header files which contain the definition we are looking for. The only real test is the one that autoconf uses, i.e. AC_TRY_COMPILE. Supporting that in distutils is probably something that needs careful planning. Regards, Martin
>> Does distutils have a way to grep a .h file for a certain string? >> I'm sure that we could come up with a suitable string to check for (a >> function or macro defined in recent curses versions but not in old >> curses versions); but I'd hate to have to write the test by hand. Martin> Even if it works, we may find that this approach causes the Martin> module not to be build on systems which would support it. Or it might be #ifdef'd into or out of existence. Grep's just not going to cut it. Martin> The problem is that curses.h may include other header files Martin> which contain the definition we are looking for. The only real Martin> test is the one that autoconf uses, i.e. AC_TRY_COMPILE. Martin> Supporting that in distutils is probably something that needs Martin> careful planning. Part of that careful planning should be to evaluate the tradeoff between making this work in setup.py and getting autoconf and friends to play on the platforms we are interested in. Skip
On 05 September 2001, Martin von Loewis said:
Even if it works, we may find that this approach causes the module not to be build on systems which would support it. The problem is that curses.h may include other header files which contain the definition we are looking for. The only real test is the one that autoconf uses, i.e. AC_TRY_COMPILE. Supporting that in distutils is probably something that needs careful planning.
The distutils "config" command was precisely that: a start at reimplementing Autoconf in Python. I didn't get very far, but I got far enough to convince myself that it's very much worth doing. For example, here's my analog to AC_TRY_COMPILE, the try_compile() method of the distutils.command.config.config class: def try_compile (self, body, headers=None, include_dirs=None, lang="c"): """Try to compile a source file built from 'body' and 'headers'. Return true on success, false otherwise. """ from distutils.ccompiler import CompileError self._check_compiler() try: self._compile(body, headers, lang) ok = 1 except CompileError: ok = 0 self.announce(ok and "success!" or "failure.") self._clean() return ok I'd much rather write Autoconf (and Autoconf scripts) in Python than in Bourne shell! I ran out of steam on the "config" command about the same time I ran out of steam on the Distutils in general, ie. right around when Python 2.0 was released. Sigh. The idea is sound, the implementation is started, it just needs to be carried through. The main problem when I left off is what to do with config info between runs of the setup script; if it's treated just like any other Distutils command, you'd end up doing the equivalent of re-running "configure" every time your run "make", which would be mind-blowingly bogus. I suspect the answer is to drop a pickle of the configuration state somewhere. There's also a lot of grunt-work coding required to implement a usable subset of Autoconf. Greg -- Greg Ward - Unix weenie gward@python.net http://starship.python.net/~gward/ Jesus Saves -- but Moses gets the rebound, he shoots, he SCORES!
I'd much rather write Autoconf (and Autoconf scripts) in Python than in Bourne shell!
Of course, there's the slight problem that you can't write the autoconfiguration for Python itself in Python. This reduces the motivation, I suppose. :-( --Guido van Rossum (home page: http://www.python.org/~guido/)
On 06 September 2001, Guido van Rossum said:
Of course, there's the slight problem that you can't write the autoconfiguration for Python itself in Python. This reduces the motivation, I suppose. :-(
Well, we could do the "probe for bsddb"-like stuff right, and in Python. Just not the "is this a 64-bit left-handed albino operating system with a broken stdio?" stuff. Greg -- Greg Ward - Linux nerd gward@python.net http://starship.python.net/~gward/ Dyslexics of the world, untie!
participants (5)
-
Andrew Kuchling -
Greg Ward -
Guido van Rossum -
Martin von Loewis -
Skip Montanaro