[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Axiom-developer] Re: noweb "bug" (was: article "standard" header/footer
[Axiom-developer] Re: noweb "bug" (was: article "standard" header/footer)
Wed, 14 Dec 2005 13:34:34 -0500
you ARE aware that gcl includes things like bfd, binutils, gmp, etc.
axiom isn't the only package that includes upstream sources. the only
way i know to ensure that your product works as advertised is to make
sure that it works when you build it. and that requires certain
versions. in a perfect world this would not be a problem. consider the
details of the alternative you propose:
suppose a user gets gcl.
suppose gcl is built with -ansi.
suppose they get axiom as it is now.... axiom builds and works.
suppose they get axiom "with external gcl"... axiom build fails.
so "axiom is broken software" and "don't use axiom" becomes the meme.
we can't afford to have the new user dancing with version issues.
the overall PERCEIVED quality of axiom depends on it "just working".
given your suggestion how do you suggest we fix the gcl -ansi problem?
we could check the "native" gcl to see
(0) that the version is at least up to gcl-2.6.7 and
(1) that it does not include -ansi and
(2) that the native version includes the right maxpage configure
(although i don't know how) and
(3) that the bfd configure option was correct (although i don't know how). and
(4) that the compiler::link option is enabled (although i don't know how). and
(5) axiom has write access to the gcl library directories for the .o files and
(6) if one of those options is not correct
we could build our own version of gcl.
but that implies we have a tested version tgz file somewhere.
which we have now.
i understand your desire to not include gcl with the distribution
and i can see how it "simplifies" the build scripts if gcl "just worked".
but if you're going to suggest we pursue this path then we need
a plan to make sure that axiom "just works".
what's the plan?