Posted by william on Fri Mar 19 20:47:54 1999
In Reply to: But I'm only learning... (was Re: stop this religious war;) posted by Myles on March 19, 1999 at 17:26:48:
| Distribution: | paneris@i-way.co.uk |
|---|
multiboard@paneris.co.uk writes:
> Yep. Let's agree on a separation for shared libraries and code, and
> then it's down to the project leader on a project by project basis.I don't really understand that and I'm not convinced we're yet on the
same wavelength. However I know I take a very hardline position on
this and ymmv.> >What happens if you have a once-set CLASSPATH (at boot time) of
> >/usr/local/share/java/*, with symlinks out of there to everything you
> >want to include?
>
> Like that! Does help help with the webmacro problem, but I like it!although actually "once at boot time" won't really do for .jar files,
sorry, what I do on my machine is make "java" (or "kaffe" or whatever)
a wrapper which sets CLASSPATH to .../share/java/* and execs the real
java> ../paneris/util/java it is then.
shurely .../paneris/org/paneris/util ?
> Whoo! Heavy, man.
What do Tim and Tim think? I reckon TimP is going to like it a lot.
It's basically a very simple idea.
Example
The CVS comprises a completely unified tree like this:
org/
paneris/
utils/
*.java
*.pm
doc/
requirements/
*.{html,gif}
functional/ ...
...
guide/
*.{html,gif}
*.java (if there were examples in the user guide!)
genericadmin/
doc/ ...
webmacro/
doc/ ...
*.java
perlcgi/
doc/ ...
*.pm
...
projects/
sugar/
doc/ ...
module1/
doc/ ...
*.java
...
http/
doc/ ...
*.{html,gif}
webmacrotemplate/
doc/ ...
*.webmacrotemplate
...
Motivation
The idea is an absolutely rigorous division into functional units,
which attempts to achieve the following goals:
- things which shouldn't be separated, like code and
documentation, are made unlikely to be separated
- things that you might want to cross-refer between are kept near
to each other in consistent and obvious places
- groups of files which might comprise a circumscribed task given
to a developer are kept near each other
- you can run a site (or whatever) directly out of a development
tree checked out of cvs, without having to perform a spurious
"install" step
- making a runnable minimal installation (minus source and docs)
is trivial and foolproof
- Java and Perl sources are located in places which are
consistent with the package-to-directory mappings made by those
languagesThese aims aren't completely compatible with each other, but they
are mostly served by the following meta-goal: for any given operation
on the sources, there is a directory (or subtree) which contains all
and only those files. The directory structure you end up with depends
on which operations you feel require the most support from it.For instance, I reckon that it's better to support operations over
each module's sources and documentation (like copy them, search and
replace in them, cvs commit them, ...) than operations over all
sources and operations over all documentation. That is why I propose
a structure {module1,module2}/{src,doc} rather than
{src,doc}/{module1,module2}.
Details
All the code for all the languages we use goes in the same tree,
inducing an identical package namespace in Java, Perl and C++ (and
eventually ML). If some packages are programmed in two languages then
there are simply two kinds of source in the corresponding directory.Also in the same tree goes documentation (project docs and code
docs), HTML, templates, test data, any scripts needed for initialising
a database, backing up a site's data, etc. The functional unit rule
still holds: for instance, all the documentation lives in a
subdirectory under the project (or code module, or whatever) which it
documents.
Htdocs are perhaps different
"But," you will say, "if we want the installation directory
structure to mirror roughly the development directory structure, we
will end up with URLs like http://project.server/submodule/foo.html
rather than just http://project.server/foo.html". Tough titty."Furthermore," you will continue, "having a structure like
project/module1/Thing.java
project/module1/Thing-form.html
project/module2/Other.java
project/module2/Other-acknowledgement.htmlalong strictly modular lines rather than
project/module1/Thing.java
project/module2/Other.java
project/http/module1/Thing-form.html
project/http/module2/Other-acknowledgement.htmlmeans that if we simply point the web server at the development
directory, the sources (and documentation, ...) will be accessible
over HTTP."This is a real objection, and I think in this case we have to say
that the latter is better. I don't see any other way of achieving the
two important aims of (1) being able to run the site directly out of a
development tree, without having to do a spurious "install" step every
time we change some HTML, and (2) having a trivial and foolproof
installation procedure that relies only on where things are put in the
development tree and not on lots of special knowledge encoded in
Makefiles or scripts.Essentially the operations "present the project's development HTML
files to the browser" and "install this project's development HTML
files" are so important as to override the grouping suggested by the
other things we want to do with sources.In any case I suppose it's not necessarily true that the structure
of the http-visible files consistently follows that of the software
behind the site.
Source/object separation
Where there is compilation to be done, we support the possibility
of compiling into a completely separate directory tree from the source
tree checked out of CVS (that's a noop with Perl and trivial with
Java). I find this just makes life much easier once it's up and
running. Again, where you have separate .class files, let alone
separate .o/.obj files for different architectures, it makes
installing them without the sources even more trivial than it would be
otherwise.