Jean-Frederic, I see. I can agree with your question here, but notice that all this is doing is setting a shell variable whose contents are to be places into an included Makefile further down. With this syntax, that Makefile is dependent on a specific JAVA_HOME in the environment, yet another in its included file. That is whay my concern was. Notice that the existing 'config.sh' asks for which JAVA_HOME is desired. I think that it may actually be a good idea review this whole question about what it does and how it does it. I would, however, like to verify in a new autoconf-style configurator that the 'javac' and 'jar' utilities are present, just like the current 'config.sh' does. I've taken a look at your 'config_try.tar' file and worked it up some. Notice that 'support/apjava.m4' lines 40 and 43 contain extraneous ';;' statements. (Also notice that the recent updates, including the new 'refcount' GC algorithm is not represented here. Please see my SVN updates from Friday afternoon, latest rev being 329319.)
Let's talk some more about your autoconf code. I think it makes a nice candidate for a powerful configurator. Dan Lydick -----Original Message----- From: Jean-frederic Clere <[EMAIL PROTECTED]> Sent: Oct 31, 2005 1:48 PM To: [email protected] Subject: Re: [BootJVM] configure [EMAIL PROTECTED] wrote: >Jean-Frederic, > >I personally would rather see the Makefile pick up >the $(JAVA_HOME) environment variable instead >of the configuration shell script. By doing it this >way, you don't have to run the configuration again >when or if JAVA_HOME changes, lest the result >be a mixture of two JDK versions. Does this make >sense? > > My idea is to use autoconf... In this case it is very easy to redo configure: "./configure --with-java=$JAVA_HOME2 ..." Of course the JAVA_HOME have to be in a .in file included in Makefile for example Makedefs.in +++ [EMAIL PROTECTED]@ +++ The problem in the current config.sh is that it contains a Makefile syntax in a shell script... > >Dan Lydick > Dan Lydick
