On Mon, 27 Dec 1999, Bill Studenmund wrote:

> What does making cross compilers part of the base system give us which
> having them(*) in the package system does not?

When little buglets or strange bootstrap dependencies come up, I've found
it a lot easier to make small changes or build things by hand in the src
tree than in pkgsrc.

> we're talking about TEN cross compilers! . . . That strikes me as a
> lot of bloat.

I'd feel rediculous to disagree with you here--there's no way I want to
build cross-compilers for every architecture every time I do a build.
especially on a sun3!  Likewise, they take up too much space if you
install them.  But, there's two separate problems:

  o Users want to choose which cross compilers get built
  o Cross compilers ought to go in separate binary packages

We don't actually _need_ pkgsrc for the latter requirement.  Releases
already segregate themselves into several tarballs, so that for example
you don't have to install any compilers at all if you're doing a binary
install of NetBSD. The base Makefiles already have this feature.

There's some precedent for the former feature as well, in the way
crypto-{enabled,disabled} builds are handled.


But, I think you could make a strong argument that the package system
could be a simpler and more advanced way of dealing with both problems.
It's just that, we don't have any precedent for packages like these yet.
I'm not saying they're impossible--just that I think (hope) you are
proposing a completely novel kind of package.

For example, all the other packages demand snapshots of source.  If the
dist source changes, the package msut be updated.  Even the pkgtools
packages, which are based on ``base src'' code, require snapshotting the
base src into a versioned distfile--they don't track unversioned
random-date -current trees.


In general, I always get a little concerned when people talk about moving
Everything into the package system.  bsd.pkg.mk is intentionally messy
convoluted spaghetti, because it is a collection of frustrating kludges to
deal with other people's build layouts.  It hasn't evolved with the same
goals in mind as /usr/share/mk/*.  I would like to understand how the
hypothetical NetBSD cross building system works, so that I can play with
it and steal ideas from it.  Yet, I would prefer not to understand
bsd.pkg.mk if I can avoid it.  Perhaps this is possible, even if cross
uses the package system--don't ask me!

One thing that might be interesting:  I don't see any logical difference
between ``hostprogs'' and cross tools.  A cross-cc and a
hostprog-make_cmds are almost the same thing.  Granted, a
hostprog-make_cmds will work for any target.  You only need to treat it
separately as a hostprog because your build host might be 1.4.1 and your
target might be -current.  But, some parts of the toolchain are like that,
too--that is, some of the binutils care about a.out vs. ELF, but not about
m68k vs. sparc.  As far as the build system is concerned, cross-cc and
make_cmds are Things of the same Kind.  Or at least, perhaps they could
be.  We have three collections of programs:

 o /
 o hostprog's
 o DESTDIR

cross tools are the middle kind.  no?

-- 
Miles Nordin / v:1-888-857-2723 fax:+1 530 579-8680
555 Bryant Street PMB 182 / Palo Alto, CA 94301-1700 / US