Michael Haubenwallner <michael.haubenwall...@salomon.at> added the comment:
> 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! ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue6163> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com