Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 02 Jan 2010 18:20:55 -0800
From:      "Ronald F. Guilmette" <rfg@tristatelogic.com>
To:        Joe Marcus Clarke <marcus@marcuscom.com>
Cc:        gnome@FreeBSD.org
Subject:   Re: ports/140563: net/avahi-app doesn't build - depends on missing "gnome-config" 
Message-ID:  <13678.1262485255@tristatelogic.com>
In-Reply-To: <1262481198.16768.52.camel@shumai.marcuscom.com> 

next in thread | previous in thread | raw e-mail | index | archive | help

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).



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?13678.1262485255>