Project

General

Profile

Bug #1600

Detect updated versions of external libs

Added by John Abbott almost 3 years ago. Updated 2 months ago.

Status:
In Progress
Priority:
Normal
Assignee:
-
Category:
Safety
Target version:
Start date:
14 Jun 2021
Due date:
% Done:

10%

Estimated time:
Spent time:

Description

Florian Walsh reported a compilation failure after updating BOOST on his (linux) system.
My understanding is that he used the package manager to update BOOST, but did not then re-run configure for CoCoALib.
This triggered a compilation failure.

Find a way to detect updated extlibs, and tell the user to reconfigure. (or somehow warn the user).


Related issues

Related to CoCoALib - Bug #1601: Compilation ambiguityClosed2021-06-16

Related to CoCoALib - Support #1700: boost_1_80_0Closed2022-10-14

Related to CoCoA-5 - Design #1696: Which BOOST libs are actually needed?Closed2022-08-18

History

#1 Updated by John Abbott almost 3 years ago

Some ideas and comments (for checks to make whenever trying to compile):
  • first idea: check whether some extlib header file is more recent than autoconf.mk; defect: how to find the path to the header file
  • next idea: have a script (for each extlib?) which determines the version; e.g. compile a file in /tmp and see what it prints out; advantage: we should have the necessary compilation flags to hand

Suggest for KISS: make these checks only from the main Makefile (at least for the first attempt at resolving)

#2 Updated by John Abbott almost 3 years ago

  • Related to Bug #1601: Compilation ambiguity added

#3 Updated by John Abbott almost 3 years ago

  • Target version changed from CoCoALib-0.99800 to CoCoALib-0.99850

#4 Updated by John Abbott over 1 year ago

#5 Updated by John Abbott over 1 year ago

Is this a duplicate of issue #1700?

#6 Updated by John Abbott over 1 year ago

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

Here is a copy of #1700#note-5 (which I closed because it duplicates this issue).

I wonder if there is a simple away to warn users of potential problems?

A similar problem could arise with any of the external libs, and the
solution is no doubt to rebuild dependencies -- and this should normally
be done by re-running configure (which may include some other "sanity
checks" for external libs).

Here is an idea:
for each ext lib configure computes a check-sum for some header file
in that ext lib, and saves the result in autoconf.mk. Then make
can verify that the check-sums are correct -- if not, a warning with
a delay, can be produced before proceeding with compilation.
[the delay gives the user a chance to hit Ctrl-C]

#7 Updated by John Abbott over 1 year ago

  • Related to Design #1696: Which BOOST libs are actually needed? added

#8 Updated by John Abbott 2 months ago

  • Target version changed from CoCoALib-0.99850 to CoCoALib-0.99880

Also available in: Atom PDF