Re: [Distutils] autoconf in distutils?
[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.
I would second this idea (and, IIDNRC, first it <wink>); maybe there are some situations where I'd like to know if a certain system is a SuSE or RedHat Linux, but usually I'd rather be interested in whether it has SysV or Simple init (and where the init.d directory is), if ps and friends want BSD or SysV style operands, if we have cc or gcc or egcs, and the like.
The "intelligence" about the peculiarities of a vendor-x/version-y installation should IMO not be built into a tool like distutils; it would fail anyway for mangled or personalized systems (e.g. a SuSE Linux updated with a few RH and some home-grown rpm's).
All the vendor-, installation- and configuration-specific data should be specified as individual variables assignments, probably in several files which are processed in a hierarchical order (like /etc/system.inst: /var/lib/inst/*.inst:~/.inst/*.inst:.instrc, just to give a silly example). They could be provided by (contributors to) distutils as a first start, but ideally by the vendors or distribution builders themselves <0.99 dream>.
I'd even go so far and suggest shell variable assignment format for these files (name=value or name="value with blanks" etc.); it's far from ideal, but since it could be used from non-pythonic tools there would be an incentive for others to support and provide these files.
Python programs can, of course, parse these files, although it's not trivial. I've written a ShellAssignment parser which understands "", '', $var, ${var}, \ escapes, at least in the most common cases; I wished there was a string.parsequotedstring() function ...
Detlef
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++ ?
"M.-A. Lemburg" wrote:
On the practical side: does anyone know of ways to figure out those names ? E.g. how would one test for RedHat vs. SuSE,
Again, should one really? I mean, a package [author] is interested in the _features_ of the current system, more than in its brand.
One example: init scripts are expected in /etc/rc.d/{rc?,init}.d/ by RedHat, /sbin/init.d/[rc?.d/] by SuSE. How would I inform the install routines if I used RedHat with /sbin/init.d? This is particularly an issue for Linux systems which actually are based on the _same_ OS; but I could also configure most other Unices beyond recognition.
Therefore all relevant parameters (which are not easily testable, like presence/absence of header files in a known include path) should be assigned individually. A predefined collection for, say, SuSE or RedHat Linux would be nice, but should be overrideable by the admin and the user.
Detlef
lannert@lannert.rz.uni-duesseldorf.de wrote:
"M.-A. Lemburg" wrote:
On the practical side: does anyone know of ways to figure out those names ? E.g. how would one test for RedHat vs. SuSE,
Again, should one really? I mean, a package [author] is interested in the _features_ of the current system, more than in its brand.
One example: init scripts are expected in /etc/rc.d/{rc?,init}.d/ by RedHat, /sbin/init.d/[rc?.d/] by SuSE. How would I inform the install routines if I used RedHat with /sbin/init.d? This is particularly an issue for Linux systems which actually are based on the _same_ OS; but I could also configure most other Unices beyond recognition.
Therefore all relevant parameters (which are not easily testable, like presence/absence of header files in a known include path) should be assigned individually. A predefined collection for, say, SuSE or RedHat Linux would be nice, but should be overrideable by the admin and the user.
Ehm, yes, that's what I was aiming at, basically. The OS vendor name should not be used to hard-code features, but rather to make proper preselection of parameters possible. Adjustments can then be done by the installing user (if she wishes).
One thing that might also be of interest is an abstract mechanism for checking the system's installation, e.g. on RedHat and SuSE one could use RPM to get information about which tools are available. Don't know about other systems though (on Windows one could probably query the registry). That way one could create scripts of the form:
if system.provides('kde') and system.getversion('kde') >= '1.2': # The system has unixODBC installed, so we default # to that configuration ... elif system.provides('iodbc'): # Ok, then use iODBC ... else: # No ODBC manager ? Ask the user... yn = raw_input('Is an ODBC manager installed on your system ?') ...
if system.provides('adabas'): # Auto-configure the ADABAS subpackage if system.provides('informix'): # Same for Informix SE Some handy directory searching tools would also help, e.g. if you look for a lib "by hand".
On Wed, 21 Jul 1999, M.-A. Lemburg wrote:
[snip]
One thing that might also be of interest is an abstract mechanism for checking the system's installation, e.g. on RedHat and SuSE one could use RPM to get information about which tools are available. Don't know about other systems though (on Windows one could probably query the registry). That way one could create scripts of the form:
[snip]
I'm kind of partial to using (and updating) the RPM databases on any system in which they are found to exist. If the Windows registry has the same information, it could be used instead. For systems in which neither exists, I recommend the use of a pure python version of such a thing.
I'm more concerned with this as a means of guaranteeing package dependencies than of checking for installation/compilation tools.
============================================================================= michaelMuller = proteus@cloud9.net | http://www.cloud9.net/~proteus ----------------------------------------------------------------------------- We are explorers in the further reaches of experience: demons to some, angels to others. - "Pinhead" from "Hellraiser" =============================================================================
participants (3)
-
lannert＠lannert.rz.uni-duesseldorf.de -
M.-A. Lemburg -
Michael Muller