axiom-developer
[Top][All Lists]

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

 From: Gabriel Dos Reis Subject: Re: [Axiom-developer] [build-improvements] Requests for discussion Date: 02 Aug 2006 05:02:01 +0200

Cliff Yapp <address@hidden> writes:

| On Tuesday 01 August 2006 6:49 pm, Gabriel Dos Reis wrote:
|
| > | Most open source installations ship a pre-generated ./configure
| > | file and I think Axiom should be no different.
| >
| > Yes, that is what we will do.  That configure is generated by Autoconf
| > based on configure.ac.  Autoconf does not expect pamphlet files.
| > Autoconf want an input in a language it understands. Consequently, we
| > must present configure.ac in a way appropriate for Autoconf.
| > Therefore we cannot depend on noweb (notangle).
|
| If I understand the question, you are asking how we can have only literate
| program files in Axiom at the get go and still not depend on noweb.  The
| simple answer is, we can't.

Actually, we can if we don't insist that literate files must be
pamphlet files or we must use noweb :-)

[...]

| I've always wondered why LaTeX itself couldn't handle processing a pamphlet
| file as a regular latex file  - after all, couldn't it just replace
| <<chunckname>> [content] @ by a fancy version of \begin{verbatium}[content]
| \end{verbatium} or some such?  You would still need a notangle command to
| extract source code, but at least you could read the documentation without
| needing anything more than LaTeX.

I would like to move away from the @ and [] fancy syntax.  But, that
is a different battle I guess.

[...]

|  As long as configure.ac.pamphlet is written and maintained in
| the .pamphlet file I don't see a problem with special casing the continual
| presence of configure.ac  - it's pretty much inevitable.

OK.  I'll write up a development enrivonment minimal requirements and
include noweb (I still dislike that specific requirement).

| > | All this looks like a horrible hack to me - unless I am missing
| > | something fairly basic. What is wrong with the usual way of using
| > | noweb?
| >
| > See the explanations above.
|
| I understand the desire to be able to bootstrap, but there is no way around
| it - we must have one non-pamphlet file present to kickstart the process.
| Personally I would suggest two or three - a set of Bash and Windows script
| files containing all the autoconf and other incantantations the user would
| need to make might simplify matters even more.
|
| I don't think we should fear a couple of non-pamphlet files being present in
| the top level directory - indeed, it will simplify matters considerably from
| the user standpoint.  They won't know (and may not want to know) what a
| pamphlet file is all about - they just want to build and use the math program
| to do math.  In that case, the complete absence of anything familiar will
| turn them off.
|
| I would suggest the minimal (and maybe maximal) set of:
|
| configure.ac
| buildaxiom.sh
| buildaxiom_windows.<whatever windows uses>

The minimal setting should include

configure                     -- generated by Autoconf; end-user stuff
configure.ac                  -- generated by noweb, developer
configure.ac.pamphlet         -- hand-edited, developer
build-setup.sh                -- hand-edited; end-user stuff

build-setup.sh will abstract over all the low-level commands that
generate configure.ac from configure.ac.pamphlet, configure from
configure.ac -- and Makefile.am from Makefile.am.pamphlet when we
converts to Automake.

I'm not a windows developer, so I'll leave the windows stuff to others
(hi Bill).

[...]

| > This is a hack; I agree.  No more horrible than what we currently do
| > with noweb.  However, I don't like it.  That is why I called for
| > discussion and suggestions for improvements :-)
|
| There is no way to bootstrap without a "lower level" file present to kick the
| process off,

I know.  configure.ac is that file.  And the point that started the
experiment is that once you've written configure.ac, there is very
little gained by putting it in a pamphlet file.  All the documentation
will need to be present in the final generated configure file.
Consequently, the low-level stuff here equals to the high-level variant.

| unless (as you already attempted) the higher level files are
| also legal lower level files.  I don't think we want to redefine the literate
| strategy we use to that degree - it's not worth it.

I'm really annoyed by the dependency on noweb to bootstrap the
process.  I would rather, by a large degree, vanilla traditional
tools, e.g. plain 'sed'.  However, I will proceed as outlined above, and
will at the same time respectfully register my strong disagreement.

[...]

| In a way, it's the same problem Tim faced with Axiom being needed to build
| Axiom.  The only way out was (and still is) to have some files in lisp
| present, to teach lisp to read and understand BOOT and SPAD.  Same deal here.

That is a good recipe for maintenance nightmarre -- recent debates about
redundant boot anyone?  There ought to be a better way to deal with it.

In the case of configure.ac, I'm pretty convinced because I've tried
several ways.  The conclusion invariably is that there is no
difference between the low-level stuff and the high-level stuff.  Any
attempt to raise the abstraction there is a non-interesting, fruitless
exercise.

The case for boot might be different though -- I've not spent enough
time there yet.

| It's a universal problem - if we wanted to bootstrap a machine from a cold,
| memoryless, powerless state we would need some binary to feed it before it
| could start speaking assembly. True bootstrapping is a very rare event ;-).

I've been hacking real life compilers for over decade now :-)

[...]

| 1 and 3 are solved by always having a current notangle of configure.ac
present
| in the tree at all times.  As for two, I think we should assume a working
| notangle is available.  We have to assume SOMETHING is working,

No question we have to assume something is workin -- just assume,
everybody knows that.

The issue is whether it must be noweb.  I think "no".  But, I do