[galtgendo o2 pl: Re: gtkmm and autoconf]

[Rafał Mużyło <galtgendo o2 pl>]

----- Forwarded message from Rafał Mużyło <galtgendo o2 pl> -----

Date: Sat, 4 Oct 2008 01:18:15 +0200
From: Rafał Mużyło <galtgendo o2 pl>
To: Nicola Fontana <ntd entidi it>
Subject: Re: gtkmm and autoconf
Message-ID: <20081003231815 GC2967 blackspire>
References: <20081002163104 GA18218 www2 mrbrklyn com>
	<1223024435 23455 38 camel murrayc-desktop>
	<20081003134454 432e6061 amd64 entidi local>
	<20081003171811 GB2967 blackspire>
	<20081004004229 7e46c432 amd64 entidi local>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20081004004229 7e46c432 amd64 entidi local>
User-Agent: Mutt/1.5.16 (2007-06-09)
Status: RO

This message was meant for the list. I accidentally sent
it only to a private email.


On Sat, Oct 04, 2008 at 12:42:29AM +0200, Nicola Fontana wrote:
> On Fri, 3 Oct 2008 19:18:11 +0200
> Rafał Mużyło <galtgendo o2 pl> wrote:
> 
> > On Fri, Oct 03, 2008 at 01:44:54PM +0200, Nicola Fontana wrote:
> > > On Fri, 03 Oct 2008 11:00:35 +0200
> > > Murray Cumming <murrayc murrayc com> wrote:
> > > 
> > > > or this might be better:
> > > > 
> > > > AM_CPPFLAGS = $(MYAPP_CFLAGS)
> > > > onwindow_LDADD = $(MYAPP_LIBS)
> > > 
> > > I don't know the technical difference (I always seen
> > > preprocessing and compilation in the same step), but is not
> > > AM_CXXFLAGS a better place for MYAPP_CFLAGS?
> > >
> > That's the whole point. Nearly all of 'pkg-config <package>
> > --cflags' I've seen were actually CPPFLAGS. So, placing them in CPPFLAGS
> > is more correct (if i.e. somebody wanted to separate preprocessing and
> > compilation). It's just like LDADD/LIBADD and LDFLAGS,
> > if the user adds -Wl,--as-needed to $LDFLAGS, things tend to break
> > if upstream put libs in LDFLAGS instead of LIBS.
> 
> maybe this is the common approach in C++ (for some unknown
> reason), but in C I'm seeing the reverse. Two notable examples
> are the Gtk+ itsself, that set the global CFLAGS in configure,
> and cairo, that use library specific CFLAGS. I always used
> AM_CFLAGS without problems.
>
I'm not saying that there are problems, it's just that i.e.
`pkg-config gtk+-2.0 --cflags` returns:
-D_REENTRANT -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include
-I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
-I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb
-I/usr/include/libpng12

All of those are preprocessor flags.

> Regardling LDADD/LIBADD and LDFLAGS the distinction between the
> two are quite clear: -l -L go into the former, the rest in the
> latter, always. Anyway, I can understand there could be corner
> cases when you would add libraries to LDFLAGS, and maybe you hit
> one of them.
> 
Those aren't exactly corner cases, I've seen many packages abusing
LDFLAGS in this way (meaning - adding libs to it), among other 
this causes AC_CHECK_LIB to fail when -Wl,--as-needed is in LDFLAGS.
(just make note that LDFLAGS may be both env var and automake var
and depending on context I'm refering to both those meanings).

> I'm talking from the C world: I wonder if the C++ world is so
> different but all can be possible.
>
OK, I've got no idea where is this coming from (especially
C++ part).

----- End forwarded message -----