Hello,

I'm the main developper of KerGIS, which is a new BSD licensed version
of the GIS named G.R.A.S.S (there is a GPL version of GRASS, but
KerGIS is based on the last public domain version of the U.S. Army
Construction Engineering Research Laboratory).

KerGIS is aimed to be POSIX compliant and my main task at the present
has been to fix the code and reorganize the source tree, eliminating
duplicates, ensuring no namespace pollution, putting shared things in
libraries and so on, and redeveloping original things that did not work
anymore (X monitor for example).

Enough for the presentation.

The result is still a large software, with more than 20 libraries and
almost 200 programs (GPL GRASS was said to be one of the 10 biggest open
source project, but this takes into account a lot of historically gained
fat... KerGIS focuses on muscles ;).

Since it is meant to be POSIX compliant (and X11 for the graphical
interface, with Motif as graphical toolkit), I want to let the OSes 
provide their POSIX environment and tips, for generating shared
libraries and so on.

So NetBSD pkgsrc is clearly the way to go.

I (KerGIS) will provide the pkgsrc directly and this will be the only
distribution format supported. So this should be always in sync, and
since I can still make the developing choices, there should be no
patches at all.

But there are some peculiarities and I like to have some tips
(pointers).

1. KerGIS third parties modules

So to say, KerGIS is running in its own environment, providing a shell.
Everything is handled relatively to its root, wherever this root may be.

In order to ensure that third parties, building modules on KerGIS, do
not wreak havoc, they can install modules wherever they want _outside_
the KerGIS tree, or in the KerGIS tree on only one place: under opt/ 
directory (empty). 
But they need at least the KerGIS headers and libraries to build their
programs and I plan to provide for compilation time too a place where
third parties can put their sources (opt/VENDOR/KerGIS_compliant_tree)
meaning that I'd like third parties relying on KerGIS to be able to use
KerGIS pkgsrc package to build and install themselves (since they do
require KerGIS).

So roughly, in KerGIS pkgsrc, extracting the third party tarball under
the work/kergis/opt and using the KerGIS pkgsrc to install themselves.

Is there some packages already doing something like that? Are there
mechanisms for doing this?

2. CWEB sources

KerGIS is only C (and Bourne shell).
Since some parts are complex, I use Knuth's (and Levi) CWEB for some
programs. I use to ctangle the files before distribution, just in order
to avoid a cweb dependency, but it may happen in the future that
depending on the architecture of the machine, the .w has to be patched
i.e. there will be .w change files, meaning a compile time necessity to
use cweb.

Is the pkgsrc mk files system providing inference rules for .w.c or .w.h
files or do I need to put them in my Makefiles?

3. OBJ directory

At the moment (historically), the sources compile in the directory,
moving the *.o in a subdirectory before linking etc.
Since this prevent multiple compilations at the same time, I want/need
to change this.

Is there a good example of a package/sources handling correctly the
generation with read-only sources directories that I can take as an
example?

4. Machine characteristic

Is there a portable way (macros available on all ports) to know the
endianess of an architecture, the size of ints, long double and so
on (required in the future for a portable/shared file format in order,
for example, to share a common repository in an heterogeneous network or
to make grid computation) ?

TIA for any tip.
-- 
Thierry Laronde (Alceste)  <tlaronde@polynum.com>
http://www.kergis.org/  |  http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C