cvs commit: ports/dns/c-ares Makefile distinfo pkg-plist ports/dns/c-ares/files ares-config-info.patch patch-Makefile.in

Peter Pentchev roam at ringlet.net
Mon Mar 29 08:51:59 UTC 2010


On Mon, Mar 29, 2010 at 01:22:33AM -0700, Stanislav Sedov wrote:
> On Mon, 29 Mar 2010 10:46:34 +0300
> Peter Pentchev <roam at ringlet.net> mentioned:
> 
> > Hmmm, apologies if I'm missing something here - and it would not be
> > a big surprise to me if I was, even about such an important thing
> > about the package building cluster :\  However, IMHO the need to
> > check for WITHOUT_* in the case of "default to on" is somewhat
> > a thing of the past - I think that the current options handling code
> > will define the WITH_* symbol if there is no options file and this is
> > an automated build.
> > 
> > [roam at straylight /usr/ports/dns/c-ares]$ make -V OPTIONSFILE
> > /var/db/ports/c-ares/options
> > [roam at straylight /usr/ports/dns/c-ares]$ ls -l "`make -V OPTIONSFILE`"
> > ls: /var/db/ports/c-ares/options: No such file or directory
> > [roam at straylight /usr/ports/dns/c-ares]$ make -V WITH_HIDE_SYMBOLS
> > true
> > [roam at straylight /usr/ports/dns/c-ares]$ make BATCH=yes -V WITH_HIDE_SYMBOLS
> > true
> > [roam at straylight /usr/ports/dns/c-ares]$ make PACKAGE_BUILDING=yes -V WITH_HIDE_SYMBOLS
> > true
> > [roam at straylight /usr/ports/dns/c-ares]$ make BATCH=yes PACKAGE_BUILDING=yes -V WITH_HIDE_SYMBOLS
> > true
> > [roam at straylight /usr/ports/dns/c-ares]$ make BATCH=yes PACKAGE_BUILDING=yes -V WITH_HIDE_SYMBOLS -V CONFIGURE_ARGS:M'*symbol*'
> > true
> > --enable-symbol-hiding
> > [roam at straylight /usr/ports/dns/c-ares]$
> > 
> > Am I wrong in assuming that any automatically-built packages would
> > have BATCH and/or PACKAGE_BUILDING defined at build time, and that
> > the code in bsd.port(.pre).mk would use the default value for all
> > options in that case?  Or is there some defined symbol - or some other
> > combination of symbols - that would result in WITH_HIDE_SYMBOLS
> > *not* being defined, even though the option's default is "yes"?
> > 
> > Of course, I could be missing something, in which case I'd be thankful
> > for a correction in my worldview :)
> > 
> 
> Sorry, my bad.
> It seems you're right and it works fine
> here.  Sorry for the noise.
> 
> However, I noticed it doesn't work
> universally.  If you take a look at
> the security/openconnect port, for example,
> that has the same problem (and apparently
> was not tested at all), and try to look
> what LIB_DEPENDS contains (make -V LIB_DEPENDS)
> you will notice it always pulls gtk into depends
> regardless of the GUI option value.  It appears
> that we should be careful with options checking
> even in this century :-)
> 
> Again, sorry for the noise. :-)

No problem about the noise - it's always good both to learn
something new and to examine one's assumptions critically :)

(the rest of this is mainly addressed to Damian Gerow,
the maintainer of the security/openconnect port)

As to the security/openconnect port, IMHO there's a problem
with the options handling in the port's Makefile: I think that
it doesn't *need* to use bsd.port.options.mk, and it also
does not use it correctly - bsd.port.options.mk should be
included only *after* the OPTIONS variable is initialized.
The use case for bsd.port.options.mk is for the port's Makefile
to be able to examine options that will lead to changes that
must be specified before including bsd.port.pre.mk, thus
a Makefile using it should look like:

...
OPTIONS=	...

.include <bsd.port.options.mk>

.if defined(WITH_FOO)
USE_XORG=	foo
.endif

.include <bsd.port.pre.mk>
...
.include <bsd.port.post.mk>

In openconnect's case, there are no early dependences that should
depend on user-settable options (it's okay to specify LIB_DEPENDS
after including bsd.port.mk ;), so it doesn't really need to use
bsd.port.options.mk at all.  Even if it did, the OPTIONS= line
should have been placed before the bsd.port.options.mk inclusion :)

Damian, what do you think about the following patch which should
fix openconnect's dependency on GTK to, well, depend on the GUI
option?  If you have no objections, I could commit it.

Index: ports/security/openconnect/Makefile
===================================================================
RCS file: /home/ncvs/ports/security/openconnect/Makefile,v
retrieving revision 1.5
diff -u -r1.5 Makefile
--- ports/security/openconnect/Makefile	28 Mar 2010 06:43:26 -0000	1.5
+++ ports/security/openconnect/Makefile	29 Mar 2010 08:47:34 -0000
@@ -25,8 +25,6 @@
 MAN8=		openconnect.8
 PORTDOCS=	README.*
 
-.include <bsd.port.options.mk>
-
 OPTIONS=	GUI      "Enable the OpenConnect configuration GUI"   off
 
 .include <bsd.port.pre.mk>

G'luck,
Peter
-- 
Peter Pentchev	roam at ringlet.net    roam at space.bg    roam at FreeBSD.org
PGP key:	http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint	2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13
Nostalgia ain't what it used to be.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-all/attachments/20100329/7866f12f/attachment.pgp


More information about the cvs-all mailing list