CoCoA » CoCoALib

Anna suggested --only-cocoalib

JAA prefers that the default be "only cocoalib", and that an option must be given to build CoCoA-5 (as well).
JAA still prefers to have two separate configuration/build structure (see #933).

Some more possible names: --build-cocoa5, --no-cocoa5

It is probably better not to have names like --with-cocoa5 or --without-cocoa5 since we seem to use "with" flags to refer to external libraries.

Further ideas are welcome!

John Abbott wrote:

Anna suggested --only-cocoalib

JAA prefers that the default be "only cocoalib", and that an option must be given to build CoCoA-5 (as well).
JAA still prefers to have two separate configuration/build structure (see #933).

Some more possible names: --build-cocoa5, --no-cocoa5

It is probably better not to have names like --with-cocoa5 or --without-cocoa5 since we seem to use "with" flags to refer to external libraries.

I like --build-cocoa5. (not with!)
Makes a lot of sense that the default compilation of cocoalib is without cocoa5!

So readline and boost are not searched.
For the user who actually want cocoa5 (like us) we add the extra flag in the configuration.

The default without cocoa5 goes in the direction of the separate configurations.

It is not quite as simple as I wrote in the previous comment.

The option --with-boost= will automatically cause CoCoA-5 to be built.
Not entirely sure what --with-readline will cause; it is anyway just optional for CoCoA-5 (whereas BOOST is required).

What should happen if the configuration options say that CoCoA-5 should not be built, but a BOOST or readline library is specified?
Error? Warning?

In some ways I would like the options relevant only to CoCoA-5 to have names which make this clear(er). Or perhaps these options may be specified only after the option --build-cocoa5?

I have revised the configure options, and several auxiliary scripts (after feedback/suggestions from Anna & Ulrich)

• (A) New option --only-cocoalib (does not look for BOOST, does not compile CoCoA-5 or Qt-gui)
• (B) default is to compile everything (CoCoALib, CoCoA-5, Qt-gui): there is an option --no-qt-gui
• (C) if Qt is absent/insufficient then it is automatically skipped
• (D) if BOOST is absent/insufficient then an error is reported (unless --only-cocoalib was chosen)
• (E) all extlibs are now accessed via symlinks (no more "default linking")

Ulrich commented that he was disappointed that configuration did not produce autoconf.mk for CoCoALib
even when BOOST is absent. JAA prefers to give error & no autoconf.mk in his case because the command
as issued did fail: configuration for CoCoA-5 did not succeed. There is now a helpful error mesg.

Based on JAA's reasoning above (C) is not the correct behaviour: it should also give error if Qt fails.
Anyway, I'll leave the configure script as it is for the moment... too many changes!!

A motivation for (E) was that JAA discovered that there were 2 system installations of BOOST (one in
/usr/include and one in /usr/local/include), and it was not immediately obvious which would be
chosen as the "system default". With symlinks it is explicitly clear.

The BOOST "find" script does not give error if more than 1 installed version is found;
instead is simply picks one (the first it found), and produces a INFO message.

Presumably the GMP "find" script should do the same too... (maybe it does, not sure)

(This concerns an intermediate version of CoCoALib. The issue is not present in the current release 0.99800.)

John Abbott wrote:

Ulrich commented that he was disappointed that configuration did not produce autoconf.mk for CoCoALib
even when BOOST is absent. JAA prefers to give error & no autoconf.mk in his case because the command
as issued did fail: configuration for CoCoA-5 did not succeed. There is now a helpful error mesg.

Perhaps there is a misunderstanding here: The "command as issued" is a plain ./configure in the main CoCoALib directory. The (optional) CoCoA-5 front-end isn't mentioned anywhere.

Since CoCoALib doesn't require Boost I don't think the absence of Boost should cause an error when running CoCoALib's configure script.

John Abbott wrote:

Earlier we did try to implement a "make as much as possible" strategy, but this led to an
excessively complicated configure script (even worse than it is now).

I found this statement quite surprising (based on my recent tinkering with the build scripts) and then actually compared the line counts of three recent configure scripts: 0.99800 as released, the patched version from #1393#note-28 (which certainly does follow a "make as much as possible" strategy), and the latest development version that I got sent.

Whatever variation of line counting I tried (in-/excluding commented lines etc.), I didn't find much support for the latest version being much simpler than the others. (One sensible count is 1031, 1028, 1045, in the same order as above, and I'm not even sure I'd attribute the differences to "make as much as possible".)

Of course, mere line counting is an utterly simplistic approach and perhaps I'm missing something here. If so, I'd be curious (but it seems to me that "agree to disagree" is the likely outcome).

Ulrich may indeed be correct to be sceptical: the revision I made to the configure script made 2 changes at more-or-less the same time:

1. handle "system installed" libs the same as "non system installed"
2. semi-automatic choice about what is actually built (= "as much as possible")

I am fairly happy with the current structure.
My view is that the arguments to configure specify what the user wants to build (just CoCoALib, or also CoCoA-5);
the Qt-GUI is still decided automatically. In principle one could have a --build-as-much-as-possible flag.
I currently prefer giving an error if the user asks to build CoCoA-5 but some essential ingredient is missing.
What is important is that the error message should explain what the user can try doing to fix the problem
(e.g. BOOST too old or BOOST absent ... get new version from www.boost.org)

Presumably a "build as much as possible" could also print out explanations for why it is not building certain parts.

Speaking of which... I'll try improving the Qt-GUI failure message.

For the time being we'll not implement "build as much as possible", but instead give error if CoCoA-5 cannot be built (e.g. because of BOOST problems).

We think this may be more helpful if CoCoA-5 is compiled by some other script; if there's a problem then the error is signalled earlier.