Project

General

Profile

Slug #792

configure: search for libgmp too slow

Added by John Abbott over 8 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Portability
Target version:
Start date:
02 Nov 2015
Due date:
% Done:

100%

Estimated time:
0.88 h
Spent time:

Description

I have new computer (here in Kassel). I am trying to build CoCoALib/CoCoA-5. The configure script took ages to decide that there are many different libgmp available.

Make this (much) faster!


Related issues

Related to CoCoALib - Bug #593: Temporary directories used during configurationClosed2014-07-20

History

#1 Updated by John Abbott over 8 years ago

The situation was the following. The new computer did not have GMP installed, so the attempt to use -lgmp failed, so configuration/gmp-find.sh then does a (recursive) find in the normal directories. I am pretty certain that it was the find command which was very slow.

I am installing the newest GMP (v.6.1.0) on the new computer, and note that also the GMP configuration process is very slow -- I think most files are stored on a separate server, and suppose the communication costs a lot of time.

#2 Updated by John Abbott over 8 years ago

Since I believe that the find command is the culprit, the solution would be to eliminate it. This could be done by making the list of "usual places" more thorough, so that it includes all directories (not just directory roots).

#3 Updated by John Abbott about 8 years ago

  • Related to Bug #593: Temporary directories used during configuration added

#4 Updated by John Abbott over 4 years ago

  • Status changed from New to In Progress
  • Assignee set to John Abbott
  • Target version changed from CoCoALib-1.0 to CoCoALib-0.99700
  • % Done changed from 0 to 50

I think this may already be almost done. Let's finish it soon!

#5 Updated by John Abbott over 4 years ago

  • Status changed from In Progress to Closed
  • % Done changed from 50 to 100
  • Estimated time set to 0.88 h

On my main machine gmp-find.sh (with SSD) takes less than 1s; on the little "netbook" it took about 2.8s.
Faster might be nicer, but it is hardly important.
Closing as the current impl seems to be fast enough...

Also available in: Atom PDF