Re: Updating databases/libpqxx

[Klaus Heinz <k.heinz.mai.sieben%kh-22.de@localhost>]

Jan Danielsson wrote:

>    Many thanks for the summary! That filled a lot of gaps, though some
> remain. So, essentially, there are a finite amount of build systems

See Roland Illig's message, the pkgsrc guide contains better information
than I thought :-), not least thanks to him.

> which pkgsrc is aware of, and the packages need to use one of them, or
> else pkgsrc needs to be extended?

There are some build systems pkgsrc supports extensively (like the
GNU autoconf tools) because they are widely used. The others have
either some minimal support you can use or your pkgsrc Makefile will
be a bit bigger than usual because you have to do the work yourself.
If some more packages pop up doing it this way, most likely someone
will suggest to factor out the common behaviour into some .mk file
in pkgsrc/mk.

>    Am I correct in assuming that the configure-scripts are a
> semi-standard for build systems in Unix-systems (I don't think I've seen
> a single Unix-aware build system which *doesn't* have a configure
> script). Is it safe to assume that an application/library tarball will

OS/2 was a system produced and sold by a single vendor: IBM. You could
rely on some basic facts on every OS/2 system.

There are many systems calling themselves UNIX or at least UN*X-like
(eg NetBSD). They all share a common heritage (if not in code then in
their interfaces) but also differ in subtle ways. This fact is the
reason why people came up with the idea "our software needs feature a1,
b1 and c1, let's look whether they are available or at least a2, b3 or
c4".

> have a configure script? Am I also correct in assuming that most
> programs do in fact require patches, or tweaks, in order to build and
> install properly (on NetBSD/pkgsrc)?

Depends on the program, its history and origin. Modern software
originating from some Linux-centric project often depends on Linux-isms
and setting some variables may not be enough. Then patches are the heavy
tools to beat the sources into shape for pkgsrc.

If possible at all, the patches should be done in a way enabling the
original software authors (often called "upstream", the term seems to
come from the Debian project) to incorporate them into their sources,
so the pkgsrc patch will be obsolete after the next release.

>    Oh, while I'm at it.. What is autoconf in this context, which I see
> references to sometimes?

The GNU autoconf tools (devel/autoconf, devel/automake) are a framework
for software authors to generate the configure script, header files and
make files. It's really heavy shell and m4 magic inside but can be used
by mere mortals like me :-).  Some people hate it, some like it.

>    Are there any examples of application packages in pkgsrc which do not
> use any configure-script? (apart from trivial packages which don't use
> tarballs at all)

There is some software which does not need configuration, for whatever
reasons. Just try "grep NO_CONFIGURE" in your pkgsrc tree.

>    I think I managed to track down the problem in the particular package
> I'm trying to build (libpqxx 2.6.9). It seems that the installation is
> performed by an install-sh script. The install-sh script in turn calls
> 'install' to install the individual files. The problem is that it isn't
> sending the '-d' parameter to 'install', so the target directories
> aren't created.

I suggest you provide the whole package you have created so far. Put it
somewhere as a  tar.gz archive and post the URL. Then people can have a
closer look and try to see why it fails.

Maybe you even want to join the pkgsrc-wip project at sourceforge

   http://pkgsrc-wip.sourceforge.net/

ciao
     Klaus