pbbuttons-users

Question about CFLAGS handling in configure.in

[Frank L. <dj...@de...>]

In configure.in of gtkpbbuttonsd (and probably the others, too, didn't
check) you use the following snippet:

CFLAGS=
dnl Use -Wall if we have gcc.
changequote(,)dnl
if test "x$GCC" = "xyes"; then
  case " $CFLAGS " in
  *[\ \ ]-Wall[\ \      ]*) ;;
  *) CFLAGS="$CFLAGS -Wall" ;;
  esac
fi
changequote([,])dnl

which is bit "suboptimal", since it deletes all previous changes
to CFLAGS, especially such given in the configure commandline or
as enviroment variables.

Is there a good reason to do this? It seems you use this only to
filter out "-g" from CFLAGS?

Gruesse,
-- 
Frank Lichtenheld <dj...@de...>
www: http://www.djpig.de/

Re: Question about CFLAGS handling in configure.in

[Matthias G. <mat...@us...>]

On Wed, 28 Sep 2005 19:24:09 +0200
Frank Lichtenheld <dj...@de...> wrote:

> In configure.in of gtkpbbuttonsd (and probably the others, too, didn't
> check) you use the following snippet:
> 
> CFLAGS=
> dnl Use -Wall if we have gcc.
> changequote(,)dnl
> if test "x$GCC" = "xyes"; then
>   case " $CFLAGS " in
>   *[\ \ ]-Wall[\ \      ]*) ;;
>   *) CFLAGS="$CFLAGS -Wall" ;;
>   esac
> fi
> changequote([,])dnl
> 
> which is bit "suboptimal", since it deletes all previous changes
> to CFLAGS, especially such given in the configure commandline or
> as enviroment variables.
> 
> Is there a good reason to do this? It seems you use this only to
> filter out "-g" from CFLAGS?

This code is a relict from the very beginning of pbbuttonsd development.
I used the autotools files from glade as base for my own. This sippet
was part of the glade files and was never questioned.

Any suggestions to replace it?

 Best Regards
   Matthias

Re: Question about CFLAGS handling in configure.in

[Frank L. <dj...@de...>]

On Thu, Sep 29, 2005 at 07:56:04PM +0200, Matthias Grimm wrote:
> On Wed, 28 Sep 2005 19:24:09 +0200
> Frank Lichtenheld <dj...@de...> wrote:
> > Is there a good reason to do this? It seems you use this only to
> > filter out "-g" from CFLAGS?
> 
> This code is a relict from the very beginning of pbbuttonsd development.
> I used the autotools files from glade as base for my own. This sippet
> was part of the glade files and was never questioned.
> 
> Any suggestions to replace it?

I made the following patch (it's against gtkpbbuttons):
Index: configure.in
===================================================================
RCS file:
/home/djpig/vcs/cvs/Projekte/debian/gtkpbbuttons/configure.in,v
retrieving revision 1.1.1.7
retrieving revision 1.2
diff -u -r1.1.1.7 -r1.2
--- configure.in        7 Jul 2005 17:15:02 -0000       1.1.1.7
+++ configure.in        28 Sep 2005 17:53:35 -0000      1.2
@@ -88,7 +88,6 @@
 packagesrcdir=`cd $srcdir && pwd`
 AC_DEFINE_UNQUOTED(PACKAGE_SOURCE_DIR, "${packagesrcdir}", [source dir of the package])

-CFLAGS=
 dnl Use -Wall if we have gcc.
 changequote(,)dnl
 if test "x$GCC" = "xyes"; then
Index: src/Makefile.am
===================================================================
RCS file:
/home/djpig/vcs/cvs/Projekte/debian/gtkpbbuttons/src/Makefile.am,v
retrieving revision 1.1.1.3
retrieving revision 1.2
diff -u -r1.1.1.3 -r1.2
--- src/Makefile.am     28 Jan 2005 11:23:45 -0000      1.1.1.3
+++ src/Makefile.am     28 Sep 2005 17:53:35 -0000      1.2
@@ -21,9 +21,7 @@
 gtkpbbuttons_LDFLAGS = @PBB_LDFLAGS@

 if DEBUG
-AM_CFLAGS = -g -DDEBUG
-else
-AM_CFLAGS = -O2
+AM_CFLAGS = -DDEBUG
 endif

This still adds -Wall wether the user wants or not but at least
he can override everything else...

Please note though that this changes the build behaviour so that
now the program will always compiled with -g (because
that's the standard autotools behaviour which was broken by the
current code).

If you want to really simplify things just delete the whole code block
and let users always decide which CFLAGS they want by specifying them
to ./configure.
If you want to complicate things (one never knows), copy AC_PROG_CC
and patch it so that it does what you like. This would enable you
to safely check for CFLAGS inherited by the environment because it
is cleary impossible to do that _after_ AC_PROG_CC ...

(I used that ocasion of fiddling with Makefile.am to also update the
gtkpbbuttons automake stuff to automake 1.9)

Gruesse,
-- 
Frank Lichtenheld <dj...@de...>
www: http://www.djpig.de/

Re: Question about CFLAGS handling in configure.in

[Matthias G. <mat...@us...>]

On Fri, 30 Sep 2005 00:57:59 +0200
Frank Lichtenheld <dj...@de...> wrote:

> If you want to really simplify things just delete the whole code block
> and let users always decide which CFLAGS they want by specifying them
> to ./configure.

Ok, I like thinks simple :-) I will remove the code in the next releases.
I tested it with pbbuttonsd so far and it worked good.

> (I used that ocasion of fiddling with Makefile.am to also update the
> gtkpbbuttons automake stuff to automake 1.9)

What have you changed here?

I don't like automake 1.7 and higer much because you get a lot more
warnings which I don't know what they are talking about. Furthermore
you can't easily see anymore which file is currently compiled becasue
each compiler call is embraced with a shell script and the output
clutters the terminal window. Why can't they filter the output like the
kernel Makefile does? Nevertheless you should be able to use automake
1.9.

 Best Regards
  Matthias