CoCoA » CoCoALib

To me it seems that approach (A) is less convenient and more risky/annoying (since any problem is reported only after compilation has finished).

Approach (B) would appear to have all the advantages (except that I have to implement it, while I have just finished implementing (A)... sigh!)

Can anyone see any potential problems with approach (B)?

NOTE: The CPP flags should be set before any of the existing header files is read. This could be done by putting them in the "preamble" of the unified header file". Having the #define directives at the very start means that any values supplied as part of the compilation command will effectively be ignored. Is this OK? One could argue that an external user should not "mess about with" the CoCoALib CPP flags. If necessary, I could add a check that the flags have not been defined.

• CoCoA_ULONG2LONG
• CoCoA_THREADSAFE_HACK
• CoCoA_DEBUG
• CoCoA_MEMPOOL_DEBUG
• CoCoA_WITH_BOOST
• CoCoA_WITH_READLINE
• CoCoA_WITH_NORMALIZ
• CoCoA_WITH_CDD
• CoCoA_WITH_FROBBY
• CoCoA_WITH_GFAN
• CoCoA_WITH_GSL
• CoCoA_WITH_MATHSAT

All settings referring to external libs have to ensure that appropriate flags are given to the linker!

Currently, if CoCoA_WITH_NORMALIZ is set then also the compilation option -Wno-long-long is set.

Currently, CoCoA_WITH_CDD and CoCoA_WITH_FROBBY are either both set or both unset.

NOTE I have just learned that if you press return while typing in the comment "subject" line, redmine then "finishes" the update (without giving you the chance to type in more details).

The flag CoCoA_WITH_READLINE is a red-herring: it applies only to CoCoA-5, and so should not really appear among the CoCoALib CPP flags.

Our handling (so far) of the flags CoCoA_DEBUG and CoCoA_MEMPOOL_DEBUG has been special: the options could be activated/deactivated by simply editing part of autoconf.mk and then recompiling -- Makefile dependencies are such that changing autoconf.mk triggers recompilation. Personally I find this approach convenient. I believe Anna has two separate subtrees, one for "optimized" CoCoALib, and one for "debugging" CoCoALib.

Up to now I have assumed that an installed version of CoCoALib would be an "optimized" version. Since CoCoALib is distributed as source code, I think it is reasonable to suppose that a person wishing to use CoCoALib with debugging active would have a private copy of CoCoALib (which can be configured as desired). Do you think this is reasonable?

I now have a first impl of the "preprocessor definitions" header file.

One question which has just arisen is the following:
in files such as ExternalLib-Normaliz.C there are two ways of achieving the effect of "compile only if CoCoA_WITH_NORMALIZ is defined"

Method (1)

#include "CoCoA/PREPROCESSOR_DEFNS.H" 
#ifdef CoCoA_WITH_NORMALIZ
...
#endif

Method (2)

// Copyright blah blah
// ..

#include "CoCoA/ExternalLibs-Normaliz.H" 
#ifdef CoCoA_WITH_NORMALIZ

...
#endif

Method (1) will probably be slightly faster (since the compiler does not have to read in a few lines of comments), but I doubt the difference is noticeable.

Method (2) avoids having to put an explicit #include "CoCoA/PREPROCESSOR_DEFNS.H" directive since it is already read by the header file.

Comments? Preferences?

The tests are producing strange results: it seems that there is some mysterious problem with the threadsafe counter :-/

NOTE I had forgotten this problem. Anyway it is now resolved (see #1048): there were some missing include directives in files refering to CoCoA_THREADSAFE_HACK