Peter Wemm wrote:
> The following files:
> .. 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
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?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message