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

[Anonymous]

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

From: Anonymous <swell.k at gmail.com>
To: bf1783 at gmail.com
Cc: bug-followup at FreeBSD.org
Subject: Re: ports/146419: [patch] devel/directfb: FREETYPE2 enabled  unconditionally
Date: Mon, 10 May 2010 09:09:18 +0400

 "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?
 
 > 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.
 
 >  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
 
   .if (defined(WITH_CUPS) || exists(${LOCALBASE}/lib/libcups.so)) && \
   	!defined(WITHOUT_CUPS)
 
 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.
 
 > Of course, one has to check whether --disable-freetype is really
 > respected by the port when freetype is already installed, but it seems
 > to be in this case.  If it isn't, then patch the port so that it is.
 > But please don't start juggling separate WITH_ and WITHOUT_ variables,
 > with compound tests -- that's really poor engineering. KISS.
 >
 > b.