On Fri, 2013-02-15 at 17:32 -0500, Mikhail T. wrote: > 14.02.2013 09:34, Peter Pentchev ???????(??): > > However, there is then the argument of "well, if you want to use the > > bsd.*.mk > > infrastructure, then why don't you just copy it into your project and > > include > > it from there - just like many, many projects do with, say, the sys/queue.h > > header, or parts of libc, or whatever?" And it is, indeed, a very good > > argument > Either I completely misunderstand the argument, or I disagree -- strongly -- > with it. Including bits created and maintained by others into your own > project > is very rarely justified (although done quite often). I don't see, why adding > (some version of) bsd.lib.mk and friends into every project, that wishes to > build a shared library on FreeBSD, is any more justified, than bundling > libjpeg > with every graphics application. > > John-Mark also just posted a strong argument for using the existing bsd.*.mk > family of makefiles... > > since this is how a software distribution's parts are supposed to be used - > > you copy them into your project and use them even when they are not > > available > > on the host system. So one might argue that the port is, indeed, buggy, > > that > > the src.conf documentation is, indeed, correct, and that the proper way for > > people to use the bsd.*.mk > The documentation is, demonstrably, incorrect -- it was incorrect, when it > was > written 7 years ago, and remains so. Because a user of bsd.*.mk /will be/ > affected by src.conf -- unless he takes special steps to prevent it. This > fact > can not be fixed by a user, the only way to avoid the effect, is to modify > their > own makefile(s). > > The implementation of the change may be blamed for this -- if, indeed, there > was > a need for src-only configuration knobs, src.conf should be included, when a > special flag is present in the environment (put there by src/Makefile), not > the > other way around. > > some weird src.conf settings might confuse the build of some of my software > > on > > FreeBSD. > And some of those settings are required for healthy building of some of the > ports... For example, libreoffice "knows" out of the box, that FreeBSD has > Kerberos libraries. So, if your world was built WITHOUT_KERBEROS and > WITHOUT_GSSAPI, libreoffice fails to configure. A simple patch like: > > +.if defined(WITHOUT_KERBEROS) > +CONFIGURE_ARGS+= --without-krb5 > +.endif > +.if defined(WITHOUT_GSSAPI) > +CONFIGURE_ARGS+= --without-gssapi > +.endif > > could help, but WITHOUT_KERBEROS and WITHOUT_GSSAPI are set in src.conf and > not, > normally, available to the ports... > > So, in my opinion, the manual (src.conf(5)) should be updated to reflect > reality. Or, if the separation is really deemed desirable (something I, for > one, > continue to question), the implementation (in /usr/src/Makefile and > bsd.own.mk) > needs to be altered to only consider src.conf, when world/kernel are being > built/installed.
The src.conf manpage is not in error. The intent is that src.conf applies only to the building of the freebsd world and kernel, that is, the source that's usually located under /usr/src. If settings from src.conf are leaking into other builds, the error is in the makefiles, not in the manpage. Unambiguous evidence of this can be found in the email announcing the new src.conf file and why it was created: http://lists.freebsd.org/pipermail/freebsd-current/2006-March/061725.html I'm not an expert with the build system, and that goes double for ports, so I can't say exact how or why it's broken, or when the breakage happened (or even if it's been broken from the very beginning), but I think that announcement email makes it clear the bug isn't the documentation. -- Ian _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
