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 haubi
Recipients haubi, srid, tarek, trentm
Date 2009-09-07.11:07:09
SpamBayes Score 1.3680168e-12
Marked as misclassified No
Message-id <1252321632.02.0.208595498395.issue6163@psf.upfronthosting.co.za>
In-reply-to
Content
> But compiler[:3] implies that the compiler string starts *with* 'gcc'.
> 
> so are you sure we're looking for 'gcc' anywhere in the string,
> or at the beginning of it ?

It is very common to use the host triplet in the compiler name, like
'i686-pc-linux-gnu-gcc', even for non-cross builds. Sometimes the
compiler string also looks like 'ccache gcc' or 'distcc gcc'. Even
'/path/to/some/gcc' is possible, in combination with '/path/to/ccache'
and/or '/path/to/distcc'. And sometimes the version number is appended,
like 'gcc-X.Y.Z'. Also ABI-specific flags might be set there, like 'gcc
-m32'.

> In any case, I find these string searches very weak in there.

Agreed, but AFAICT, native and other non-gcc compilers never do have
something like 'gcc' in their installation path, especially not in their
executable basename (on AIX, HP-UX, Solaris). So eventually it is save
enough to search for gcc/g++ after the last path-separator, although
this won't work for things like 'gcc -I/my/local/include'.

> I am going to refactor a function in distutils that guesses the type
> of compiler, given a list of known compilers 'names' and a list of
> matching strings (or regular expressions) for them.

The most reliable way IMHO would be to preprocess '#ifdef __GNUC__', and
avoid searching the compiler string for anything.

Thank you!
History
Date User Action Args
2009-09-07 11:07:12haubisetrecipients: + haubi, tarek, trentm, srid
2009-09-07 11:07:12haubisetmessageid: <1252321632.02.0.208595498395.issue6163@psf.upfronthosting.co.za>
2009-09-07 11:07:09haubilinkissue6163 messages
2009-09-07 11:07:09haubicreate