axiom-developer
[Top][All Lists]
Advanced

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

Re: Relative vs. Absolute paths (was Re: [Axiom-developer] HyperDoc)


From: Gabriel Dos Reis
Subject: Re: Relative vs. Absolute paths (was Re: [Axiom-developer] HyperDoc)
Date: 09 Apr 2007 16:48:09 -0500

C Y <address@hidden> writes:

| --- Waldek Hebisch <address@hidden> wrote:
| 
| > Relative $AXIOM have to change when you change directory.
| 
| Um.  I'm not quite following you here Waldek - isn't that the whole
| point of relative linking?  We set $AXIOM once to define where the
| toplevel Axiom directory is located, and then everything else changes
| automatically?

Yes, the old build does that.  I did not change anything in that
respect.  The only thing that changed is what can be a value for
AXIOM.

| > This means that some variable settings have to be repeated.  Passing
| > of filenames to programs working in different directory become
| > harder.
| 
| Can you give an example?  I'm missing something, I think - what is the
| difference between having $AXIOM/lib/lib1.spad vs.
| /usr/local/axiom/mnt/linux/lib/lib1.spad?  If I am in $AXIOM/lib and I
| tell the program to output to $AXIOM/bin, or I want a file in ../input/
| or $AXIOM/input, (or for that matter $AXIOM/$INPUT if you want to
| generalize) those should Just Work.  Perhaps lisp has some limitations
| here?

I don't know.  I'm happy that I can re-root Axiom, and Axiom was
designed that way.  I'm unhappy about some other choices, but they
seem minor with respect to what I ran into.

[...]

| Shouldn't Axiom not care at all what drive or directory it is in? 

Absolutely.  
Furthermore, I really, really, really care that users should simply
say 

    ./configure && make && make install

and be done with it.  Most users don't want, or don't have time to
fiddle with the build machinery.  If the try two times and it did not
work, they are likely to stay away from Axiom, not matter how Great we
think it is.  That is a simple fact.  We can argue that we should have
many binaries that people can download, but that is a separate issue
that does not change the simplicity of the build -- personally, I
don't like downloading binaries unless it is properly signed and I can
trace back to the author in can it turned out to be a scam. 

Now, that simple requirement means that the complexity has to be
shifted somewhere else; I don't want the build machinery to be
complex; relative paths helped me port to windows in reasonable amount
of time, and I do consider it important to facilitate porting without
assuming much on the host system.  Although my primary machine
is now windows only (because GNU/Linux cannot fully support it), I don't
intend to become a windows developer -- I don't have the time for
that.  Consequently, it is important that I don't spend too
much time solving windows only issues.  Your mileage may vary.

-- Gaby




reply via email to

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