[Top][All Lists]

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

[Gcl-devel] Re: Axiom uses unmodified GCL on Debian?

From: Camm Maguire
Subject: [Gcl-devel] Re: Axiom uses unmodified GCL on Debian?
Date: Wed, 14 Dec 2005 20:49:11 -0500
User-agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (Unebigory ōmae) APEL/10.3 Emacs/21.2 (i386-debian-linux-gnu) MULE/5.0 (SAKAKI)


root <address@hidden> writes:

> well, the build is proceeding and appears to be progressing ok.
> of course i have no idea WHY it works since there are no comments 
> in the patch file. i'll test the graphics and hyperdoc in the morning.

My apologies, Tim!  This is that same stuff I tried to document when I
was in your office last spring, and I think once on the list.  But the
general idea is that one can run ld (the linker used by gcc et.al.)
now from within gcl, so C libraries and objects can be incorporated.
One can even avoid compiling C source explicitly via command line gcc
by wrapping same in #'clines and using #'compile from within GCL.  The
only advantage here is to avoid patch rot against GCL source
makefiles, and to allow for the time saving ability to use a
pre-compiled GCL with the source tree no longer available.

> so code appears in debian 
> with changes that are not in the master source tree
> and is distributed under the name 'axiom'
> and you don't consider that a fork....

Please let me clarify here, not that I feel you you are expressing
alarm over this situation, but all Debian source trees have some build
modifications/patches perforce to enable the package to comply with
Debian policy.  A well designed package simply adds a debian
subdirectory with a few essential installation scripts, and a wrapper
makefile (called debian/rules) to provide the targets used by the
autobuilders.  Occasionally a patch to the upstream source will be
included, and again in well-designed cases, this is supplied in the
debian subdirectory and only applied when making the targets of
debian/rules, -- i.e. the freshly unpacked source tree is 'pristine'.  

I made the decision to build the Debian packages against the
pre-supplied gcl package not in an attempt to interfere with the
judgment or design goals of axiom, but rather simply as a practical
measure -- many of our autobuilders are very slow, and gcl is compiled
(and ansi-tested) on all of them already, and used by maxima and acl2,
so it really was a resource saver to enable axiom to be shipped on all
12 Debian platforms.

> but patching the original source files of gcl and noweb
> to build axiom (but not a gcl or noweb distro)
> is considered a fork?
> methinks you're being a bit harsh. forking is not intended
> in either case and i'd never claim camm is trying to fork
> axiom. we've had close cooperation over many years he's
> remotely logged onto my main laptop to debug the original
> SELinux failure and we worked together to corner an issue
> of semantics that was killing the axiom compiler. i have
> the greatest respect for him and wouldn't consider forking
> gcl under any circumstances.

And please let me say that I never thought otherwise.  I am more than
happy for Tim and anyone else to use the GCL source tree as they see
fit (other than to close it of course).  And the respect is mutual!

I would just suggest that as a member of the axiom team, we always
consider ways to increase the modularization of the code, as it should
be a time saver for us in the long run.  To this end, if there is ever
anything axiom needs in GCL proper, please let me know and I will try
to provide it.  I've made some attempts in this regard in the past,
though they are likely inadequate.

> the fact that debian changes are not integrated into the
> axiom source tree is likely due to miscommunication and
> lack of time or lack of understanding, not malicious intent.
> this needs to be fixed, though, as the debian version should
> be buildable from the master sources. i was under the impression
> that they were.

I believe that the 'external gcl' model was used by the BSD people
too.  If it is deemed desirable, perhaps we could supply an
external_gcl or some such target in the makefile and avoid interfering
with your preferred method.

Take care,

> sending (or resending) patch files that fix the differences
> is usually sufficient. 
> if you'll push the noweb changes all the way thru the build
> process and send patch files i'll 'fix' that also.
> t

Camm Maguire                                            address@hidden
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

reply via email to

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