axiom-developer
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Axiom-developer] Re: ASDF and ./configure


From: Gabriel Dos Reis
Subject: Re: [Axiom-developer] Re: ASDF and ./configure
Date: 24 Feb 2006 10:50:29 +0100

"David MENTRE" <address@hidden> writes:

| Hello Gaby,
| 
| 24 Feb 2006 07:54:40 +0100, Gabriel Dos Reis <address@hidden>:
| > The value of using Autoconf for Axiom is not in building it on or for
| > Ultrix, but in reusing packaged knowledge about various regular systems,
| > taken care of by system packagers.  Axiom really should be developing
| > its own idea of config.guess or system triplet.
| 
| Ok. However, I had the impression that Autoconf triplets are not what
| is needed for Axiom (e.g. is t possible to recognize a Fedora Core 3?

I don't understand why computing the triplet is not needed for Axiom.
The triplet is needed each time it is necessary to install and run
binaries that are not platform-independent.  Think about people
running in multi-arch environments for example (which is not
uncommon).  The binaries and other triplet dependent components will
be installed in places with standard names derived from the triplet.
To a very large extent, it is less important to recognize Fedora Core 3
(yes, that is what the current ./configure script does, but that is
wrong).  It is far more important to recognize *available*
functionalities, whether they come from Fedora Core 3 or SuSE Linux 9.3
Professional.  
If at some point in the future, we wanted Axiom easily distributed and
packaged with standard linux distros, it is in our interest to make
the integration seamless.

| Could we integrate different Lisps as part of the system triplet?).

The triplet identifies the cpu/machine/os.  That is a standard
classification, the least thing we want is to hijack it.  If we want
to test for specific flavors of lisp, we should use the Autoconf macro 
AC_CHECK_PROG, and if needed augmented with specific tests.

| But you obviously think that using some m4 macros this is not an
| issue.

essentially, we can write Autoconf macros to generate Lisp programs,
and run them.

| > ahem, in which shell?
| 
| Bash. But you're perfectly right that I did not read the manual with
| enough attention:
| man bash
| [...]
|        string1 == string2
|               True if the strings are equal.  = may be used in place of == for
|               strict POSIX compliance.
| 
| Bourne sh is using '=' as string equality.
| 
| Gaby: 1 - David: 0 (well, rather -infinity on this one ;-)

I notice the emoticon, but please let's nto get into that.  My main
interest in this is to have a proper build system, not to count point
or argue. 

| > Autoconf has been widely test in more wild
| > environment than anything variation you'll come up here.  I would
| > suggest that we avoid NIH and reuse the wisdom of the Autoconf guys
| > who have faced and experienced wild shell variation issues.
| 
| Ok, I'll look at Autoconf. If I should criticize it, at least should I
| do it on sound grounds. :-) I'll try to make a first prototype, but as
| I need to learn Autoconf first, don't hold your breath.

I'm was just relieved of one big "task", the other one is to get C++
standard papers written by tonight or tomorrow morning at the latest,
then make a pre-release for GCC-3.4.6; and after than I should be in
position to send a preiminary simple version of toplevel configure.ac
that we can start with.  Sorry it takes to long, but my TODO list
seems bottomless and evergrowing priority "car"s.  Babies and families
usually change priorities (as you all now)...

-- Gaby




reply via email to

[Prev in Thread] Current Thread [Next in Thread]