Project

General

Profile

Feature #1050

ExternalLibs: function for getting info

Added by John Abbott about 7 years ago. Updated almost 7 years ago.

Status:
Closed
Priority:
Normal
Assignee:
John Abbott
Category:
New Function
Target version:
CoCoALib-0.99550 spring 2017
Start date:
24 Apr 2017
Due date:
% Done:

100%

Estimated time:
4.44 h
Spent time:
4.20 h

Description

I propose a new feature: CoCoALib should offer a function(s) for finding out which "external libraries" have been compiled in.

Several questions:
  • what should the function(s) be called?
  • in which file should the function(s) be defined?
  • what info should the function(s) produce?

Related issues

Related to CoCoALib - Design #1019: CPP flags in installed libraryClosed2017-03-05

Related to CoCoA-5 - Bug #1046: CoCoA-5 no longer lists the external libs presentClosed2017-04-13

Related to CoCoA-5 - Feature #711: External Libs: print credits?Closed2015-05-18

Related to CoCoALib - Feature #1219: Frobby version numberIn Progress2018-08-16

History

#1 Updated by John Abbott about 7 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 10

I propose putting the new function(s) in a new file called ExternalLibs.H (and ExternalLibs.C of course!).
This means that each time a new external lib is added, the files ExternalLib.H/C should be modified.

The information about each external lib should ideally contain the following:
  • name of the external lib (e.g. GMP or maybe libgmp?)
  • names of the main authors of the external lib (but this might be long)
  • version number of external lib (if this can be easily extracted from the lib itself)
Probably the information about an external lib should simply be in a struct: the fields could be called
  • myLibName
  • myAuthors
  • myLibVersion

I am thinking of a single function (name ExternalLibs, maybe) which returns a std::vector of the above structs. The order of the entries in the vector is unimportant (and could even change from run to run!).

#2 Updated by John Abbott about 7 years ago

  • Related to Design #1019: CPP flags in installed library added

#3 Updated by John Abbott about 7 years ago

An alternative file in which to put the function(s) is BuildInfo.H/C.

Advantage: no need to create any new files.
Disadvantage: perhaps not obvious that one should modify BuildInfo when adding a new external lib?

Comments?

#4 Updated by John Abbott almost 7 years ago

I have a first prototype (sent to Anna by email). Currently, it is just a program in examples/.

The main problem is finding an automatic way to obtain version numbers from the other libraries.

#5 Updated by Anna Maria Bigatti almost 7 years ago

John Abbott wrote:

An alternative file in which to put the function(s) is BuildInfo.H/C.
Advantage: no need to create any new files.
Disadvantage: perhaps not obvious that one should modify BuildInfo when adding a new external lib?

My first reaction was "yes! it is the right place!", but your second point made me reflect.
Now I'm convinced that ExternalLibs.H/C are the right places: easier to remember to update, and easier to find.

#6 Updated by Anna Maria Bigatti almost 7 years ago

John Abbott wrote:

I have a first prototype (sent to Anna by email). Currently, it is just a program in examples/.

OK, looks good.

The main problem is finding an automatic way to obtain version numbers from the other libraries.

That worries me a bit: I'd rather have two separate "suggested version" field and a "compiled with" field, so that there is no confusion. The first is obviously hand writen, the second is defined only if we can extract the information.

#7 Updated by John Abbott almost 7 years ago

I am not yet convinced that having 2 fields is a good idea.

We could simply set the field to UNKNOWN or maybe Unknown but >= v2.3.4 (since compilation would not succeed with older versions). Personally I prefer the simpler solution of just UNKNOWN. If the external library does not publish its version, the recommended version should be described in the documentation (e.g. configure --help), and it is the user's responsibility to check it.

#8 Updated by Anna Maria Bigatti almost 7 years ago

John Abbott wrote:

We could simply set the field to UNKNOWN or maybe Unknown but >= v2.3.4

OK

#9 Updated by John Abbott almost 7 years ago

  • Status changed from In Progress to Resolved
  • Assignee set to John Abbott
  • % Done changed from 10 to 70
  • Estimated time set to 2.22 h

I have just checked-in my implementation (after some cleaning).
I have also modified src/CoCoA-5/Banner.C so that it uses the new fn.

One change compared to previous code for listing the external libs is that now GMP is listed as well; JAA thinks this is probably desirable.

#10 Updated by John Abbott almost 7 years ago

  • Target version changed from CoCoALib-0.99560 to CoCoALib-0.99550 spring 2017

#11 Updated by John Abbott almost 7 years ago

  • Status changed from Resolved to Feedback
  • % Done changed from 70 to 80

I have checked in some documentation.

#12 Updated by Anna Maria Bigatti almost 7 years ago

  • % Done changed from 80 to 70

It says:

    info.push_back(ExternalLibInfo("libnormaliz",ToString(NMZ_RELEASE),"...

in my autoconf.mk it is called (and undefined)
NORMALIZ_VERSION=

#13 Updated by Anna Maria Bigatti almost 7 years ago

  • Related to Bug #1046: CoCoA-5 no longer lists the external libs present added

#14 Updated by Anna Maria Bigatti almost 7 years ago

Found missing include.
Also added mathsat and gsl

#15 Updated by Anna Maria Bigatti almost 7 years ago

I compiled and it works fine.
I don't much like the "lib" names:

With CoCoALib and external libraries GMP, libnormaliz, libfrobby, libgfan, libcdd, MathSAT

to my eyes it is less readable. I prefer the proper names like GMP. So I changed it.

But I think useful (in addition) the actual name of the "lib" file, together with the static/dynamic extension, so I started making this change, but I made the naive error to think that definitions in autoconf.mk are visible at compile time.
I'm checking in my work (now with "UNKNOWN lib..."), so that it is ready for updating it.

#16 Updated by John Abbott almost 7 years ago

  • Related to Feature #711: External Libs: print credits? added

#17 Updated by Anna Maria Bigatti almost 7 years ago

Anna Maria Bigatti wrote:

But I think useful (in addition) the actual name of the "lib" file, together with the static/dynamic extension, so I started making this change, but I made the naive error to think that definitions in autoconf.mk are visible at compile time.
I'm checking in my work (now with "UNKNOWN lib..."), so that it is ready for updating it.

checked in

#18 Updated by John Abbott almost 7 years ago

  • Status changed from Feedback to Closed
  • % Done changed from 70 to 100
  • Estimated time changed from 2.22 h to 4.44 h

While it may not be strictly correct to do it this way, I am closing this issue. We can proceed with the current implementation; if later it turns out that changes must be made then we will make them (via a new issue).

#19 Updated by John Abbott over 5 years ago

Also available in: Atom PDF