Jeroen Demeyer on Mon, 03 Nov 2008 10:46:32 +0100

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: One more ./Configure issue

Karim Belabas wrote:
* Jeroen Demeyer [2008-10-31 12:33]:
the following is an issue which I encountered while doing 32bit/64bit cross-compiling on a x86_64 GNU/Linux machine:

When using linux32 ./Configure, this setting will be forgotten during make. Once I have Configured PARI/GP as 32-bits it should remember that during make instead of checking again (the culprit is the @dir=`config/objdir`; line in the top-level Makefile).

This is intentional.

(1) To bypass it, just
  cd <your-objdir> && make <your-target>.
Thanks for this suggestion, I was not aware of this. I agree it is very useful to be able to build different versions from the same source tree.

(2) The reason for guessing $dir "at runtime" instead of hardcoding it at
Configure time is that my home directory is mounted identically on a
large number of different architectures. I can then use the very same
sources simultaneously on each of these architecture. And just type
'Configure' or 'make <my-target>' from my main workdir without bothering
to go to a specific directory first. This does simplify testing immensely
( and I'd rather include everything in a Makefile than depend on
external scripts/aliases )

I understand it makes cross-compilation slightly more difficult.
But I'd rather simplify development and testing than cross-compilation.
Well, there are other ways to solve this problem: the "GNU" way is to allow configure to be run from a different directory and then build everything in the directory where configure was called from. For example, inside the pari directory the user could create directories, say build32 and build64, and then do
../Configure && make
from inside those directories.

It is clear to me that PARI's Configure system has many good features; it just annoys me that it does many things in a *different* way than autoconf+automake.