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

[Alex Lancaster]

>>>>> "JS" == Julian Scheid <address@hidden> writes:

JS> This is exactly the layout that I prefer and which I use for all
JS> my Java projects. A 'src' directory containing the Java sources,
JS> each stored in a directory corresponding to its package. I agree
JS> with you, Nic, that this is also the layout the average Java
JS> developer assumes.

JS> I was discussing a related issue with Alex on a different thread,
JS> he hasn't answered yet but I suppose he chose the 'flat' layout
JS> for TexiDoclet so that Automake works - am I right Alex?

Nope, it wasn't automake restrictions.  I didn't flatten it in the
savannah CVS, but only in making a module so that it was in a shallow
directory when you checked it out.  Also it was slightly easier for
packaging, but there's no intrinsic automake restrictions.

JS> Nic FYI: originally TexiDoclet distro layout was similar to your
JS> proposal. Alex flattened it, as I said probably because of
JS> Automake limits.

JS> Back then, I was glad that Alex took care of TexiDoclet and didn't
JS> object his decision at all (good that you're here my friend!)

JS> But even if it is your personal preference, Alex, I have to agree
JS> with Nic that the "deep" source directory approach is preferrable
JS> as it is the (pardon me::) standard Java way of doing things. If
JS> Automake is the reason for the flat TexiDoclet layout, we should
JS> drop it and use Autoconf only, tailored to our needs.

I think we should go for automake (perhaps suitably augmented with
Nic's proposed extensions) in conjunction with autoconf, as you can
leverage the macros that you would otherwise write just for your one
project in autoconf across many different projects.  I agree that Java
support in automake as it stands is rather weak, but it has been
improving and there seems to be quite a lot of new stuff over the last
year or so in the automake CVS.  Is Tom Tromey driving to get Java
better integrated?  Nic, what is the long-term strategy
w.r.t. automake & Java?

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

JS> In short, I support Nics suggestion. Looks very good.

Alex