Re: [Cp-tools-discuss] shape of the CVS

[Nic Ferrier]

Julian Scheid <address@hidden> writes:

>  
> This is exactly the layout that I prefer and which I use for 
> all my Java projects. A 'src' directory containing the Java 
> sources, each stored in a directory corresponding to its 
> package. I agree with you, Nic, that this is also the layout 
> the average Java developer assumes. 
>  
> I was discussing a related issue with Alex on a different 
> thread, he hasn't answered yet but I suppose he chose the 
> 'flat' layout for TexiDoclet so that Automake works - am I 
> right Alex? 
>  
> Nic FYI: originally TexiDoclet distro layout was similar to 
> your proposal. Alex flattened it, as I said probably because 
> of Automake limits. 
>  
> Back then, I was glad that Alex took care of TexiDoclet and 
> didn't object his decision at all (good that you're here my 
> friend!) 
>  
> But even if it is your personal preference, Alex, I have to 
> agree with Nic that the "deep" source directory approach is 
> preferrable as it is the (pardon me::) standard Java way of 
> doing things. If Automake is the reason for the flat 
> TexiDoclet layout, we should drop it and use Autoconf only, 
> tailored to our needs. 

One of the reasons I don't worry about the src directory is that I
don't use automake.

I have a generalized Makefile for java code. It only uses make stuff,
no special automagic but it links in very well with autoconf.

It doesn't do proper dependancy checks (I don't think automake does
either though, without extra effort) but it does give some dependancy
checking. 

It works by generating a filelist of the source files that need to be
compiled (which by default is done by comparing the .class file for
the equivalent .java file) and then compiling that list with:

  $(JAVAC) -d classes/ @filelist

It's perfectly adequate for user builds and for developers.

I am (just now in fact) working on some autoconf macros for java
support, stuff like an AC_PROG_JAVAC and so forth. The resulting
macros will be usable to configure the makefile.

Who knows? My java rules might eventually make it into automake, but
for now the Makefile is easily maintained separately.


Brian Jones has promised to consider use of this Makefile for
Classpath.

 
> BTW the deep way is also a better structure because you don't 
> have tens or hundreds of java source files cluttered in one 
> directory. You have source files sorted by package, i.e. by 
> software module, or function, which is a good thing. 

You can also add a trick that I do with paperclips. One of the
problems when writing tools is that running the tool from java
(or using command line tool support) requires the fully qualified
name. With Paperclips I have a class called:

   gnupaperclips

which simply calls my normal "main" class. Note this class is in the
top-level but very unlikely to cause any name clash.

If you don't use the src/ convention then you have this rather
forlorn top-level class in your package directory.


> In short, I support Nics suggestion. Looks very good. 
>  
> (Nic I suppose the 'k' in gnu/gkjdoc is a typo. The full 
> package path would be gnu/classpath/tools/gjdoc/.) 

Of course.


Alex? Do you want to respond to this?


Nic