Hi all
I have just two questions about grass (5.7 as it's the devel path).
1. Why is grass not build shared as standard and an alternative as static version? (likely because it comes from some old ugly system)
2. Why is the directory structure in the sources and the installed files that chaotic? (likely it's grown that way)
What about cleaning these things up and using GNU autotools for building.
I hope you don't kill me now.
Jens Oberender
On Wed, 12 Nov 2003, Jens Oberender wrote:
Hi all
I have just two questions about grass (5.7 as it's the devel path).
1. Why is grass not build shared as standard and an alternative as
static version? (likely because it comes from some old ugly system)2. Why is the directory structure in the sources and the installed files
that chaotic? (likely it's grown that way)What about cleaning these things up and using GNU autotools for building.
(was that three questions?) Very good questions too, we really hope that
you will join the efforts too, all help is valuable. If you track
discussion on this list, you will see lots of similar questions. Choose a
particular itch and scratch it, and be sure to contribute your
experiences!
I hope you don't kill me now.
Not kill, invite!
Roger
Jens Oberender
_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5
--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Breiviksveien 40, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 93 93
e-mail: Roger.Bivand@nhh.no
On Wed, Nov 12, 2003 at 10:45:29AM +0100, Jens Oberender wrote:
Hi all
I have just two questions about grass (5.7 as it's the devel path).
1. Why is grass not build shared as standard and an alternative as static
version? (likely because it comes from some old ugly system)
Because compilation will still fail on some platforms. Just use
--enable-shared
2. Why is the directory structure in the sources and the installed files
that chaotic? (likely it's grown that way)
Is it? The intention was to clean up the structure.
While
- 5.3-cvs contains 1.x million lines of code
- 5.7-cvs "only" contains 450000 lines of code in a rather plain structure.
Just post some examples where you don't like the structure (we are open to
new ideas).
What about cleaning these things up and using GNU autotools for building.
See this comment:
http://grass.itc.it/pipermail/grass5/2002-April/009033.html
I hope you don't kill me now.
Why we should?
But what would you like to be have cleaned?
Markus
Hi Markus
Because compilation will still fail on some platforms. Just use
--enable-shared> 2. Why is the directory structure in the sources and the installed files
> that chaotic? (likely it's grown that way)Is it? The intention was to clean up the structure.
While
- 5.3-cvs contains 1.x million lines of code
- 5.7-cvs "only" contains 450000 lines of code in a rather plain
structure.Just post some examples where you don't like the structure (we are open to
new ideas).
Looks like I were pert and premature with my mail.
I only compiled 5.0.3 and 5.3-snapshot. 5.7-snapshot didn't compile, but I
tried it only once last week.
I didn't look close to the sources of 5.7, only 5.0 and 5.3. My statement
footed on those two. 
The 5.7 sources look very clear, but I can't say anything about the the
finish installation.
The problem with building shared (5.0) is, that some stuff isn't build, for
example the man pages aren't created.
> What about cleaning these things up and using GNU autotools for
> building.See this comment:
http://grass.itc.it/pipermail/grass5/2002-April/009033.html
To fix that problem with building shared I worked my way through the
Makefiles.
And that was very complicating.
My opinion is that the autotools stuff is clearer and more powerful, but I
don't have any experiences with such a huge project as grass.
Perhaps I can help somehow.
Sorry!!!
Jens Oberender
Jens Oberender wrote:
The problem with building shared (5.0) is, that some stuff isn't build, for
example the man pages aren't created.
Huh? By "building shared (5.0)" are you referring to the stuff in the
"mk" subdirectory? That *should* build the man pages (both nroff
source and formatted text); it does on my system.
> > What about cleaning these things up and using GNU autotools for
> > building.
>
> See this comment:
> http://grass.itc.it/pipermail/grass5/2002-April/009033.htmlTo fix that problem with building shared I worked my way through the
Makefiles.
And that was very complicating.
My opinion is that the autotools stuff is clearer and more powerful, but I
don't have any experiences with such a huge project as grass.
Using additional tools just adds to the number of tools whose
behaviour I need to understand. It's far easier for me to just write a
Makefile than to figure out how to get e.g. automake to produce the
Makefile I want.
And, if you think that reading a Makefile is complicated, try reading
the libtool source (ltmain.sh). FIVE AND A HALF THOUSAND lines of
Bourne shell script; it's completely incomprehensible. And when it
doesn't do what you want out of the box (which, for me, is always, as
it always seems to add a -rpath switch which I don't want), it's
impossible to figure out how to make it do what you want (with the
-rpath issue, I gave up and modified "ld" to ignore that switch).
These kinds of tools are fine if you're willing to experiment with the
input file until you get something that appears to work, and you don't
really care about what it's actually doing or why. If you are
concerned about what is actually happening, and having the ability to
change it subsequently, they just make life harder.
AFAICT, the main reason why people use libtool is that, unfortunately,
shared libraries are highly non-standard. Every OS has its own
peculiarities (particularly Windows, which makes all other platforms
look straightforward). Building shared libraries on many different
platforms requires a database of "incantations" for all of the
different platforms. Accumulating this knowledge is a lot of effort
so, when it is available elsewhere (i.e. libtool), people are willing
to use it, even if it's provided in the most inconvenient form
imaginable (as is the case for libtool).
I'd rather just ensure that the build system is sufficiently flexible
to accomodate all plausible options, and add the invocations for
particular platforms as they are contributed. This assumes that, for
each platform, we can find out how to build shared libraries on that
platform.
But, realistically, we need that sort information anyway, shared
libraries or not. If we don't have a developer who actually knows how
to build code on a particular platform, that platform is never really
going to be "supported" (e.g. on MacOSX, much of the actual work has
been done by people who don't even have access to a Mac, but have
occasionally managed to squeeze sufficient information out of Mac
users who have problems).
--
Glynn Clements <glynn.clements@virgin.net>
Hi Markus
> Looks like I were pert and premature with my mail.
> I only compiled 5.0.3 and 5.3-snapshot. 5.7-snapshot didn't compile,
> but IWhy? Error (please post to the list)?
Here is the Error:
make[2]: Entering directory
`/usr/src/packages/BUILD/grass57_exp_2003_11_08/lib/gis'
gcc -I/usr/src/packages/BUILD/grass57_exp_2003_11_08/include
-I/usr/src/packages/BUILD/grass57_exp_2003_11_08/dist.i686-pc-linux-gnu/i
nclude -O2 -g -march=i586 -mcpu=i686 -fmessage-length=0 -Wall
-Wconversion -Wno-implicit-int -fPIC
-I/usr/src/packages/BUILD/grass57_exp_2003_11_08/include
-I/usr/src/packages/BUILD/grass57_exp_2003_11_08/dist.i686-pc-linux-gnu/i
nclude \
-o OBJ.i686-pc-linux-gnu/adj_cellhd.o -c adj_cellhd.c
adj_cellhd.c: In function `G_adjust_Cell_head':
adj_cellhd.c:44: error: `PACKAGE' undeclared (first use in this function)
adj_cellhd.c:44: error: (Each undeclared identifier is reported only once
adj_cellhd.c:44: error: for each function it appears in.)
make[2]: *** [OBJ.i686-pc-linux-gnu/adj_cellhd.o] Error 1
make[2]: Leaving directory
`/usr/src/packages/BUILD/grass57_exp_2003_11_08/lib/gis'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory
`/usr/src/packages/BUILD/grass57_exp_2003_11_08/lib'
make: *** [default] Error 1
And the configure I use:
./configure --with-postgres-includes='/usr/include/pgsql
/usr/include/pgsql/libpq /usr/include/pgsql/server' --with-freetype
--with-lapack --with-blas --with-readline --with-dbm --with-cxx
--with-freetype-includes=/usr/include/freetype2 --with-motif
--with-motif-includes=/usr/X11R6/include --with-glw --with-nls --with-gdal
--with-grass50=/usr/src/packages/BUILD/grass53_exp_2003_11_08
I didn't have a closer look at it!
> tried it only once last week.
> I didn't look close to the sources of 5.7, only 5.0 and 5.3. My
> statement footed on those two.That was not really clear before.
> The 5.7 sources look very clear, but I can't say anything about the
> the finish installation.We do autocompilation every Saturday morning:
http://grass.itc.it/grass51/binary/linux/
It successded at least on Nov 8. Of course it may be possible that
errors were introduced later. So it would be useful to know
before next Saturday> The problem with building shared (5.0) is, that some stuff isn't
> build, for example the man pages aren't created.Are you sure?
Try
grep html src/CMD/lists/GRASSshould print 'html'. If not, you are right (then post it to the list).
It prints html, but it isn't built!
The error is here:
mk/Makefile.in:
binaries:
@echo "making binaries ..."
echo "Start of compilation: "`date` > ${ERROR_LOG}
-cat ${SRCDIR}/src/CMD/lists/GRASS
${DSTDIR}/src/CMD/lists/optional | \
grep -v '^ *#' | grep -v '^ *$$' | grep -v '^html$$' | \
while read dir ; do \
mkdir -p $$dir ; \
${MAKE} -I${DSTDIR}/mk -I${SRCDIR}/mk -C
${SRCDIR}/$$dir -f makefile || \
echo "Compilation error in module: $$dir"
${ERROR_LOG} ; \
done
echo "End of compilation: "`date` >> ${ERROR_LOG}
> > > What about cleaning these things up and using GNU autotools for
> > > building.
> >
> > See this comment:
> > http://grass.itc.it/pipermail/grass5/2002-April/009033.html
>
> To fix that problem with building shared I worked my way through the
> Makefiles.
> And that was very complicating.Yes, the Makefile system in 5.0/5.3 is a nightmare.
In 5.7 it's much more standard, but could be even better.> My opinion is that the autotools stuff is clearer and more powerful,
> but I don't have any experiences with such a huge project as grass.
>
> Perhaps I can help somehow.Yes: Apply the autotools to GRASS 5.7 and post the patches. If it is
liked, we could apply it.
Perhaps I'll have a look at it! 
Ciao,
Jens Oberender
Jens Oberender wrote:
> > Looks like I were pert and premature with my mail.
> > I only compiled 5.0.3 and 5.3-snapshot. 5.7-snapshot didn't compile,
> > but I
>
> Why? Error (please post to the list)?Here is the Error:
make[2]: Entering directory
`/usr/src/packages/BUILD/grass57_exp_2003_11_08/lib/gis'
gcc -I/usr/src/packages/BUILD/grass57_exp_2003_11_08/include
-I/usr/src/packages/BUILD/grass57_exp_2003_11_08/dist.i686-pc-linux-gnu/i
nclude -O2 -g -march=i586 -mcpu=i686 -fmessage-length=0 -Wall
-Wconversion -Wno-implicit-int -fPIC
-I/usr/src/packages/BUILD/grass57_exp_2003_11_08/include
-I/usr/src/packages/BUILD/grass57_exp_2003_11_08/dist.i686-pc-linux-gnu/i
nclude \
-o OBJ.i686-pc-linux-gnu/adj_cellhd.o -c adj_cellhd.c
adj_cellhd.c: In function `G_adjust_Cell_head':
adj_cellhd.c:44: error: `PACKAGE' undeclared (first use in this function)
adj_cellhd.c:44: error: (Each undeclared identifier is reported only once
adj_cellhd.c:44: error: for each function it appears in.)
This is related to the NLS support.
And the configure I use:
./configure --with-postgres-includes='/usr/include/pgsql
/usr/include/pgsql/libpq /usr/include/pgsql/server' --with-freetype
--with-lapack --with-blas --with-readline --with-dbm --with-cxx
--with-freetype-includes=/usr/include/freetype2 --with-motif
--with-motif-includes=/usr/X11R6/include --with-glw --with-nls --with-gdal
--with-grass50=/usr/src/packages/BUILD/grass53_exp_2003_11_08
Don't use --with-nls; the 5.7 Makefiles don't define the PACKAGE macro
which that feature requires (see glocale.h).
> > The problem with building shared (5.0) is, that some stuff isn't
> > build, for example the man pages aren't created.
>
> Are you sure?
> Try
> grep html src/CMD/lists/GRASS
>
> should print 'html'. If not, you are right (then post it to the list).It prints html, but it isn't built!
The error is here:mk/Makefile.in:
binaries:
@echo "making binaries ..."
echo "Start of compilation: "`date` > ${ERROR_LOG}
-cat ${SRCDIR}/src/CMD/lists/GRASS ${DSTDIR}/src/CMD/lists/optional | \
grep -v '^ *#' | grep -v '^ *$$' | grep -v '^html$$' | \
while read dir ; do \
mkdir -p $$dir ; \
${MAKE} -I${DSTDIR}/mk -I${SRCDIR}/mk -C ${SRCDIR}/$$dir -f makefile || \
echo "Compilation error in module: $$dir" >> ${ERROR_LOG} ; \
done
echo "End of compilation: "`date` >> ${ERROR_LOG}
The "binaries" target explicitly excludes the html directory from the
list of modules to build. The documentation is built by the
"documents" target using Makefile.docs:
documents:
${MAKE} -I${DSTDIR}/mk -I${SRCDIR}/mk -f ${SRCDIR}/mk/Makefile.docs documents
Note that the "documents" target is included in the "all" target
("all" is the default target):
all: dirs gmake binaries links documents
The rationale behind this is twofold:
1. html/Gmakefile is highly bogus; specifically:
F_MOD_TIME=`${GISBASE}/etc/getModTime $$f`; \
H_MOD_TIME=`${GISBASE}/etc/getModTime $$h`; \
if [ ! -f $$f -o $$H_MOD_TIME -gt $$F_MOD_TIME ]; then echo Generating: $$f; cp -p $$h $$f; fi; \
and:
F_MOD_TIME=`${GISBASE}/etc/getModTime $$f`; \
H_MOD_TIME=`${GISBASE}/etc/getModTime $$h`; \
if [ ! -f $$f -o $$H_MOD_TIME -gt $$F_MOD_TIME ]; then echo Generating: $$f; cat $$h|sed 's@html/@@' > $$f; fi; \
Execute a program to get the last-modified time of the source file. Do
the same to get the last-modified time of the output file. Only
execute the command if either the output file doesn't exist or it's
older than the input file.
Isn't there a dedicated program to do this sort of thing? What's it
called? Oh, that's right; it's called "make".
Not only is the above (i.e. expressing the very essence of "make" as a
make rule) so ... well, for want of a better term, obscene, but on
Cygwin, it's incredibly slow (Cygwin's fork()/exec() are around a
hundred times slower than on a real Unix, so adding two additional
commands per file to do something which is meant to be done
internally by make results in a serious performance hit).
2. When I'm doing modify-build-test cycles, I don't really need to
build the documentation every time. By moving the documentation to a
separate target, I can skip it. And even if I do build the
documentation, it's built last, so I can start using the new build
while the documentation is still being built. OTOH, the html directory
is the second entry in src/CMD/list/GRASS (after src/libes/tools,
which is where getModTime lives).
> > > > What about cleaning these things up and using GNU autotools for
> > > > building.
> > >
> > > See this comment:
> > > http://grass.itc.it/pipermail/grass5/2002-April/009033.html
> >
> > To fix that problem with building shared I worked my way through the
> > Makefiles.
> > And that was very complicating.
>
> Yes, the Makefile system in 5.0/5.3 is a nightmare.
Which one? The gmake5 system, or the "mk" system, or both?
As far as the gmake5 system is concerned, we could abandon that now if
we were willing to require GNU make. Also, the "mk" system is
currently constrained by the need to coexist with the gmake5 system.
--
Glynn Clements <glynn.clements@virgin.net>