axiom-developer
[Top][All Lists]
Advanced

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

[Axiom-developer] RE: Juergen's makefile


From: Weiss, Juergen
Subject: [Axiom-developer] RE: Juergen's makefile
Date: Wed, 13 Aug 2003 21:46:20 +0200

Actually, as I already noted, the ordering is mainly due
to Tim. I just went on with the missing files in alphabetical
order, tried to compile the files and if it failed,
I added the files after Tim's explicit list as layer 19. So 
what's in the makefile is an explicit list and the rest alphabetically
ordered. There may be dependencies between the alphabetically
listed files. If you know the dependencies, just extend
the explicit list. Not further changes necessary. 

My idea was to explicitly state the nontrival and let make
care for the rest. And I wanted the command to compile an
algebra file to be in one place, so that it is easy to
change. It's very difficult to understand a system,
were some nontrivial build information is found after
some thousand lines of ``trivial´´ commands. In my framework,
if you add a new algebra file, you just have to add 
the file to the list of .spad files and the modules
it defines at the right place in the modules list.

You can explicitly define groups of 
files and dependencies between them in my framework as
well. I wonder if this is really necessary. Make generates
the dependencies of a target sequentially and that's all
I used. Especially if as you suggest, the make file is
used only to build the system from scratch. Other
dependencies are necessary, if you change one file and
want to rebuild as few files as necessary. 

I know that my makefile needs some explanation. It was 
just a first version. Though I'm proud of the ed
hack :-), I know it is quite cryptic. But I did not
wanted to put any time in the makefiles, if they would
not pass peer review ;-). 

Juergen

> -----Original Message-----
> From: root [mailto:address@hidden 
> Sent: Wednesday, August 13, 2003 8:44 PM
> To: address@hidden
> Cc: address@hidden; Weiss, Juergen; address@hidden; 
> address@hidden
> Subject: Juergen's makefile
> 
> 
> re: explaining the difference between Juergen's work and mine...
> 
> I've been continuing the build of the system and have only glanced at
> Juergen's work so this is (a) not intended as criticism and (b) not
> well founded and open to discussion.
> 
> First, there are dependencies beyond the 19 layers (I'm up to 
> 21 so far)
> but the compiles may be insensitive to these. I'm laying out 
> the lattice
> because without knowing these dependencies you can't build a 
> system from
> scratch. It is possible that after 19 layers there is no point in 
> continuing but (a) I haven't proven that and (b) I'm nearly finished.
> It would be good to figure out how many layers form the minimal set.
> 
> Second, remember that this Makefile is only really used to build the
> system from scratch. Once the algebra code exists it is reasonably
> insenstive to changes. In particular, changes to these 
> original algebra 
> files will have to be reviewed carefully before being made so 
> once there
> is a running version of the algebra all of this work is basically 
> documenation. If you need to build the system from scratch 
> on, say a 64
> bit architecture, you really need to understand why it is 
> built that way.
> 
> Third, Juergen's makefile looks a lot simpler as it is shorter and
> less verbose. This is, in fact, the trend I'm trying hard to correct.
> I'm simply unable to decode:
> 
> @ ( echo '1.$$s,${IN}/\(.*\)/.spad\.pamphlet:<<\(.*\)\.lsp .......
> 
> well, that's not strictly true but you get the idea. It is important
> to remember that I have Makefiles that look like this from long ago.
> I like the apparent brevity of the rules. However the machine 
> doesn't care
> if there are 3 or 300 rules but humans do and I need to work 
> with Juergen
> to reach some compromise. At the moment I'm just using very 
> simple rule
> forms rather than GNU make extensions. Dirt simple rules, in fact.
> 
> My main problem with the brief approach goes to the heart of the "new
> Axiom".  Juergen's makefile includes less than a dozen comment
> lines. But think carefully about what this Makefile is doing. It
> bridges the gap between the algebra world (where the files are
> organized into logical piles of categories, domains, and packages) and
> the method of constructing the world from scratch. It contains an
> ordering which is required but documented nowhere else. Why does this
> ordering exist? What does it imply about the algebra? How will someone
> 30 years from now figure out what to change, what it affects, and why
> it has that effect when the need to change the core algebra files?
> 
> Makefiles document how to build the system. One reason that it has
> taken so long to get a running system from the NAG sources is that the
> expertise of how to build the system (and it's associated makefiles)
> was lost. (Another reason is that you used to need an Axiom to build
> an Axiom.)  That is partially my fault from the past. I built
> Makefiles just like Juergen (and everybody else) does. I wrote
> Makefiles for the machine to read. But that is misguided. I can build
> a system (witness the downloadable version).  But I'm trying to build
> it so you guys can understand it, modify it, and maintain it. If we
> don't document it then nobody will be able to do these things and
> Axiom will die.
> 
> Juergen's makefile is basically a condensed version of mine and is
> correct (modulo the other layers). Use it to build and test 
> the algebra.
> However, the CVS version is going to end up as a pamphlet file that
> leans heavily on explanation. The current version you see has a great
> deal of "scaffolding" as I'm keeping build notes in the same file.
> These build notes are unnecessary and will be elided eventually.
> I need them to form the lattice. 
> 
> Again, this isn't a criticism of Juergen's great work. 
> 
> Tim
> address@hidden
> address@hidden



Juergen Weiss     | Universitaet Mainz, Zentrum fuer Datenverarbeitung,
address@hidden| 55099 Mainz, Tel: +49(6131)39-26361, FAX: +49(6131)39-26407

> 




reply via email to

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