Message138872
Attached is a patch that implements this enhancement along the lines of what was last discussed. The behavior introduced in the patch is as follows:
* It adds a stub method named get_compiler_version() to CCompiler,
and implementations of that method for the various compilers.
This method returns the name of the compiler and a version number
(eg "gcc 4.5.2"), exact format described in docstring
of stub method.
* It adds two new arguments to the Extension object:
specific_compile_args, and specific_link_args.
These act similarly to extra_compile_args & extra_link_args,
except that (if specified) they should contain a list of
(regexp string, args) tuples.
When build_ext runs, it retrieves the version string from
get_compiler_version() for the current compiler object.
It matches this against all patterns listed in specific_compile_args.
The args corresponding to the first pattern that matches
are appended to extra_compile_args.
If no pattern matches, extra_compile_args is used unchanged.
If the matched args list contains the magic string "{common_args}",
any extra_compile_args will be inserted at that location
instead of appending the matched args, allowing
for position-dependant arguments.
specific_link_args is handled in a parallel manner.
* The Config object has been modified to parse
specific_compile_args and specific_link_args
in any extension sections.
Both expect a multiline list of k=v pairs,
as in the following example:
[extension=foo]
...other settings...
specific_compile_args =
gcc = --optiona --optionb ; some-env-marker = 'value'
gcc = --optiona
.* = --fallbackoption
These are translated into the format required by Extension()
While this patch works, I have a couple of questions / issues:
1. This patch was made against the hg.python.org/cpython repo.
There appear to be a number of distutils2 repos floating about
(hg.python.org/distutils2, and Tarek has some mirrors on bitbucket).
I'm unclear which one I should be writing this patch against.
If another repo is more appropriate, I can rebase the patch
and resubmit.
2. I'm not sure where I should add documentation about this new behavior.
I added some documentation to the Extension class itself,
but that probably isn't the only place it's needed.
3. This feature could probably use some unittests to be added as well.
I can try my hand at that, but wanted to make sure the design
was acceptable first.
4. This patch uses ";" to separate k=v pairs from environment markers.
This is in line with the PEP and the metadata sections.
However, extra_compile_args's _pop_values() function seems
to use "--" as it's environment marker separator.
This doesn't seem right to me, as "--" is frequently found in options
strings, and I'd expect it to cause problems.
If this is a bug in extra_compile_args,
I'm happy to create a separate bug and submit a patch.
However, if there's some reason that "--" should be used,
I can modify this patch to use "--" as well
(though that route seems fraught with parsing problems).
Please let me know what more I can do. |
|
Date |
User |
Action |
Args |
2011-06-23 19:50:22 | eli.collins | set | recipients:
+ eli.collins, tarek, eric.araujo, alexis |
2011-06-23 19:50:21 | eli.collins | set | messageid: <1308858621.76.0.0183537042142.issue12242@psf.upfronthosting.co.za> |
2011-06-23 19:50:21 | eli.collins | link | issue12242 messages |
2011-06-23 19:50:19 | eli.collins | create | |
|