Project

General

Profile

Bug #712

External Libs: missing dependencies in Makefiles

Added by John Abbott almost 9 years ago. Updated over 4 years ago.

Status:
In Progress
Priority:
Normal
Assignee:
Category:
External Libs
Target version:
Start date:
18 May 2015
Due date:
% Done:

10%

Estimated time:
Spent time:

Description

The CoCoALib binaries related to Normaliz (e.g. ExternalLibs-Normaliz.o) do not depend on the Normaliz source files.

So currently, if you change the version of Normaliz, you must delete the corresponding dot-o files inside the CoCoA code tree, and then recompile. Simply recompiling (via make) does not recognise that the Normaliz files need to be rebuilt.


Related issues

Related to CoCoALib - Feature #573: Use symbolic links for external librariesClosed2014-06-18

History

#1 Updated by John Abbott almost 9 years ago

  • Description updated (diff)

#2 Updated by Christof Soeger almost 9 years ago

Depending on the source files would maybe be to much. It can not know how to recompile the external library.

What I would like is a dependency on the compiled libnormaliz.a. So that if I recompile libnormaliz, a make in CoCoAlib updates whatever needs an update.

Actually, make-dependencies should already create a dependency on the included headers. But in my tests it didn't. That would also be nice to have.

EDIT:
It looks like test-normaliz1 now nicely depends on libnormaliz.a, but not the CoCoAInterpreter.

#3 Updated by John Abbott about 8 years ago

  • Target version changed from CoCoA-5.1.3/4 Jan 2016 to CoCoA-5.2.0 spring 2017

#4 Updated by John Abbott over 7 years ago

  • Status changed from New to In Progress
  • Assignee set to John Abbott
  • % Done changed from 0 to 10

In a perfect world the CoCoA files which connect to external libraries should depend on the corresponding header files; and any executables should depend on the external binary libraries.

Unfortunately, I do not see how to do this in general.
If the external library is a "local installation" which has been identified by passing in paths to the header files and the binary library, then there should be no problem. If the external library has already been installed "in a standard place" then it could be rather harder to find out the full paths to the files for the dependencies.

Postponing.

#5 Updated by John Abbott over 7 years ago

  • Target version changed from CoCoA-5.2.0 spring 2017 to CoCoA-5.2.2

Postponing because I have no idea how to resolve this (certainly not in the near future).

#6 Updated by John Abbott over 6 years ago

  • Target version changed from CoCoA-5.2.2 to CoCoA-5.2.4

I'm not even sure if it is worth trying to resolve this... :-/

#7 Updated by John Abbott over 5 years ago

  • Target version changed from CoCoA-5.2.4 to CoCoA-5.3.0

#8 Updated by John Abbott over 4 years ago

  • Target version changed from CoCoA-5.3.0 to CoCoA-5.?.?

Also available in: Atom PDF