Re: [Cp-tools-discuss] build

[Mark Wielaard]

Hi,

On Fri, 2002-05-10 at 10:15, address@hidden wrote:
> The Paperclips aclocal includes a java compiler selection macro that I
> have contributed to the autocoinf macro store. It's compatible with ac
> 2.13 and ac 2.52 >.
> 
> The macro works exactly like the macros for selecting other
> compilers. You should use it where possible.
>
> > - Run 'ac_local' to create a 'aclocal.m4' file from the 'configure.in' 
> >   file. 
> 
> You don't need this step unless you've got other dependancies... 
> 
> For a java only project you just need to copy aclocal.m4 from the
> Paperclips directory and put it in the same dir as the configure.in
> script.
> 
> The aclocal is not strictly necessary, it just includes a nice java
> compiler selection macro.

OK, I see. But shouldn't your aclocal.m4 file actually be the
acinclude.m4 file? If I copy the aclocal.m4 file from paperclips to
acinclude.m4 and then run aclocal it automatically creates the
aclocal.m4 file including that macro. From the Classpath HACKING file:

        aclocal    - combines acinclude.m4 and system macros to produce 
                     aclocal.m4

The Classpath acinclude.m4 also includes some usefull autoconf macros.
Note to other readers, the GNU autoconf macro archive Nic talks about is
probably: http://www.gnu.org/software/ac-archive/

> > - Create a 'Makefile.aj' file as attached. 
> >   [XXX - insert some of the stuff that Nic said] 
> >   Note that it is a simplified version of the paperclips one. 
> >   PROGRAM variable added. SOURCEDIR added to classpath 
> >   (should probably not be necessary). 
> 
> SOURCEDIR should not be added to the CLASSPATH.

It is necessary for gcj at least, would it do any harm for other
compilers?

> Also, a "CLASSPATH" target is *really* useful, if you one you can do
> this:
> 
>    CLASSPATH=`make classpath`
> 
> which can save a lot of hassle.

O, now I see why you don't like SOURCEDIR in the CLASSPATH. We should
probably distinguish between a "sourcepath" and a "classpath", the first
should be used as input to the compiler, the second for the runtime (and
maybe even the jar/manifest creator).

> > - Add the attached 'automakejar' program to your project dir 
> >   and make sure it is executable (chmod 755 automakejar). 
> >  
> > - Run './automakejar Makefile.in' to create a 'Makefile.in' file from 
> >   your 'Makefile.aj' file. 
> 
> I'm going to change this step, perhaps tonioght I will check in a
> module in cp-tools with an altered automakejar that picks up the right
> makefile to alter.

Please, create such a module. That would make it so much easier to hack
on the framework and/or create real diffs for it. If you do that then I
promise to create the README document from our recent discussions on the
list.

> > - Run './configure' 
> >   (I don't seem to be able to do something like --with-gcj or 
> >    --with-javac which would be very nice. Same for --with-jar) 
> 
> These should be set with environment variables, my java compiler macro
> tries to behave just as a C compiler macro does.

OK, so you would do "JAVA_CC=gcj ./configure" or
"JAVA_CC=jikes ./configure". Good.
Hmmmm. It only actually works when removing config.cache...
Needs to document that then. It is then probably also a good idea to
write it as follows in the configure.in file:
AC_PROG_JAVA_CC(javac gcj jikes kjc)
That way it at least says "checking for javac..." at the moment it says
things like "checking for gcj... jikes" which is a bit confusing.

> There does need to be some concept of --enable-native-compilation but
> that's different from using GCJ as a java compiler.
> 
> Do you see what I mean?

Fair point. But it should default to yes if gcj is used I think.

> > - Run 'make' 
> >   This does not actually work since for some reason it detects gcj 
> >   but does not add -C to the JAVAC_OPTS, so add it manually. 

OK, I don't see how the original macro could have worked.
I changed it to this which seems to do the correct thing for me:

if test "$JAVA_CC" = "gcj"; then
   if test -z "$GCJ_OPTS"; then
      GCJ_OPTS="-C"
   fi
   JAVA_CC_OPTS=$GCJ_OPTS
fi
AC_SUBST(JAVA_CC_OPTS)

> >   Also when using gcj 3.0 -classpath overrides the system classpath, 
> >   so you should change it to -CLASSPATH by hand. 
> >   (Since this also works with gcj 3.1 I propose to make this the 
> >    standard switch when using gcj.) 
> 
> -CLASSPATH has been dropped in gcj 3.1 hasn't it? GCJ now only
>  supports -classpath which ocerrides the CLASSPATH env var and not the
>  system path (which is the same as the Sun behaviour).
> 
> I'd rather not change it, Bryce, Per, Tom, et al admitted that the
> -CLASSPATH/-classpath behaviour was a bug (because gcj didn't do what
> javac does).
> 
> It's possible that we could make the compiler selection macro detect
> GCJ 3.0 and set an env var for use as the -classpath switch.

-CLASSPATH still exists in 3.1, but you might be right that it should
probably be deprecated. What we could portably (gcj 3.0/3.1) do is split
the classpath and add the separate parts as -Ipart to the gcj command
line.

> > Some other observations: 
> > - The original check for make dist in the paperclips version didn't 
> >   detect my system as GNU/Linux :( 
> 
> HMmmm... seems odd.

The Makefile.aj contains the following test:
ifeq (${OSTYPE},linux-gnu)
But OSTYPE is never defined on my system.

> > - make dist includes lots of stuff, not just the distribution files. 
> > - For very simple Manifests you could create it from the main-class 
> >   argument (if added). 
> > - There is no make install or dist-check target. 
> 
> No. I don't use those really.

make dist should really be cleaned up and make install seems also
essential to me. Will see if I can come up with something.

> Note that the source Makefile (the Makefile.aj) for automakejar should
> not be prescribed. There are lots of things that you might want to do
> which we can't think of.

What does prescribed precisely mean in this sentence? English is not my
native language, and I am unable to parse the above correctly. I know
the word prescription, but that does not really make sense in this
context :) Do you mean that it should go away, or that we should not
give examples, because it will change to much?

> That's one reason why it would be nice if automake developed this
> functionality. Unfortunately there was absolutely no interest when I
> mentioned it on the java-people list.

We are just at a point where the free java tools are reaching maturity
so it does not surprise me very much that people haven't been very
interested in this before. But I am interested now. gjdoc seems like a
good testing ground for automakejar. We can talk to Tom Tromey later
about real automake integration.

Cheers,

Mark