Roel Schroeven wrote:
Jeremy Jones wrote:
Andy Leszczynski wrote:
Is there any way to pass the prefix to the "make install"? Why "make"
depends on that?
A.
What does it matter? If you *could* pass it to make, what does that buy
you? I'm not a make guru, but I'm not sure you can do this. Someone
else better versed in make will certainly chime in if I'm wrong. But I
think make just looks at the Makefile and does what it's going to do.
If you want different behavior, you edit the Makefile or you get the
Makefile created differently with configure.
That way you could install to a different directory without having to
rebuild the whole thing. I don't think that uses case happens very
often, but I've certainly encountered it (not in relation to Python though).
I guess I'm still having a hard time understanding "what does it
matter?". Even if he reconfigures, he's not going to rebuild the whole
thing unless he does a make clean. For example, I just built Python
twice, once with a prefix of /usr/local/apps/pytest1 and then with a
prefix of /usr/local/apps/pytest2 and timed the compile:
BUILD 1:
jmjones@qiwi 7:16AM Python-2.4.1 % cat compile_it.sh
../configure --prefix=/usr/local/apps/pytest1
make
make install
../compile_it.sh 107.50s user 9.00s system 78% cpu 2:28.53 total
BUILD 2:
jmjones@qiwi 7:18AM Python-2.4.1 % cat compile_it.sh
../configure --prefix=/usr/local/apps/pytest2
make
make install
../compile_it.sh 21.17s user 6.21s system 56% cpu 48.323 total
I *know* a significant portion of the time of BUILD 2 was spent in
configure. So if he's really eager to save a few CPU seconds, he can
edit the Makefile manually and change the prefix section. Maybe I'm
just a slow file editor, but I would do configure again just because
it'd probably be faster for me. Not to mention potentially less error
prone. But he's going to have to build something again. Or not. He
*should* be able to just tar up the whole directory and it should "just
work". I moved /usr/local/apps/pytest1 to /usr/local/apps/pyfoo and
imported xml.dom.minidom and it worked. I'm guessing the python binary
searches relative to itself first (??). But if I move the python binary
to a new location, it doesn't find xml.dom.minidom.
JMJ