Re: ports include /etc/src.conf? i.e. graphics/libfpx

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