Autoconf works pretty well as is. The CMD/head/head file
(or something close) is the key file to create. There are
a few tests that might need to be added to the autoconf
script to handle some of the shared library generation.
Libtool could also be used, but it's a pain if you're not
using it in combination with autoconf/automake. Using
automake/autoconf in each directory will result in an
estimated configure time-frame of about half an hour, due
to the extensive use of "sed" for substitutions.
The only real requirement for my current prototype makefile
setup is that source for libraries and executables be in
different directories. The grass-base "package" (module?)
would be configured, made, and installed first. All other
packages would be installed from either within the grass
environment, or with an environment variable set to point
to the grass installation (GISBASE?). As far as
modularization goes, I'm not sure what would be the best
way to partition the source into modules. I'm really a
very casual GIS user (mark trails with GPS, plot them on
USGS topographic data, add nearby roads if available, =).
As far as source reorganization, I would recommend a
structure similar to the following in CVS:
$CVSROOT - the root of the cvs repository
$CVSROOT/Grass-old/Grass-5.0/ - put the current Grass-5.0
codebase under here for reference
$CVSROOT/Grass/grass-base - the
$CVSROOT/Grass/module-one
$CVSROOT/Grass/module-two
$CVSROOT/Grass/module-three
Set up a CVS alias for the $CVSROOT/Grass directory in your
$CVSROOT/modules file, and for the modules:
grass Grass
module-one Grass/module-one
module-two Grass/module-two
module-three Grass/module-three
This way if you only need one or two modules, you don't have
to check out the entire source tree. But if you need to,
you can check out the entire source tree from a single alias.
Also, any convenient development scripts can be stored in the
top level of the Grass directory, for example, a master
"recompile everything" script, etc.
Markus Neteler wrote:
Hi Eric,
as you have started the new auto-conf for GRASS, I would
like to know your requirements for the new code structure.
We have to meet a set of ideas:
- make auto-conf working
- modularize the code
- each "package" (we need a better name here) should compile
of the core GRASS is there
-...
As you have worked on auto-conf, you have more insights than me
for the new source code structure.
Thanks in advance
Markus
y
--
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+
| Eric B. Mitchell mailto:emitchell@altaira.com |
| tel: (301) 809 - 3534 Altair Aerospace Corporation |
| tel: (800) 7 - ALTAIR 4201 Northview Dr. Suite 410 |
| fax: (301) 805 - 8122 Bowie, MD 20716 |
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+
,___
/"\ / o=\ /"""---===/
/ \_/ \__/ ---===/
| //\ || /""TT""/ //\ || ||""\
| // \ || || // \ || ||__/
| //--==\ |L--/ || //--==\ || || "=,
\ ---===/
\____---===/
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'