Date:        Thu, 29 Nov 2001 08:13:48 -0600 (CST)
    From:        Frederick Bruckman <fredb@immanent.net>
    Message-ID:  <Pine.NEB.4.30.0111290739170.4658-100000@fbruckman.tsps1.freenet6.net>

  | How about, the top-level Makefile builds and installs a whole toolchain
  | in place (after updating "tools", and using "tools" to build it), only
  | if DESTDIR is not set?

The actual src build hasn't been a problem for me so far (except the gcc
bug that is preventing a cross compile of groff for i386 on alpha with -O2
set ... but that's a different issue).

I will do a bunch of "oddball" tests over the weekend, and see if anything
doesn't behave in a nice way though.

  | Not "pkgsrc", so much as certain packages.

If that's what it was, for me, then I was damn unlucky, as before I
actually figured out what was happening, I tried 3 or 4 at random, and
they all failed exactly the same way.   Before I incorporate Todd's fix,
I'll try some more just to be sure.   It could however be only packages
that run "configure", I think the few I tried all did that, so I'll try
a bunch of simpler ones as well.

  | Actually, it would be kind of neat if "pkgsrc" could guarantee that the
  | "tools" directory would be used for all packages, (perhaps conditionally
  | on DESTDIR set plus some other knob), as "pkgsrc" could then more easily
  | support foreign systems and very old systems.

Yes, that would be nice, if available - it certainly needs to be optional
though, not everyone has anything in /usr/src (other than pkgsrc).  On many
systems I don't (well /usr/src/sys and /usr/src/pkgsrc are the two I typically
have everywhere).

  | I suggested that recently, too, but Al talked me out of it. "bsd.own.mk"
  | has a lot of stuff that relates to the system you have installed, and
  | "pkgsrc/mk" and many individual packages count on it being correct, so
  | when a port switches to ELF, or evolves the capacity to use shared
  | libraries, it wouldn't be enough to simply pull up the change from
  | "bsd.own.mk" in current -- you'd have to have tests, as "pkgsrc" must
  | support the older systems, too.

Yes, all of that makes some sense - but there has to be a way that the
"state of the system" stuff can be separated out from the "how do I compile"
stuff - and in any case, it needs to be for other systems.  What would
pkgsrc do if Solaris changed their binary format (something like an a.out to
elf or coff to elf, or elf to blather ...) somewhere along the line?
It would need a way there to tell what it should do.   Is there some reason
that NetBSD installations of pkgsrc need to be handled differently?

Of perhaps more likely, for pkgsrc on linux - there you have to be expecting
incompatible and arbitrary changes any time at all ...

kre