[Axiom-developer] Re: [Axiom-mail] Compiling Axiom on FreeBSD

[Mark Murray]

root writes:
> re: diff command. sure.
> 
> re: noweb. 
> 
> ummm, there are "short term" and "long term" discussions.  In the
> short term I'm just patching noweb. In the long term I have other
> plans and extensions. It won't be a "fork" of noweb so much as a
> rethink of the whole thing (probably with a complete rewrite). But
> that's longer term. For now the only extension is the "booklet" code
> by David Mentre. Literate programming is the goal; noweb is a useful
> tool. If you use the installed noweb be sure to use the axiom.sty
> file rather than the noweb.sty file.

Aaaah. OK. I remember that now. It is much easier for me, then just
to use our local noweb port, and snip it out of axiom. I'll make sure
that any local hacks get to find out about axiom.sty.

> re: bolt-on-the-side. 
> 
> This strategy has a lot of upsides and downsides.  One downside is
> that I have to get code to run on many different ports.  I'd rather
> face that problem and solve it. I want Axiom to build "out of the box"
> so I have to make sure the correct version is used and the correct
> patches are applied. The upside is that I can make sure that Axiom
> actually works on various platforms since I can (and do) test it. If I
> let the user choose "a version" or even "gcl-2.5.2" and build it
> themselves it is likely they will have build problems.  These build
> problems will make Axiom more painful to install.

Hmm.

> I agree that the bolt-on-the-side strategy is not optimal, that not
> everyone agrees that it is good, that it might duplicate existing
> code on an individual's platform, that it makes porting painful, 
> that it could (if we wanted to, but we don't) discourage giving
> patches back to projects, that it makes tracking external projects
> an issue, etc. 

Hmm^2.

> Nevertheless, I'm still of the opinion that bolt-on-the-side (BOTS?)
> is a higher-quality strategy for the Axiom pile. All the pain for
> the developers and none for the users.

Hmmm^3. :-)

> BSD port issues:
> 
> GCL-2.6.1 doesn't build there? I can restore GCL-2.5.2.tgz and you 
> can change the switch in the Makefile. All of the code to build
> 2.5.2 exists. I'd like to know what you needed to change for 2.6.1

2.6.1+ is closer to building than older version, so please don't
go backwards. :-) The freeBSD patches to make GCL-2.5.3 work are
sizeable and messy.

> To add your changes to the Axiom build there will be a global
> change to the AXIOM variable. It will end up being:
> 
> AXIOM=(yourpath)/mnt/BSD

I already have a patch that does this, but with s/BSD/freebsd/.

> and all of the changes for BSD will be buried in the Makefile
> stanzas at the top level. Setting this variable will cause a
> 
> Makefile.BSD 
> 
> file to appear (rather than Makefile.Linux) and this will be
> automatically invoked to apply the BSD changes (like using
> gcl-2.5.2 rather than gcl-2.6.1).

Right. My local build (functional, but not packaged), dikes out
the GCL build, and uses a FreeBSD GCL port (locally upgraded to
GCL-HEAD). This will be the most likely way that the FreeBSD port
will be built for distribution, as it works. The hacks/patches
to do this are small(ish), and the literate programming style
of axiom make this delightfully easy :-).

Re-engineering the FreeBSD/GCL-2.5.3 patches into Axiom is another
route, but will be an upgrading/maintenance nightmare for me, and
I'm very reluctant to go that way unless I can convice someone else
to maintain it ;-)

M
--
Mark Murray
iumop ap!sdn w,I idlaH