Greg Ward wrote:

Oh, here's an example of how easy it is to autoconfigure Python extensions now. This is taken from examples/mxdatetime_setup.py; here're the essentials 'run()' method of the "config_mxDateTime" command class:

def run (self): have = {} have['strftime'] = self.check_func('strftime', ['time.h']) have['strptime'] = self.check_func('strptime', ['time.h']) have['timegm'] = self.check_func('timegm', ['time.h'])

define = [] undef = [] for name in have.keys(): # ('strftime', 'strptime', 'timegm'): macro_name = 'HAVE_' + string.upper(name) if have[name]: define.append((macro_name, None)) else: undef.append(macro_name)

Note that the bulk of the code is the bureaucracy of figuring out which macros to define, ie. generateing HAVE_STRFTIME and friends. Obviously this could (and should) be taken care of by the standard "config" command; we'll get there!

Here's the output of "setup.py config" (very noisy because --noisy and --dump-source are both enabled by default for now):

running config compiling '_configtest.c': #include

int main () { strftime; } gcc -c -g -O2 -fPIC _configtest.c -o _configtest.o gcc _configtest.o -o _configtest success! removing: _configtest.c _configtest.o _configtest compiling '_configtest.c': #include

int main () { strptime; } gcc -c -g -O2 -fPIC _configtest.c -o _configtest.o _configtest.c: In function `main': _configtest.c:4: `strptime' undeclared (first use in this function) _configtest.c:4: (Each undeclared identifier is reported only once _configtest.c:4: for each function it appears in.) failure. removing: _configtest.c _configtest.o compiling '_configtest.c': #include

int main () { timegm; } gcc -c -g -O2 -fPIC _configtest.c -o _configtest.o gcc _configtest.o -o _configtest success! removing: _configtest.c _configtest.o _configtest macros to define: [('HAVE_STRFTIME', None), ('HAVE_TIMEGM', None)] macros to undefine: ['HAVE_STRPTIME']

Note that ('HAVE_STRFTIME', None) means "-DHAVE_STRFTIME" -- i.e. define the macro without any particular value. No, I don't know why 'strptime()' isn't showing up, but at least it demonstrates a failure case.

Because it will only show up if the _XOPEN_SOURCE symbol is defined before including time.h -- weird, I know, but that's gcc... it may be worthwhile to provide such defines to the config functions in some way (or to make them default for gcc in the compiler class, e.g. always define _GNU_SOURCE which enables all of GNU CC's features). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

On 22 June 2000, I spoke too soon:

That assumes that I changed the interface to return boolean arbitrarily. I did not: I believe there is code that depends on it returning boolean. And now there is also code that depends on it returning the output filename. Damn! Time to grep the source for copy_file and see how it's *really* used...

Well, from poking through the CVS logs, it appears that 'copy_file()' has *always* returned boolean. And from scanning the source, it appears that no code actually expects it to return boolean -- the only bits that pays attention to the return value are my recent additions that use 'copy_file()'s supposed string return value to build list of files copied. So, Bastian's patch is exactly the right thing. (Except you forgot to fix the docstring! Don't worry, I did it.) Applied, checked in, and now maybe things will work again. Greg -- Greg Ward - geek-at-large gward@python.net http://starship.python.net/~gward/ The NSA. We care: we listen to our customers.