Re: [staf-devel] CVS Organisation

[Charles R. <ra...@us...>]

This note is addressing Point 2.  I responded to Points 1 and 3 in a
previous note.  As a word of caution, this note may ramble a bit, as I seem
to be having some difficulty putting a coherent line of thought together.
:)

To being with, I would point you to
http://www.pcug.org.au/~millerp/rmch/recu-make-cons-harm.html.  This
document was very influencial with regards to the current STAF build
system, as well as the source tree.

One thing that complicates matters is that the STAF project really has a
whole bunch of subcomponents.  I.e., STAF is not just a simple standalone
application, but is more akin to something like a GCC (although, granted,
not quite that big), in that there are a lot of pieces getting built.
Indeed, building GCC is rarely as simple as ./configure, make, make
install.  The last two steps are pretty straightforward, but the configure
step is generally something that requires a little bit of reading in order
to do it "right".  This is similar to the need to read (portions of) the
document you reference below in order to build STAF "right".

I actually like tools that follow the simple ./configure, make, make
install approach.  They tend to be very easy to get setup.  The one thing I
really, Really, REALLY don't like about most of these is how they build
everything in the source code directories.  I really prefer a system where
the source tree doesn't get touched during a build.  Now, this isn't
necessarily a strike against the autotools, as GCC strongly suggests (to
the point of effectively requiring) that you point the build output to
another directory instead of the source directory, and GCC does use the
autotools.  The way the current STAF build tree is structured is that given
a directory such as /build, then /build/src is where all source files
reside (this tree is never written to by the build system), /build/obj is
where intermediate files go (all temporary work happens here), and
/build/rel is where "released" files go (i.e., all the output of the
build).  In theory, there is also a /build/pkg tree where all "packaged"
files go (i.e., installable images go here).  This is why the CVS tree
starts at "src".

In theory, it should be possible to add "clean" and "install" targets to
the current makefile structure.  In theory, there is a "cleanup" target
which, I believe, is identical to your "clean" target, but I'm certain it
is broken at the moment.  Actually, "make clean" in the current build tree
is little more than (assuming you are in src/staf) rm -Rf ../../obj
../../rel.  I'm not sure what the "dist" and "distcheck" targets do.  Could
you elaborate?

The two autotools I'm most keen on are autoconf and libtool.  I like the
idea of being able to do a ./configure which will check which pieces of
STAF are buildable on your system (for example, Perl, Python, Tcl, Java,
and Rexx support would only be built on systems that had them installed,
etc.).  Plus, libtool looks like it might be handy in building shared
libraries (although we've already done most of the work to make this
simple).

Do you think it would be worthwhile to do the autoconf (and maybe the
libtool) work while leaving the makefile structure intact (with the
possible exception of adding some additional useful targets)?  I'm
concerned that the automake work would require a radical change in the
source structure, and I'm fairly happy with the current source tree.

I'm definitely interested in hearing your thoughts about all of this.
Anything to make the end-users and developers life with STAF easier is a
good thing.  I look forward to your feedback.

Charles Rankin
903/6C-006 T/L 678-2264



|---------+-------------------------------------->
|         |           Philip                     |
|         |           Willoughby/UK/IBM@IBMGB    |
|         |           Sent by:                   |
|         |           sta...@li...ur|
|         |           ceforge.net                |
|         |                                      |
|         |                                      |
|         |           04/29/2002 11:44 AM        |
|         |                                      |
|---------+-------------------------------------->
  >-----------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                       |
  |       To:       sta...@so...                                                                            |
  |       cc:                                                                                                             |
  |       Subject:  [staf-devel] CVS Organisation                                                                         |
  |                                                                                                                       |
  |                                                                                                                       |
  >-----------------------------------------------------------------------------------------------------------------------|



I have three changes to the source organisation to propose:

1: Reorganise the cvs repository so that the outermost module is `staf' and
not `src'. The module name `src' is hardly descriptive, and makes things
difficult for anyone trying to keep their devel box tidy and organised.

2: Make the Makefiles more sysadmin friendly -- we need rules for `make
clean' and `make install' at a minimum, but `make dist' and `make
distcheck' are very very useful for development.  I would suggest moving to
using GNU autotools (autoconf, automake, libtool, etc..) to facilitate
this, and I am willing to undertake this work if there is no reason to
believe it will be rejected.

3: Make the default installation top-level `/opt/staf' with symlinks to
core binaries in `/usr/local/bin'.  I can offer no justification for this
other than it is the normal unix way of doing things, and appears to be the
IBM standard as (on linux):
MQSeries -- /opt/mqm
NUL (Notes) -- /opt/nul
ISSI -- /opt/issi
eclipse -- /opt/eclipse
If you want further justification, I could find a formal document defining
this, but basically /usr/local is where locally developed/unpackaged stuff
should go, /usr is where vendor developed packaged stuff should go, and
/opt is where externally developed packaged stuff should go.

Point 1 is just a nit, but I would suggest changing it now while
development pace is low, and the number of people inconvenienced by any
change is small.  It needs to be done before 3.0 devel starts in earnest if
it is going to be done at all.

Point 2 is pretty essential, most people will be offput by a 35kb
Build/Installation document, and if we can replace this with the extremely
familiar extract->./configure->make->make install sequence that everyone
knows, IMO we should.  It will also make packaging it somewhat simpler.
Reasons not to are if autotools does not support a currently supported
platform, in which case things become more complex.

Point 3 is merely a matter of taste, but it does look more professional in
/opt (I think).

If you disagree with any of my views, fair enough, I am happy to go along
with the group decision on any of these points.

I'd appreciate hearing all of your views, especially on point 2, and if you
have any questions about the way autotools work I'll be happy to answer
them.

Regards,

Phil


_______________________________________________
staf-devel mailing list
sta...@li...
https://lists.sourceforge.net/lists/listinfo/staf-devel