Design #933
Separate configure scripts for CoCoALib and CoCoA-5
Description
Currently there is a single configure
script for both CoCoALib and CoCoA-5. Strictly they should be separate.
Is it feasible to separate them? Is it worth doing so?
Related issues
History
#1 Updated by John Abbott over 7 years ago
- Related to Design #932: CoCoALib configuration: BOOST dependency added
#2 Updated by John Abbott over 7 years ago
- Related to Bug #757: readline: fix script for finding libreadline added
#3 Updated by Anna Maria Bigatti almost 7 years ago
- Project changed from CoCoA to CoCoALib
- Category changed from Philosophy to Portability
- Assignee set to John Abbott
- Target version set to CoCoALib-1.0
I'd rather not.
First of all, it works as it is.
Secondly, CoCoALib and CoCoA-5 are strictly related: nice to keep them strictly tied.
#4 Updated by John Abbott almost 7 years ago
Oh, I am of the opposite opinion.
Whatever solution we adopt, it should be as easy as possible to configure and build CoCoALib and CoCoA-5 together.
#5 Updated by John Abbott over 4 years ago
- Related to Support #1353: configure script help added
#6 Updated by John Abbott over 4 years ago
- Related to Feature #1360: configure script: add flags for "only cocoalib" or "both cocoalib and cocoa5" (for boost) added
#7 Updated by John Abbott over 3 years ago
- Related to Feature #1479: CoCoA release for linux: CoCoAInterpreter: with and without libreadline? added
#8 Updated by Anna Maria Bigatti over 1 year ago
Anna Maria Bigatti wrote:
I'd rather not.
First of all, it works as it is.
Secondly, CoCoALib and CoCoA-5 are strictly related: nice to keep them strictly tied.
I still think they should stay together.
We have added the flag --only-cocoalib (so that it does not look for boost)
#9 Updated by John Abbott over 1 year ago
- Status changed from New to In Progress
- Target version changed from CoCoALib-1.0 to CoCoALib-0.99850
- % Done changed from 0 to 10
The advantage of two separate configure
scripts is that they would be smaller (and more manageable?) than the one large, cumbersome script we currently have.
The disadvantage is that it would become more involved for anyone who wants to build CoCoA-5 (and GUI?) from source:
they would have to go through two separate configuration steps.
Maybe in this instance we should go with if it ain't broke, don't fix it
What we have currently seems to work adequately (but it is a pain to maintain).
We can stick with what we have until some future point where we are forced to
reconsider... we do have far more pressing matters to attend to.
Reject?
#10 Updated by John Abbott 3 months ago
- Target version changed from CoCoALib-0.99850 to CoCoALib-0.99880