Date: Thu, 07 Feb 2002 00:41:33 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Peter Wemm <peter@wemm.org> Cc: Julian Elischer <julian@elischer.org>, Mike Barcroft <mike@FreeBSD.ORG>, Wilko Bulte <wkb@freebie.xs4all.nl>, Alfred Perlstein <bright@mu.org>, current@FreeBSD.ORG Subject: Re: Non 386 testers REALLY NEEDED Message-ID: <3C623DBD.DEB870A5@mindspring.com> References: <20020207033239.480313BAC@overcee.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Wemm wrote: > The following files: > src/gnu/usr.bin/cc/cc_tools/auto-host.h > src/gnu/usr.bin/cc/cc_tools/freebsd-native.h > .. are vaguely based on stuff that configure generated and are hand tweaked > to deal with the *freebsd* environment (eg: whether printf supports %p > etc), rather than compiler configuration. The compiler and language > configuration is done at runtime in the bmake files. eg: Ports does the same thing: hand tweaks stuff instead of pushing the patches back to the projects that originated it. It's far, far better that the Makefile runs the autoconf/automake/configure/etc. on behalf of the contrib code, with no hand-tweaked files dragged in after the config has already been run. In theory, this code, and the FreeBSD hierarchy that's used to build it, should compile successfully on any platform, FreeBSD or not. When I make something run on FreeBSD (e.g. OpenSLP, OpenLDAP, MySQL, ACAP, Cyrus, etc.), I always send the changes back to the originating project, rather than putting them in a patch file, or an extra file derived from a post-configure. To get back on track, the gcj stuff will be really hard to deal with, unless it can be dealt with natively. In other words, anything that has to be done in a FreeBSD specific way really thwarts this goal. If these (and other contrib build files elsewhere) are not hgenerated correctly by the configure/automake/autoconf/etc. process, then it's the process, not the files, that need to be corrected. Personally, I have great dislike for the tools used to create nominal platform independence; the imake/xmkmf stuff was really much better thought out for platfirm independence. But if we're stuck with the GNU munging, then we are stuck with it, and it's better to embrace it than it is to deny it by checking in hacked code to work around an unwillingness to correct it. Wasn't someone recently saying the same thing about the stdup()'s in the YP code to make it not bitch about the discarding of the "const" qualifier? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C623DBD.DEB870A5>