Re: [Cp-tools-discuss] build

[nferrier]

Mark Wielaard <address@hidden> writes:

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

Ok... but the autoconf manual is the bible, right? I really don't know
the answer to this.

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

I haven't tried gjdoc no... I do compile Paperclips, gnujaxp, gnu
crypto, etc... with GCJ without a problem.

I wasn't aware of this resolution problem, what exactly is it? That
it can't resolve names that are in jars? or what?


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

Hmmm... ok. I'm sure my one worked because I tested it using 2.13.

However, I can't get that excited about it. If yours works then fine.

  
> > > -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. 
>  
> 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'm sure it's fine. In general what are you doing here? Checking these
things into the automakejar module or checking them into both
automakejar module and gjdoc?


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

That's a macro fault then. It should probably get the basename or
something.

Things are so much easier in AC 2.52. Maybe it would be a good idea to
have 2 macros. I really don't know.


> What/How is OSTYPE supposed to be set? 

I've no idea. I presume 2.52 sets it and 2.13 doesn't. I'll try and
find out.

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

Exactly!

If automakejar was automake compatible then most of those things could
be done by automake.

I don't think automakejar is currently automake compatible, but it
would be a good thing if it was.


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

It doesn't matter whether my hacking time is minimal or extensive,
I always find the autotools confusing  /8->



Nic