ports/146419: [patch] devel/directfb: FREETYPE2 enabled unconditionally

[b. f.]

The following reply was made to PR ports/146419; it has been noted by GNATS.

From: "b. f." <bf1783 at googlemail.com>
To: Anonymous <swell.k at gmail.com>
Cc: bug-followup at freebsd.org
Subject: Re: ports/146419: [patch] devel/directfb: FREETYPE2 enabled 
	unconditionally
Date: Mon, 10 May 2010 05:41:40 +0000

 On 5/10/10, Anonymous <swell.k at gmail.com> wrote:
 > "b. f." <bf1783 at googlemail.com> writes:
 >
 >> Look, introducing more variables (and contradictory ones, too) is just
 >> complicating things unnecessarily.  This is getting to be a mess. This
 >> port currently enables freetype support by default for ordinary builds
 >> on many systems that already have freetype installed, but disables it
 >> by default for package-building clusters and tinderboxes that use a
 >> clean sandbox for builds.  That dichotomy is undesirable.  But the
 >> solution proposed in the original submission isn't a good idea,
 >> either.
 >
 > This PR is about a bug and classified as such - sw-bug. What you are
 > proposing below constitutes as change-request. And since you're already
 > changing established behaviour why not update the damn thing, too?
 
 Whether the existing behavior is a bug or not is debatable, but I
 don't really care.  My response belongs in this PR's audit chain
 because it addresses your proposed change (which I think could have
 been simply submitted as a follow-up to the update PR, ports/144765).
 I'd love to see an update.
 
 >
 >> The best solution is to _remove_ the following lines of code:
 >>
 >> .if exists(${LOCALBASE}/lib/libfreetype.so.9)
 >> WITH_FREETYPE2= yes
 >> .endif
 >>
 >> and expose this knob as a FREETYPE OPTION with a suitable default
 >> value.
 >
 > And ports/144765 does exactly that, i.e. adds OPTIONS, except it doesn't
 > remove above statement.
 
 Good.  But it should also remove these lines, or users will not be
 able to disable auto-detection and -configuration of freetype support
 when freetype is installed, as you wanted.
 
 >
 >>  That should satisfy people who want to be able to enable or
 >> disable freetype support without regard to whether freetype is already
 >> installed, and is more visible than a knob that isn't an OPTION.
 >
 > You're forgetting that
 >
 >   .if defined(WITH_BLAH) || exists(${LOCALBASE}/lib/libblah.so.1)
 >
 > is quite common. Here is an example from x11-toolkits/gtk20
 
 This is usually present because the maintainer didn't want to take the
 time and effort to disable auto-detection and -configuration of
 certain features.  But it it not necessary, and it is not desirable.
 It is also not the recommended practice in section 5.11.3 of the
 Porter's Handbook.
 
 >
 >   .if (defined(WITH_CUPS) || exists(${LOCALBASE}/lib/libcups.so)) && \
 >   	!defined(WITHOUT_CUPS)
 
 Yes, it's present in some ports because those ports were never fully
 converted to the OPTIONS framework, which was intended to replace this
 kind of garbage.  You can offer some precedents, but it is still _not_
 a good idea.
 
 >
 > And the purpose of things like HAVE_GNOME is exactly to intervene with
 > user's decision and enable things based on what's already installed.
 >
 
 I guess here you're talking my separate response to PR ports/146385.
 I'm not sure what you mean by this.  My point there was that rather
 than subverting the use of *_GNOME in one port Makefile, the question
 of of libgsf's dependence on gconf2 should be addressed centrally in
 bsd.gnome.mk and the libgsf port Makefile, so that dependencies are
 properly recorded for _all_ ports that use libgsf, and ports are not
 attempting to use some Gnome ports outside of the *_GNOME framework,
 and some inside, which could lead to confusion.  I support your
 attempt to reduce the number of dependencies for users that want to
 use part but not all of Gnome, but not the way you went about it.
 
 b.