[ On Wednesday, October 16, 2002 at 01:23:31 (+0200), Brad Knowles wrote: ]
> Subject: Re: POSIX threads & NetBSD 1.6?
>
> 	Right, but this means that NetBSD has effectively closed itself 
> to anything that is not inherently NetBSD-aware, or for which there 
> is not a NetBSD package/port.  At least, there's an extra step that's 
> involved here that people will tend to stumble over.

I don't know how you could ever get that idea.

No system should ever automatically add '-I' or '-L' flags that point
anywhere but at the base system supplied directories, not even to
/usr/local.

No third party software should ever automatically assume that other
third party software is installed in any given location (either absolute
or relative to where the package in question is about to be installed).

Such poor development hygiene mistakes have been the bane of unix
software developers for 20 years or so, and also the cause of many a
sys-admin's lost hair for just as long.  (well since *BSD shipped with
/usr/local anyway)  Even worse are the problems such assumptions cause
for systems like pkgsrc which must very carefully control the build
environment so that all dependencies can be well known and understood.

If you're about to install some non-pkgsrc software that happens to need
to use some other software that you've already installed via pkgsrc then
_you_ must simply tell that new software where the other software it
needs is located.  You should do the same to tell it about any software
you've already installed in /usr/local or /opt or wherever you choose to
install other software.  Normally this should be a very easy process for
software that expects to make use of some other third party packages
(i.e. other software that's not normally expected to be included in a
basic unix-like OS).

You should also send bug reports to any package maintainers who ship
software which makes any unfounded assumptions about where any other
non-base system software has been installed, especially if those
assumptions cannot be overridden _and_ disabled as appropriate.

For example the one potential exception to this rule of thumb is
software using GNU Autoconf.  You might allow it to continue making
assumptions about where other software might have been installed just so
long as you are 101% certain that those assumptions can easily and
always be overridden when necessary.  If I'm not mistaken this is also
the very strong advice of the GNU Autoconf maintainers as well but of
course Autoconf cannot force developers using it to honour these
guidelines.

(Remember though that GNU Autoconf and other things like it of course
make the job of pkgsrc much harder since they try very hard to explore
the target system for usable features and add-ons while pkgsrc must
control the build environment very very strictly.)

> 	My primary question has to do more with why this step wasn't 
> followed by the natural next step, namely insuring that 
> /usr/pkg/include is always included in the normal patch searched by 
> the compiler for header files, and that /usr/pkg/lib is always 
> included in the normal search path for the linker & loader?

If you wish to do that for your system then you should do so, but please
do not expect such things to be done for you, neither by the base system
authors, nor by third party software developers.  Pkgsrc doesn't have to
install packages in /usr/pkg -- that's just the default.  Anyone can
just as easily use /local, /opt, /usr/local, or any other pathname of
choice, indeed even almost as easily one can install packages directly
in /usr!

Software developers should never expect the system compiler to
automatically lead their build systems to find locally installed
software.  Given the state of our software construction technology today
and for the foreseeable future that way lies uncontrollable madness.
However if their own build system does this for them, as GNU Autoconf
_can_, then that's a potentially good thing for system administrators
(just, as I say, so long as those features can be turned off or
overridden when they might get in the way).

Some configuration systems, including GNU Autoconf, do allow you to
provide standard system default settings too.  You could use this
feature with "locally" installed software so that it can easily find
other packages you've installed in /usr/pkg.  See the section "Sharing
Defaults" in the GNU Autoconf manual.

Many packages also honour -I and -L flags included in commonly used
environment variables, such as CPPFLAGS (or CFLAGS) and LDFLAGS, etc. so
you can try setting the defaults you wish in /etc/profile, etc.

You might also try writing a little wrapper script for configuring
hand-built software.  For example when I hand-build a test version of
emacs I link it against libraries I've installed as packages in /usr/pkg
with this little wrapper on the emacs "configure" script:

export PWD=$(pwd)
export PATH=/usr/pkg/gcc-ssp/bin:$PATH
export CC="/usr/pkg/gcc-ssp/bin/cc"
export CFLAGS='-pipe -g -O2 -fstack-protector -DGLYPH_DEBUG=1 -I/usr/pkg/include'
export CPPFLAGS='-DGLYPH_DEBUG=1 -I/usr/pkg/include'
export LDFLAGS='-g -O2 -pipe -Wl,-R/usr/pkg/lib -L/usr/pkg/lib'

./configure  --verbose --without-xim --with-xpm --with-jpeg --with-tiff --with-gif --with-png --with-pop --with-ipv6 --prefix=/usr/local --with-x-toolkit=athena

echo ""
echo "=======>>>>  now remember to 'gmake all info'!!!"
echo ""


>  After 
> all, the standard PATH definition for users includes /usr/pkg/bin, so 
> why not make the other modifications as well?

Is that really true?  I didn't think it was.  In any case that's a
different issue.

> 	I know that I won't be installing a whole lot of things on this 
> machine, and I'll only be manually installing things for which no 
> current package/port exists, so I am not concerned about collisions.

Why not try your hand at creating pkgsrc modules for those things?  If
you manage to succeed then you could submit them back with send-pr and
share them with the rest of us!  ;-)

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>