Re: [Axiom-developer] [build-improvements] Requests for discussion

[Gabriel Dos Reis]

Ralf Hemmecke <address@hidden> writes:

[...]

| I don't see a difference between
| 
|  >     (1) modify configure.ac.pamphlet
|  >     (2) run ./build-setup.sh
| 
| and my suggested
| 
|       modify configure.ac.pamphlet
|       make configure

"make" means that there is a Makefile that is used to make "configure".
There isn't.  Any makefile must be generated at configure time when
building Axiom.  I know that is not what the current system does;
but it is a bug -- it got me several times.

| In my previous mail I suggested "./configure && make configure" but
| that was only to make sure that "noweb" is found by "configure" if you
| have it installed somewhere, then of course you don't need to run
| 'configure'.
| 
| Now whether you call "build-setup.sh" or "make configure" isn't much
| of a difference. Is it? 

from my perspective; there is.  See above.

[...]

| I know that "make" checks whether the "Makefile" is as new as it could
| be. But does it check whether there is Makefile.in or Makefile.am and
| re-generates the Makefile from that???

No.  Makefile.in usually contains variables that need to be
substituted.  Makefile.am is even at higher level.  You need
Automake.  Now, when you have the full Autotools in place, if you
modify Makefile.am or configure.ac and you say "make", there usually
is a dectection and autoconf is run to regenerate

| And why do you insist on having all Makefiles generated during
| "configure"? 

Because they contain platform-specific information and the standard way to
reduce duplication and make the whole system manageable is to abstract
over the variabilities.  Otherwise, we have the current mess. 
This isn't an innovation.  Look at any other system that uses Autoconf
+ Automake (Maxima is one that additionally has a Lisp-based configure).

| For me it is perfectly fine if the Makefiles are
| regenerated from their .pamphlets during the build of Axiom. It is
| only that the Makefiles should more rely on variables that define
| programs like using ${TAR} instead of just tar.
| 
| Or is the whole thing more complicated than I think?

In part yes.

The only benefit I see of not storing configure.ac is more
complications and more potential for bugs.  I don't see the benefits.

| > | Gaby, it is only you who must run
| > | | notangle configure.ac.pamphlet > configure.ac
| > | autoconf configure.ac > configure
| > I do expect other developers making changes to
| > configure.ac.pamphlet (and later to any Makefile.am.pamphlet) to run
| > equivalent commands.  Fortunately, that is all taken care of by
| > build-setup.sh.  :-)
| 
| So each time I modify a file which is called configure.ac.pamphlet or
| Makefile.am.pamphlet, I should run "build-setup.sh".

Yes.

| What if I forget that? 

I'll catch you.  Your "make configure" suffers from the same problem.

When we move to Automake, the system will assist me.

| There should be at least a warning telling me that I should run
| "build-setup.sh".

Probably; that is low-priority right now.

| 
| > build-setup.sh is not an end-user stuff.  It is only for maintainers
| > of the build machinery.
| 
| That's clear.
| 
| > Bill suggested we don't keep configure.ac.  I fear we must kepp it --
| > for the purpose of preventing the build machinery maintainers from
| > introducing subtle bugs.  Components of Autotools have dependency on
| > such files in several circumstances.
| 
| Can you make up an example so that we see what problems can occur and
| appreciate why we should keep configure.ac.

No, I don't have time for that -- I'm sorry.  You have to take my word
for it for the moment.  When I get more time, I can play with testcases.

| Then that should be
| documented (in a pamphlet file) describing the build process.

Yes.  That is not an issue.

| Currently, I also don't feel need for configure.ac, given that
| maintainers have noweb and configure.ac.pamphlet.

Then just forget about it and run build-setup.sh.

-- Gaby