The build_ext command has -I and -L options, why don't others???
I think this may be a fundamental flaw in the way distutils works... (By that, I mean that it's something that "obviously" should work, but it's going to be massively hard to implement that way :-() Let me know what you think. I'm still hacking on my PIL setup.py file. My latest thought was that, given that PIL needs the ZLib, JPEG and TCL libraries, and given that I don't have a "standard" location to look in for them, what command line options might help. And sure enough, I found the -I and -L options for the build_ext command. Great! That's just what I want. Obviously (!), I'm using the "build" command, but that executed build_ext behind the scenes for my extensions, so I'll just pass -I and -L, and let build pass them on to build_ext as needed. Oh, no... The build command complains that the -I and -L options are invalid. Grr. I guess this means that I either have to run build_ext first, by hand, and then run build (this works - well, it would if the build_clib command had an -I option, but that's a separate issue...), or I have to write a custom build command which accepts -I and -L and passes them onto build_ext. Surely, commands (like build and install) which run other commands should take *all* of the options allowed by any of their sub-commands, and pass them onto those sub-commands. As I say, this seems obvious to me, but (having looked briefly at the internals) annoyingly hard to do, in practice. As I say, any thoughts? Paul. PS I think this pretty much kills any hope of writing a setup.py which usefully implements command line argument extensions. You'd have to write custom commands for every command, from the lowest one which needs the extra option, all the way up the tree (install must be customised to take the same options as the custom build, which must be customised to take the same options as the custom build_ext, ...)
Paul Moore wrote:
I think this may be a fundamental flaw in the way distutils works... (By that, I mean that it's something that "obviously" should work, but it's going to be massively hard to implement that way :-() Let me know what you think.
I'm still hacking on my PIL setup.py file. My latest thought was that, given that PIL needs the ZLib, JPEG and TCL libraries, and given that I don't have a "standard" location to look in for them, what command line options might help.
And sure enough, I found the -I and -L options for the build_ext command.
Great! That's just what I want. Obviously (!), I'm using the "build" command, but that executed build_ext behind the scenes for my extensions, so I'll just pass -I and -L, and let build pass them on to build_ext as needed.
Oh, no... The build command complains that the -I and -L options are invalid. Grr. I guess this means that I either have to run build_ext first, by hand, and then run build (this works - well, it would if the build_clib command had an -I option, but that's a separate issue...), or I have to write a custom build command which accepts -I and -L and passes them onto build_ext.
Surely, commands (like build and install) which run other commands should take *all* of the options allowed by any of their sub-commands, and pass them onto those sub-commands. As I say, this seems obvious to me, but (having looked briefly at the internals) annoyingly hard to do, in practice.
python build_ext -I ... -L ... build should do the trick.
PS I think this pretty much kills any hope of writing a setup.py which usefully implements command line argument extensions. You'd have to write custom commands for every command, from the lowest one which needs the extra option, all the way up the tree (install must be customised to take the same options as the custom build, which must be customised to take the same options as the custom build_ext, ...)
AFAIK, all commands inherit command line option from the Distribution class, so by subclassing you should be able to provide those extra options to all subcommands. Could be wrong though... the option passing in distutils is something of a mess. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/
On Sat, 21 Jul 2001 21:12:44 +0200, "M.-A. Lemburg"
python build_ext -I ... -L ... build
should do the trick.
That's a bit messy, though - and not particularly intuitive.
AFAIK, all commands inherit command line option from the Distribution class, so by subclassing you should be able to provide those extra options to all subcommands. Could be wrong though... the option passing in distutils is something of a mess.
I'll look into this - but I agree, the area is complex and non-trivial to understand. If I can get a simple example working, I'll write it up for the documentation. I already have a nice simple "How to add a custom command" sample. Paul.
Paul Moore wrote:
On Sat, 21 Jul 2001 21:12:44 +0200, "M.-A. Lemburg"
wrote: python build_ext -I ... -L ... build
should do the trick.
That's a bit messy, though - and not particularly intuitive.
Agreed, but it works ;-) (and you can also have your users edit the setup.cfg file section for build_ext, so they won't really notice)
AFAIK, all commands inherit command line option from the Distribution class, so by subclassing you should be able to provide those extra options to all subcommands. Could be wrong though... the option passing in distutils is something of a mess.
I'll look into this - but I agree, the area is complex and non-trivial to understand.
If I can get a simple example working, I'll write it up for the documentation. I already have a nice simple "How to add a custom command" sample.
That'd be great ! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/
participants (2)
-
M.-A. Lemburg
-
Paul Moore