-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Klaus Heinz wrote:
>> I'm having some trouble understanding where the line is drawn between
>> pkgsrc and the packages own build system. I understand that pkgsrc does
>> some preparations, then modifies the package's build system as required,
>> then kicks it off. Once it's done, it returns to pkgsrc for installation
>> or ever build target has been chosen. But how does it know which actions
>> to take? Does it always assume that it should run:
>>
>> configure --prefix=/usr/pkg
>
> There are various stages during the build of a package. Those stages
> are listed at the top of pkgsrc/mk/bsd.pkg.mk:
[---]
> During the "configure" stage, pkgsrc has to tell the build system of
> the software, well, to "configure" itself. As you noticed, many
> software systems use the "./configure" command for this configuration.
Many thanks for the summary! That filled a lot of gaps, though some
remain. So, essentially, there are a finite amount of build systems
which pkgsrc is aware of, and the packages need to use one of them, or
else pkgsrc needs to be extended?
[---]
> Once the configure script has finished, control returns to pkgsrc and
> eventually the dance continues in a similar but also different way for
> the next sub-target of "all", "build".
>
> The first task in building a pkgsrc package for some software is
> determining which kind of build system it has, which knobs this
> system offers, looking whether and how pkgsrc already supports it and
> chasing down the various pkgsrc variables to control the run of that
> build system.
Let me just state that I come from an OS/2 background, where my
projects generally had a makefile, which would do as advertised,
providing you had the appropriate compiler installed. So I'm not at all
accustomed to the "configure script" idea.
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
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)?
Oh, while I'm at it.. What is autoconf in this context, which I see
references to sometimes?
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)
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.
In fact, there's something very non-intuitive - to me - going on:
First:
- --------------------------
[---]
src=""
dst=""
dir_arg=""
while [ x"$1" != x ]; do
case $1 in
-c) instcmd="$cpprog"
shift
continue;;
-d) dir_arg=true
shift
continue;;
[---]
- --------------------------
Then, later:
- --------------------------
[---]
if [ x"$dir_arg" != x ]; then
dst=$src
src=""
if [ -d $dst ]; then
instcmd=:
chmodcmd=""
else
instcmd=mkdir
fi
else
[---]
- --------------------------
What's this mkdir-business? Shouldn't the script simply be passing
'-d' to 'install'? Or is it a portability issue?
See, here I'm lost. I can potentially fix this problem very easily,
by simply adding the appropriate hard coded '-d' flag to the
installation script. But is that _the_ solution? Also, if that is "the"
solution, how do I create the appropriate patch and how do I know that
it will be patched at the appropriate time? Hmm.. I believe this is
pretty well documented in the pkgsrc guide, so I should probably read it
again.
I'm really trying to learn this stuff, so I need to ask less, and can
patch more. :-)
- --
Kind regards,
Jan Danielsson
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (NetBSD)
iD8DBQFGVQFxuPlHKFfKXTYRCkh9AJ9wQnKBEMzDQXOAd9Pq2Xb1IOH88gCdE1bg
TSAzOfFI4Zp9yKMAjYmRjak=
=KmgB
-----END PGP SIGNATURE-----