Hi Thierry,

First of all, pkgsrc is intended to build third party packages.  It
does not provide any mechanism to build shared libraries nor programs
in a platform-independent way.  However, it provides "tricks" to fix
programs that don't build properly or, sometimes (very few), complete
build scripts to compile the package directly (bypassing broken
and/or non-portable makefiles coming in the distribution file).

The whole build is handled by the build infrastructure of each package.
Most of them use GNU libtool, and this is what provides everything
necessary to build shared libraries in multiple platforms.  Also, they
use GNU autoconf, which provides a standard way to detect those
system features you talk about (endianness, size of longs, etc).

So you should try the widely extended GNU autoconf/automake/libtool
triplet (IMHO, ew).  Or even better, use a BSD alternative, Buildtool
http://buildtool.sourceforge.net/ (being its author, I'm biased ;).

If you use any of those in your distribution files, creating packages in
pkgsrc will be very easy.

Cheers


On Sat, 10 Jul 2004 19:28:56 +0200
Thierry Laronde <tlaronde@polynum.com> wrote:

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


-- 
Julio M. Merino Vidal <jmmv@menta.net>
http://www.livejournal.com/users/jmmv/
The NetBSD Project - http://www.NetBSD.org/