After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 669598 - Trivial build fix
Trivial build fix
Status: RESOLVED FIXED
Product: pygobject
Classification: Bindings
Component: general
Git master
Other All
: Normal normal
: ---
Assigned To: Nobody's working on this now (help wanted and appreciated)
Python bindings maintainers
Depends on:
Blocks:
 
 
Reported: 2012-02-07 19:06 UTC by Patrick Welche
Modified: 2012-02-08 13:33 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Trivial build fix patch (s/==/=/) (1.26 KB, patch)
2012-02-07 19:06 UTC, Patrick Welche
none Details | Review

Description Patrick Welche 2012-02-07 19:06:23 UTC
Created attachment 207015 [details] [review]
Trivial build fix patch (s/==/=/)

test(1) uses '=' to test if strings are identical
Comment 1 Dieter Verfaillie 2012-02-07 19:24:21 UTC
Comment on attachment 207015 [details] [review]
Trivial build fix patch (s/==/=/)

correct MIME type and set patch flag which enables review functionality.
Comment 2 Paolo Borelli 2012-02-07 22:18:49 UTC
Review of attachment 207015 [details] [review]:

The patch removes a bashism and I agree that is correct.

Is this python.m4 something home grown or are we copying it from somewhere else?
Comment 3 Martin Pitt 2012-02-08 04:48:41 UTC
My /usr/share/aclocal-1.11/python.m4 looks quite different, but at least does not have this bashism, so I guess that was fixed upstream a while ago.

I pushed your patch, thanks!
Comment 4 Dieter Verfaillie 2012-02-08 07:53:08 UTC
I suspect it was home grown, but failed to trace it's history
back to the origin when working on the win32 ports last year.
The same macros are also used in the python.m4 files in glade
and gobject-introspection.

So, the bashism's where introduced with my win32 porting (sorry!)
and the same fix should be applied for all 3 projects. I'll look
into it.

That said, have studied more .m4 files than I should since back
then and these string equality tests are usually written like:

  if test "x$WHATEVER" = "x"; then

whereas we now have:

  if test "x$WHATEVER" = x; then

We should probably add the quotes too to be completely correct...

PS Martin: the patch does not yet show up on http://git.gnome.org/browse/pygobject/log/
Comment 5 Paolo Borelli 2012-02-08 07:58:52 UTC
(In reply to comment #4)
>   if test "x$WHATEVER" = "x"; then
> 

and

> 
>   if test "x$WHATEVER" = x; then
> 

are completely equivalent, so it is not a correctness issue. We can obviusly still change them for consistency if we want
Comment 6 Martin Pitt 2012-02-08 08:22:57 UTC
The whole syntax is very 1980-ish anyway. if [ -z "$WHATEVER" ] or [ "$WHATEVER" = "" ] are a bit more eye friendly :)

> PS Martin: the patch does not yet show up on http://git.gnome.org/browse/pygobject/log/

It's there now, sorry.
Comment 7 Patrick Welche 2012-02-08 13:27:38 UTC
(In reply to comment #4)
> That said, have studied more .m4 files than I should since back
> then and these string equality tests are usually written like:
> 
>   if test "x$WHATEVER" = "x"; then
> 
> whereas we now have:
> 
>   if test "x$WHATEVER" = x; then

I can't remember where but I recently saw

     if test x"$WHATEVER"= "x"; then

which I thought was "imaginative", but also entirely correct...

Thanks for pushing the patch :-)
Comment 8 Patrick Welche 2012-02-08 13:33:05 UTC
(In reply to comment #6)
> The whole syntax is very 1980-ish anyway. if [ -z "$WHATEVER" ] or [
> "$WHATEVER" = "" ] are a bit more eye friendly :)

autoconf's shellology is always a fun read. [] is asking for trouble as it is the quote in m4, but this was the surprise:


     Posix also says that `test ! "STRING"', `test -n "STRING"' and
     `test -z "STRING"' work with any string, but many shells (such as
     Solaris, AIX 3.2, UNICOS 10.0.0.6, Digital Unix 4, etc.) get
     confused if STRING looks like an operator:

          $ test -n =
          test: argument expected
          $ test ! -n
          test: argument expected
          $ test -z ")"; echo $?
          0

Thankfully my shells behaved correctly :-)