David O'Brien wrote:
> Personally I do not mind requiring latest 4-STABLE to build -CURRENT
> (either for cross or simple `world').  I think that is all we can
> officially support.  I know RU wants to be able to upgrade from say 4.1 to
> 5-CURRENT.  I think that is a nice thing; but if it is going to be a
> requirement it should become an officially stated one.

I'm actually with RU on cross-building.  Crossbuilding is right
next door to porting, and it finds compilation/link platform
portability problems for things like Alpha and SPARC on x86
boxes, which is all to the good.

I'm all for the minimum build requirement being Xenix 2.2 or
VMS 3.4.  8-).

> The only fix is to import all of libiberty and create a config.h that
> implies Version 7.

It's annoying.  But I think that this annoyance comes from
automake/autoconf, and it's not ever going to get better,
since these programs don't make software portable, they aid in
porting software, which is a very different thing, and grossly
inferior to other approaches (e.g "imake" and "xmkmf" out of
X11 out of Project Athena out of MIT).

> > The problem is the usual one with committing files generated by
> > autoconfig.
> It would be the same problem without autoconf, the code could have been
> written only the the 5-CURRENT API.

The GNU tools have never been very cross-friendly, except in
single instances.  Very much unlike the NCR tools, which would
let you specify target in the Makefiles.  8-(.

> > This gives a configuration that might only be valid for the host
> > machine that ran autoconfig.  Cross-compiling of even portable
> > cross-compile-aware sources like gcc is broken by this.
> I personally believe we should build GCC in the normal manner, but this
> is no longer my decision to make.

FWIW, I think that building things in the normal manner is the
way to go; that's why I occasionally (one or two times a year) take
passes through ports, clean up the easy patches (the ones that don't
result in the code being FreeBSD specific instead of Linux specific),
and send them back to the various project maintainers.

Integrating actively maintained code into the project, not on a
vendor branch (a vendor branch is the best we can do with the tools
we have, since CVSup can't update to a vendor branch from a remote
primary archive), is really evil, as we can see with the fun with
sendmail, ssh, SSL, and the resolver library, among others.

Archie and Julian can probably provide a lot of information on
how to deal with vendor code as external modules, with version
tagging to allow "stickiness" in the build process.

Doing it that way, though, is a trade-off, since it means active
access to a CVS archive during the build process itself, rather
than just to get a code cut.  No CVS is also possible (a code cut
from a checked out archive with a "make checkout" run to get the
modules).  It may not be worth it, depending on your point of view.

I don't know if Julian and Archie have postable copies of the
Whistle/IBM InterJet .mk files, or if they would have to be recreated
for legal reasons, but it's a nice framework: the Makefile is responsible
for checking out the un-config'ed sources, and running the "configure"
with the set of options listed in the Makefile.

For things like "bind", this would including patching the two
non-overridable paths in the FreeBSD Make template files, as
distributed with bind itself, etc..  I'm sure there would be
other similar local hacks, but they could be seconded back to
the original code maintainers, like most people try to do with
ports these days.

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to