[GRASS5] Just some questions

Glynn Clements glynn.clements at virgin.net
Wed Nov 12 14:39:07 EST 2003


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.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.

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 at virgin.net>




More information about the grass-dev mailing list