From owner-freebsd-gnome@FreeBSD.ORG Sun Jan 3 02:21:00 2010 Return-Path: Delivered-To: gnome@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD7691065676 for ; Sun, 3 Jan 2010 02:21:00 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 7BB048FC15 for ; Sun, 3 Jan 2010 02:21:00 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 29066BDC43; Sat, 2 Jan 2010 18:20:55 -0800 (PST) To: Joe Marcus Clarke In-Reply-To: <1262481198.16768.52.camel@shumai.marcuscom.com> Date: Sat, 02 Jan 2010 18:20:55 -0800 Message-ID: <13678.1262485255@tristatelogic.com> From: "Ronald F. Guilmette" Cc: gnome@FreeBSD.org Subject: Re: ports/140563: net/avahi-app doesn't build - depends on missing "gnome-config" X-BeenThere: freebsd-gnome@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME for FreeBSD -- porting and maintaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jan 2010 02:21:00 -0000 In message <1262481198.16768.52.camel@shumai.marcuscom.com>, you wrote: >> So now, is THIS my solution? Do I just simply need to find the place in >> the avahi-app Makefile(s) where the pgk-config command is being invoked, >> and then re-arrange things so that the options come before non-option >> args? > >This isn't a solution. This just reinforces the fact that your system >has a problem. Now that I look again, you have POSIXLY_CORRECT set in >your environment. Yea. So? What have you got against POSIX correctness? (If I wanted to work in an environment and with software where important internationally-recognized standards were simply ignored, then I'd be working on Windoze and sending money to Bill Gates on a regular basis. But I'm a dyed-in-the-wool UNIX bigot. I work on UNIX in the hopes that other people building software for it obey standards... or at least care when they have inadvertantly failed to do so.) >This is the cause of your problem. I agree that it is most likely the cause of _the_ problem. I do not agree that it is *my* problem. Looking now at the version of popt.c (Copyright RedHat, 1998, but which may have been derived from GNU getopt) which has been packed in with pkg-config-0.23_1, I do see that it makes reference to POSIXLY_CORRECT, and that the setting or non-setting of this environment variable then probably does (I'm assuming) logically affect the behavior of argument and option processing. Googling around, I found this: http://www.gnu.org/s/libc/manual/html_node/Using-Getopt.html#Using-Getopt * POSIX demands the following behavior: The first non-option stops option processing. This mode is selected by either setting the environment variable POSIXLY_CORRECT or beginning the options argument string with a plus sign (`+'). I feel sure that I could dredge up the exact POSIX reference (chapter & verse) if I was of a mind to do so. But for now I'll just say that I _am_ quite sure that this GNU documentation I've just quoted from is correct, and that indeed the POSIX commands standard (ISO/IEC 9945-2:1993(E) ANSI/IEEE Std 1003.2-1993) unambiguously _requires_ that option arguments proceed non- option arguments. Given that, is there some _compelling_ reason why the Makefile for avahi-app is electing to deviate from the published POSIX standard (_and_ from nearly 40 years of well-established UNIX tradition & practice) ? Or was this POSIX faux pas just a result of ignorance of the relevant international standard? >Remove this variable, and popt-based applications will work the way they were >intended. As far as I can see, there is nothing whatsoever wrong with the application known as pkg-config. It is behaving as its developer intended. It is using popt and thus benefits from all of the features of that well-written package... _including_ user-optional enforcement of POSIX standards with respect to command line argument/option parsing. Indeed, I have no reason at this point to believe that _any_ "popt-based application" on my entire system is misbehaving in any way. Do you have some basis for asserting that this whole problem I have experienced is due to anything other than just one simple goof by one lone coder who wrote one lone command in one single Makefile (for avahi-app) in a way that violates POSIX, simply because he wasn't aware of the requirements thereof? If not, then may I hunbly suggest fixing the simple (and now obvious) goof in the avahi-app Makefile? Regards, Ron Guilmette (Former member of the ANSI C++ and ANSI C/9x standards comittees) P.S. I see that you have closed this PR (ports/140563). I disagree that it should be closed, and I request that you re-open the PR. A Makefile which is part of avahi-app is violating POSIX command invocation standards for no apparently good reason, thus causing build problems for some users. This is a bug. As of this moment, it remains unresolved. If you prefer (or insist) I'll file a new PR which will make it more clear and apparent that this is the exact (and actual) problem. Sweeping the problem under the rug does not appear to me to be an appropriate or proper way to resolve it. I greatly appreciate the work you've done to help me to isolate the problem, but now that it has been isolated and identified, it appears fairly apparent that (a) this is a real bug and that (b) it is _not_ just simply due to "pilot error". Furthermore, it would appear that the following harmless one-line patch will rectify the problem entirely: *** net/avahi-app/work/avahi-0.6.25/configure.ac- Mon Apr 13 18:55:55 2009 --- net/avahi-app/work/avahi-0.6.25/configure.ac Sat Jan 2 18:07:06 2010 *************** *** 563,567 **** AC_DEFINE(HAVE_DBUS, 1, [Whether we have D-Bus or not]) ! DBUS_VERSION=`$PKG_CONFIG dbus-1 --modversion` DBUS_VERSION_MAJOR=`echo $DBUS_VERSION | awk -F. '{print $1}'` DBUS_VERSION_MINOR=`echo $DBUS_VERSION | awk -F. '{print $2}'` --- 563,567 ---- AC_DEFINE(HAVE_DBUS, 1, [Whether we have D-Bus or not]) ! DBUS_VERSION=`$PKG_CONFIG --modversion dbus-1` DBUS_VERSION_MAJOR=`echo $DBUS_VERSION | awk -F. '{print $1}'` DBUS_VERSION_MINOR=`echo $DBUS_VERSION | awk -F. '{print $2}'` Note that this simply brings that one line into conformance with POSIX. (Not surprisingly, all of the other invocations of pkg-config within configure.ac are _already_ full conformant.) P.P.S. At the risk of belaboring the point, allow me also to say again what I said earlier... I don't know why people are out there writting Makefiles with commands where the command options _don't_ always come first. I had always believed that this was one of the first things they teach you on day one of UNIX school... the options come first, then the actual command arguments. (Didn't everybody get this on day one of UNIX school??) Anything else is just counter-intutive (and just plain looks wrong, e.g. to at least one old-time hack who has been on UNIX since circa 1983).