if the "make" command causes "./configure" to be called (presumably because it has just been regenerated), it does not reuse the options that ./configure was last called with. For example, I did this:
./configure --prefix=$HOME make make install
and then it wanted to install in /usr/local because "make" reran "./configure" without any options.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Mathieu Bouchard wrote:
if the "make" command causes "./configure" to be called (presumably because it has just been regenerated), it does not reuse the options that ./configure was last called with. For example, I did this:
./configure --prefix=$HOME make make install
and then it wanted to install in /usr/local because "make" reran "./configure" without any options.
the only solution i see for this, would be to remove configure and aclocal.ac from the respository (they are generated anyhow)
any objections?
mfga.dsr IOhannes
On Wed, 27 Sep 2006, IOhannes m zmoelnig wrote:
if the "make" command causes "./configure" to be called (presumably because it has just been regenerated), it does not reuse the options that ./configure was last called with.
the only solution i see for this, would be to remove configure and aclocal.ac from the respository (they are generated anyhow) any objections?
Yes, because your solution doesn't solve the problem. Whenever configure.in changes (usually by cvs update), the settings will be reset.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Mathieu Bouchard wrote:
On Wed, 27 Sep 2006, IOhannes m zmoelnig wrote:
if the "make" command causes "./configure" to be called (presumably because it has just been regenerated), it does not reuse the options that ./configure was last called with.
the only solution i see for this, would be to remove configure and aclocal.ac from the respository (they are generated anyhow) any objections?
Yes, because your solution doesn't solve the problem. Whenever configure.in changes (usually by cvs update), the settings will be reset.
so i guess your solution would be to not automatically generate Make.config via the makefile.
mfg.adsr IOhannes
On Wed, 27 Sep 2006, IOhannes m zmoelnig wrote:
so i guess your solution would be to not automatically generate Make.config via the makefile.
Is there any way to retrieve the arguments that ./configure was last invoked with?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Mathieu Bouchard wrote:
On Wed, 27 Sep 2006, IOhannes m zmoelnig wrote:
so i guess your solution would be to not automatically generate Make.config via the makefile.
Is there any way to retrieve the arguments that ./configure was last invoked with?
i have now implemented something like this in Gem's build system.
whenever make calls "configure" it will use the options used at the last successfull run of configure. you can set these options by either running configure explicitely ('./configure --with-pd=/dev/null') or via evironment variables ('CONFIGUREFLAGS="--with-pd=/dev/null" make')
i hope this solves your problem.
other magic, like using environment variables to change configure's output will not be preserved (but should work in the same environment)
mfg.asdr IOhannes
Mathieu Bouchard wrote:
On Wed, 27 Sep 2006, IOhannes m zmoelnig wrote:
if the "make" command causes "./configure" to be called (presumably because it has just been regenerated), it does not reuse the options that ./configure was last called with.
the only solution i see for this, would be to remove configure and aclocal.ac from the respository (they are generated anyhow) any objections?
Yes, because your solution doesn't solve the problem.
even if removing aclocal.ac and configure does not solve your problem, are there any objections to remove these?
(they shouldn't be in there at all; i think i have checked them in, because i had problems generating them on os-x (a long time ago!); these problems are gone now, so the generated files should vanish)
fm.adr IOhannes
On Wed, 18 Oct 2006, IOhannes m zmoelnig wrote:
even if removing aclocal.ac and configure does not solve your problem, are there any objections to remove these? (they shouldn't be in there at all; i think i have checked them in, because i had problems generating them on os-x (a long time ago!); these problems are gone now, so the generated files should vanish)
Because everyone expects a source tarball in which ./configure already exists and that things are in a way cleaner if the tarball is *exactly* the same as a cvs export.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Mathieu Bouchard wrote:
On Wed, 18 Oct 2006, IOhannes m zmoelnig wrote:
Because everyone expects a source tarball in which ./configure already exists and that things are in a way cleaner if the tarball is *exactly* the same as a cvs export.
hmm... i expect a INSTALL.txt, where i can read how to build. if it says "aclocal && autoconf && ./configure && make" i can understand this and follow. (however, it adds more dependencies to build)
in theory Gem's build system just needs "make" (and does the rest on its own). since flags to configure are needed, i am thinking about using some environment variable for configure-flags:
~> make CONFIGURE_FLAGS="--with-pd=/bi/ba/bo"
would then run: aclocal autoconf ./configure --with-pd=/bi/ba/bo make
i don't understand why things are cleaner if tarballs and CVS export are the same. (it might give you less worried users, but that has nothing to do with cleanliness)
mf.asdr IOhannes
-
IOhannes m zmoelnig -
Mathieu Bouchard