distutils extension commands and option passing
hi there, one of the things I like most about distutils is the compositional approach to the build system, i.e. commands such as 'bdist' being defined independently of 'build', so as soon as I have a working 'build' command, 'bdist' (and its variants) will work out-of-the-box most of the time. However, I'v now run into an issue with this very approach, and I wonder how to deal with that: As the 'build_ext' command shipped with distutils isn't powerful enough for my extensions, I'v written one myself. It's basically a wrapper around a call to 'make -C ...'. That is accompagnied by a 'config' command, doing, what else, a 'configure' call... I'v added various options to the config command to be able to enable/disable the various extensions that can be supported. But there doesn't seem to be a way to call 'python setup.py bdist_rpm' (say) and somehow pass options that are really meant for the config command, or is there ? That means I have to write my 'config' command such that the default is the desired configuration for the rpm. Right ? Any tips are highly appreciated, Stefan
Stefan Seefeld
hi there,
one of the things I like most about distutils is the compositional approach to the build system, i.e. commands such as 'bdist' being defined independently of 'build', so as soon as I have a working 'build' command, 'bdist' (and its variants) will work out-of-the-box most of the time.
However, I'v now run into an issue with this very approach, and I wonder how to deal with that:
As the 'build_ext' command shipped with distutils isn't powerful enough for my extensions, I'v written one myself. It's basically a wrapper around a call to 'make -C ...'. That is accompagnied by a 'config' command, doing, what else, a 'configure' call...
I'v added various options to the config command to be able to enable/disable the various extensions that can be supported.
But there doesn't seem to be a way to call 'python setup.py bdist_rpm' (say) and somehow pass options that are really meant for the config command, or is there ?
There are three ways that I know of:
On the command line (undocumented, AFAIK):
python setup.py build_ext
Hi Thomas, thanks for the reply. It's really a pitty that these things are not documented... Thomas Heller wrote:
There are three ways that I know of:
On the command line (undocumented, AFAIK):
python setup.py build_ext
bdist_rpm
interesting ! However, this doesn't really work in my case since the bdist_rpm command generates a script that is calling 'python setup.py install', so the above options aren't passed (i.e. the problem is that bdist_rpm would need a way to 'pass through' stuff without interpretation.
In the setup.cfg file (documented):
[build_ext] opt_1 = value_1 opt_2 = value_2
[bdist_rpm] opt_A = value_A opt_B = value_B
good, however, this would apply to every build then, right ? What I was looking for was a way to call 'python setup.py bdist_rpm --foo' and 'python setup.py bdist_rpm --bar' and have both build *different* rpms. And that is hard to achieve as bdist_rpm only has a fixed set of params and extending it is very hard.
And finally, you can pass a nested dictionary of options to the setup script (aldo undocumented, AFAIK):
options = {"build_exe": {"opt1": "value1", "opt2": "value2"} "bdist_rpm": {"opta": "valuea", "optb": "valueb"}}
hmm, that looks best, but it requires some top-level parameter processing to yield the flexibility I desire, i.e. before calling setup() I'd have to process the parameters myself and then fill these dictionaries appropriately. Looking into the code I see how the default commands do what I want: snippet from bdist_rpm: sdist = self.reinitialize_command('sdist') if self.use_bzip2: sdist.formats = ['bztar'] else: sdist.formats = ['gztar'] self.run_command('sdist') i.e. commands can communicate among each other through the 'distribution' object. Of course, that's quite fragile as it requires these commands to know each other, so setting or modifying another command's option 'in memory' has to be done with care.
IMO, patches for the docs would be appreciated.
Hmm, is *anybody* actively working on distutils ? Of course, documenting existing code / practice would be a good start. But at some point I'd like to provide patches that enhance distutils, but for that I'd prefer to have a clear idea of the mental model the developers have (had ?) when working out the framework. There are notably two places I think would be worth enhancing: * a much enhanced 'config' command that provides functions to test platform specifics, similar to autoconf. * a much more flexible (and extensible !) way to deal with 'Extensions' Regards, Stefan
participants (2)
-
Stefan Seefeld
-
Thomas Heller