Re: [Cp-tools-discuss] build

[nferrier]

Mark Wielaard <address@hidden> writes:

> Hi, 
>  
> On Fri, 2002-05-10 at 00:29, Nic Ferrier wrote: 
> > The latest version of automakejar is in the paperclips cvs. The 
> > version elsewhere works but there is a fix for a particular feature in 
> > the paperclips cvs version. 
> >  
> > The tool does not have it's own project or webpage yet. 
>  
> OK, I have something that almost works out of the box. 
> This seems simple and usefull. 
> It would be nice to at least create a CVS module for it. 
>  
> Note that some files have notices like: 
> # (c) Nic Ferrier - Tapsell-Ferrier Limited 2002 
> # 
> # You are free to redistribute this file. NO WARRANTY or fitness  
> # for purpose is implied by this notice. 
>  
> Which is not a real free software license since it does not permit 
> distributing changed versions. Not, that that stops me from distributing 
> modified versions in this email :) 

The only reason for that is I don't have a GPL template for sh-mode in
emacs (because I haven't been bothered to write one).

  
> - What are the dependencies precisely? 
>   I have aclocal (GNU automake) 1.4-p4 and Autoconf version 2.13. 

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.

Running ac_local does something that I don't really understand, to do
with C header files I think.
  

> - Run 'autoconf'. This creates a real 'configure' file from the 
>   'configure.in' and 'aclocal.m4' files. 

That's right.

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

Also, a "CLASSPATH" target is *really* useful, if you one you can do
this:

   CLASSPATH=`make classpath`

which can save a lot of hassle.
   

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

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

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?

  
> - Create a 'lib/manifest.mf' file as attached. 
>   The Main-Class attribute should point to the main class (duh). 
> 
> - 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. 
>   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.

  
> - Run 'gij -jar gjdoc.jar'. Yeah! 


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

HMmmm... seems odd.


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

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.

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.


> - Haven't looked at javadoc generation yet 
>   (which should be the ultimate bootstrap test for gjdoc!) 

I'm sure that a similar process to automakejar could automate a lot of
drudgery from writing javadoc targets.

However, javadoc targets are not as onerous to maintain as the sorts
of java targets that automakejar deals with, so it's not as important.


  
> Good night, 

Good work fella!


Nic