This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author eli.collins
Recipients alexis, eli.collins, eric.araujo, tarek
Date 2011-06-23.19:50:17
SpamBayes Score 1.2767565e-15
Marked as misclassified No
Message-id <1308858621.76.0.0183537042142.issue12242@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2011-06-23 19:50:22eli.collinssetrecipients: + eli.collins, tarek, eric.araujo, alexis
2011-06-23 19:50:21eli.collinssetmessageid: <1308858621.76.0.0183537042142.issue12242@psf.upfronthosting.co.za>
2011-06-23 19:50:21eli.collinslinkissue12242 messages
2011-06-23 19:50:19eli.collinscreate