cp-tools-discuss
[Top][All Lists]
Advanced

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

Re: [Cp-tools-discuss] build


From: Nic Ferrier
Subject: Re: [Cp-tools-discuss] build
Date: 12 May 2002 14:29:40 +0000

Mark Wielaard <address@hidden> writes:

> 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 

Oh. I don't know. I thought aclocal was local macros... This is what
the autoconf (2.52) manual has to say:


   "To create a `configure' script with Autoconf, you need to write an
Autoconf input file `configure.ac' (or `configure.in') and run
`autoconf' on it.  If you write your own feature tests to supplement
those that come with Autoconf, you might also write files called
`aclocal.m4' and `acsite.m4'.  If you use a C header file to contain
`#define' directives, you might also run `autoheader', and you will
distribute the generated file `config.h.in' with the package."

Maybe this is a 2.52 vs 2.13 thing. Asking an old hand might help,
maybe Tom Tromey?


> 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/ 

Maybe we should combine the two then.

On the subject of the macro archive it would be good to present a
GNU-Java tools section to them. They have a hotpotch of different
macros right now.

  
> > SOURCEDIR should not be added to the CLASSPATH. 
>  
> It is necessary for gcj at least, would it do any harm for other 
> compilers? 

Why is it necessary for GCJ?

Remember that GCJ doesn't need to know the "sourcepath" (ie: the
sourcedir) because the filelist it's given includes full paths.

Check the "filelist" file after a Paperclips build for example.


> 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). 

Nope, as above, you don't need a sourcepath.


> 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. 

I've done this. The module is called automakejar and it's in the
cp-tools repository.

I have assigned copyright to the FSF for automakejar. I haven't done
it for the aclocal.m4 yet... But I will do.


A good README would be really cool.


> 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. 

I wish it didn't say checking for gcj... it should say "checking for
java compiler" but I couldn't get the macro to do that portably.

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

I don't agree... compiling to native is different from making a jar
file, which is what automakejar does. We need to think hard about
native compilation and how it should be done generically.


> > > - 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) 

Hmmm... interesting. This was one of the problems I got when I made
the macro portable across 2.13 and 2.52 autoconf. I thought I'd fixed
that.

What was the original code you had? Why was it obvious that it
wouldn't work?

Your code seems remarkably similar to what I had originally and
didn't work.

I have checked in my version, can you test it again, if it doesn't work
apply your patch and I'll test it here (I use 2.52, you use 2.13 I
think).


> -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. 

-CLASSPATH and -classpath semantics have been swapped in 3.1. Trust
 me on that, the road was long and painfull.

-CLASSPATH's not *supposed* to be in there at all as far as I remember.

I will check that out.

I prefer not to decompose the path because that is specific to
GCJ... it's much better IMHO to try to keep the command for compiling
the same.

I suppose the compiler detect macro could add a switch env var, but
that's just one more env var to get confused about.


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

This is for detecting cygwin. I have Debian and it works that out
properly. I'm not sure why yours doesn't work.


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

Cool.

  
> > 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? 

I mean that we can't strictly define the contents of the Makefile.aj
for every project. If we do then it becomes harder to work out how to
integrate automakejar into other projects that don't meet the strict
requirements.

The good thing about automakejar is that it does one simple thing
very well. 

The good thing about Make is that it's a very powerful build
tool that can do just about anything.

automakejar makes Make easy to use for java targets.


Perhaps all I'm saying is that we need to keep a simple Makefile.aj
in the CVS module.

A more complex Makefile (one that has dist targets and so forth)
could also be kept in the CVS module but it's not necessary because
everyone knows how to write those targets (see the Make manual).

  
> > 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. 

Cool. I'm really glad you think it has potential.


Nic




reply via email to

[Prev in Thread] Current Thread [Next in Thread]