[Axiom-developer] Re: new/src/boot/Makefile.pamphlet

[root]

Dylan

> In my initial attempts to understand the compilation system, I found a
> minor problem: lines 165-168 of new/src/boot/Makefile.pamphlet read:
> 
> ----
> Integers start with a digit (0-9) and are followed by any number
> of digits.  The syntax for floating point numbers is
> <.I | I. | I.I> <E|e> <+ | - | empty> I where I is an integer.
> ----
> 
> which turns into goobledy-gook when TeXed, particularly the '<' and
> '>' signs.  How should I fix things like this?  Should I make a patch
> and send it to you, or should I check it into CVS directly?

Send me the patches directly. The CVS tree is rather static as I'm
working locally. This will change once the system compiles and I can
move the working sources to savannah. But for now, just send me the patch.

> 
> (I'm still getting oriented, so I won't be able to help much with
> substantive matters for a little bit.)

Not to worry, Axiom is a huge system with many layers and it takes
a while to figure things out and build up a good working environment.
I lost a lot of my tools once the project left IBM and I'm slowly
rebuilding them as I work.

> 
> The other thing that was annoying me was the hard-coding of the SPD
> path in the top-level makefile.

Ah, well, something seems to have changed in Make since it was last
used. I used to be able to take a shell variable (AXIOM) and do things
like: 

SPD=`basename $AXIOM`

and it would get executed. That fails now and I need to figure out the
new magic to make that work. Unfortunately my two attempts both failed
and I resorted to hard-coding them. It really annoys me also. In theory
you should just have to set the AXIOM shell variable and the Makefile
figures out all the subtree information, including the kind of system
to build. It used to be the case that setting the AXIOM variable to:

AXIOM=/spad/mnt/sun

would build a sun system. And

AXIOM=/spad/mnt/linux

would build a linux system. I can't figure out how to parse out the
basename at Make time. Seems trivial but ....

>                                    Also, why do you patch the noweb
> makefile to point to /tmp/null rather than /dev/null?  And have you
> submitted your patch to noweb to Norman Ramsey?  It seems like a very
> reasonable patch...

I have corresponded with Norman on several occasions. I've made some
changes to noweb that Norman feels should be done with gawk filters.
I'm a much better C programmer than a gawk programmer (in fact, I
never use awk or gawk) so I made changes in the C code. Since these
changes are not of interest to others (well, maybe the /dev/null)
and I haven't taken the time to learn gawk there is no common ground
to give back the changes. This really isn't Norman's problem, it's me.

It'll get worse in the future as I want the pamphlet files to have
more functionality. In the fullness of time I want pamphlet files to
be the publication standard for an Axiom Journal. A pamphlet file
should be able to be "dropped" onto a running Axiom. Axiom should
read the bibligraphy and recursively parse and load the referenced
pamphlets. (This way a referee could actually run the algorithm that
supports a research paper which now gets lost in a library).

Another design goal is that pamphlets form portions of larger works
(booklets). Booklets slice the pamphlets in various ways. So, for
instance, there can be a booklet of all the matrix domains in the
system (a horizontal slice) explaining all of the matrix operations
the system knows. Alternatively you can include the matrix pamphlet
into a booklet on digital filters where you explain digital filtering
concepts from the top level commands all the way down to the bits
(a vertical slice). 

The noweb chunks need some small syntactic changes (basically a URL
style syntax). These will not be of interest to Norman either so I
don't expect to have the patches included into noweb.

> 
> At some point, it will be necessary to change the Makefile to allow
> the option of using the versions of GCL, CMUCL, noweb, etc. that are
> already installed on the system.

You'll notice that the top level Makefile does nothing but build a
system-specific Makefile before proceeding. Changing the variables
in the top-level Makefile will change which system-specific Makefile
gets built. All of the system-specific information is customized at
that point. Ideally the AXIOM variable names the kind of system you
want to build and this automatically selects the system-specific 
version. It used to work this way and I was able to build on 12
different systems by simply 

 1) cross-mount NFS file systems to cover the src and int subdirectories
    For example, if I were going to build a Sun system I'd NFS mount
    src and int (these are read-only during the SECOND build) directories
    from the master machine
 2) set the AXIOM=/spad/mnt/Sun
 3) cd /spad
 4) make

I could build sparcs, powerpcs, intels, and symbolics (lisp-machine)
versions under solaris, linux, pc-dos with djgpp, aix, etc. I hope
to be able to do that again. This is why there are 5 different "major"
subtrees (src, int, obj, mnt, lsp).

It used to work and eventually it will all work again.
    
Tim