Re: [Cp-tools-discuss] build

[Mark Wielaard]

Hi,

On Sun, 2002-05-12 at 16:29, Nic Ferrier wrote:
> 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?

I bought his (and others) The Goat Book and it has nice diagrams
explaining what is generated by what:
<http://sources.redhat.com/autobook/autobook/autobook_277.html#SEC277>
The Automake manual (for 1.6.1) says the same thing about generating
aclocal.m4 with acinclude.m4:
<http://www.gnu.org/manual/automake/html_mono/automake.html#SEC17>

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

I am still learning a lot about the autotools, but once we have
something that really works and is acceptable to everyone we should
certainly try to do that.

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

Yeah, but then gcj and jikes are not able to resolve package names. For
both compilers a get lots of warnings like:

Found 34 semantic errors compiling
"src/gnu/classpath/tools/doclets/xmldoclet/Driver.java":

    23. import com.sun.javadoc.*;
               <------------->
*** Error: Could not find package "com/sun/javadoc" in:
                /usr/share/java/libgcj.jar
                classes
                .

I haven't tried other compilers. Does this really work for you? Also
after cleaning the classes directory?

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

Yeah! Thanks. Will add a README this week.

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

Does the above code not work for you now (see below)?

The original code was as in the CVS module.
It was "obvious" because I couldn't find any references to examples for
a AC_STUBST that took multiple arguments, so I assumed it was some sort
of typo and recreated it from scratch (also because the Makefile.aj
didn't contain any GCJ_OPTS to replace in the first place).

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

Checked it in (but not yet renamed to acinclude.m4).

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

The online manual for 3.1
<http://gcc.gnu.org/onlinedocs/gcj/Input-Options.html#Input%20Options>
lists it as:
  --CLASSPATH=path Deprecated synonym for --classpath.

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

It is a pity that gcj 3.0 has it wrong.
I looked at how classpath detects what gcj version is in use and made
something that checks what classpath flag should be used.
I checked it in CVS. Can you test it on your system?

I did find a bug in how we test the JAVA_CC we use. If you just say
"JAVA_CC=gcj ./configure" then everything goes as expected. But if you
say "JAVA_CC=/usr/local/gcc31/bin/gcj ./configure" then the tests don't
pick up the fact that we are using gcj. Classpath does not have this
problem since it has explicit --with-gcj and --with-jikes configure
flags.

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

What/How is OSTYPE supposed to be set?

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

OK, I am seeing the light now. automakejar should do one thing simple
and that is not actually java targets but jar targets. Extending support
to Javadoc, native compilation, etc should be done in the Makefile[.aj].

Cheers,

Mark

P.S. My hacking time has decreased somewhat and the autotools are not
easy when confronted with them for the first time, so progress will be a
bit slow. But I am really getting excited about creating good build
environments with this stuff.