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