[GRASS5] grass and re-autoconf - lots of questions

[Eric Mitchell]

I took a first crack at implementing a potentially "cleaner" 
makefile solution to grass tonight.  The main idea behind my
work is to get closer to the "standard" package installation 
process of "configure ; make ; make install", where "make" 
builds all the targets, and "make install" copies them to their 
final destination. This allows compilation to take place as a 
"regular" user, while the installation may require root access.
Also, installing to a non-default location requires tweaking
scripts in src/CMD, instead of simply specifying --prefix=/opt
and letting the make process take it from there. The "make" 
phase may also produce "runnable" programs within the make tree 
for trying out the program before installation.  In the case 
of grass, this would have to be an entire GISBASE layout, either 
copies of files, or links.  

I have the following to report:

1) The library layout is pretty confusing.  There are many
(i.e. more than 20) of them, in various levels of nested dirs
under src/libes.  Also, most of the header files for the libs
are in the src/include directory, away from the library source 
files themselves.  Many projects with multiple libraries tend 
to organize all the libraries under a single common directory,
and use the directory names in the include path of the headers,
e.g. #include <xxx/xxx.h>.  This lets the Makefile only specify
one directory (-I$(TOPDIR)/src/libes) and include files from
any library as needed, and eases maintenance of the 
src/CMD/generic/make.mid file.  Also, this keeps directories a 
little cleaner when installing headers to the final target 
directories for development, as the headers used don't end up 
under the $PREFIX/include directory, but the $PREFIX/include/xxx 
directory.  Reworking grass to use such a scheme is certainly 
a nontrivial effort, and most libraries don't seem to have 
dependencies on other libs so I've tried to work with the 
layout as is.  

Any thoughts on whether this would be worth pursuing right now?  
If grass is to be distributed in smaller pieces (core plus 
independent modules), this may be worth looking into.

2) Now that I've looked around a little, most of what I was 
putting into a platform specific makefile (a lot of blanks 
to be filled in by configure) is already done in the 
src/CMD/head/head file.  I see many platform specific head
files in the src/CMD/head/head/os_specific directory.  This 
is good news, as it's already done, mostly, and just needs
to be integrated with the new makefile scheme.  The only parts 
I see really missing are placeholders for shared library 
generation.  The GNU library creation tool, libtool, may be 
able to help out here.  It's a script that's supposed to handle
platform specific shared library construction details.

Are there any problems with requiring libtool for making 
shared libraries? (configure --enable-shared)

3) I have almost all the libraries referenced in the 
src/libes/Gmakefile building now. The last one (image3)
is causing problems, but I'm still looking into it.  Also, 
library validation and test programs (mostly named "try") 
may not be working yet. Building libs and executables in 
the same directory is a little flaky with my current set 
of common makefile rules.  This is still in the proof of 
concept stage, so a lot of the rules need tweaking.  I 
have a recursive descending Makefile that seems to be 
pretty good provided that there are no "leaf and branch" 
nodes in the build tree.  This is good in that you can
just specify which subdirs to descend into without 
modifying the master list(s) in src/CMD/lists

Summary: it's starting to take shape.  It looks like it'll 
I'll have to kick it around a little while longer before 
it's ready to show.  I'd like it to do about as much as a 
standard "make install" before letting it loose.  This will 
probably take two more nights of hacking, which translates 
into about two calendar weeks.

-- ebm
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+
| Eric B. Mitchell         mailto:emitchell at 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 internal mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'
length: 5585
max: 0