lannert@lannert.rz.uni-duesseldorf.de wrote:
[I'm only subscribed to the digest; please bear with me if I'm out of sync with the current status of the discussion]
Greg Ward wrote:
Sooner or later (probably sooner), somebody is going to want to say:
if compiler == 'gcc' and platform == 'linux-x86': compiler_options.append ('-funroll-loops')
...and that's probably only the beginning. ...
and, later on, suggested variables like OS class, OS name, OS version, OS vendor, architecture, etc. etc.
IIRC, Marc-Andre's suggestion pointed into a somewhat different direction: that the properties of a certain [instance of an] OS would be described by a set of variables indicating system "behaviour", rather than the formal vendor/version/architecture description.
Well, to make things complete, here are the three suggestions again: · a way to test compiler features a la configure, e.g. a simple way to pass a small C program and evaluate the compiler error message (error or no error should suffice) · a way to test the availability of (shared) libs in much the same way, e.g. try to link an empty object file against a set of given libs to see if the linker finds the libs or not · a way to access the compiler/linker name and version More specific the methods: · testcompile(program_string[,options]) · testcompileandlink(program_string[,options,libs]) which return 1/0 to state "success" / "failure" and implement proper cleanup of the intermediate files. And an interface much like the one Greg proposed in his last mail for the compiler/linker/platform names. Note that I only mention abstract interfaces. It's up to the distribution author to use these and do something useful with them. On the practical side: does anyone know of ways to figure out those names ? E.g. how would one test for RedHat vs. SuSE, libc5 vs. libc6, MSVC vs. Borland C++ ? -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 164 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/