----- Forwarded message from Rafał Mużyło <[EMAIL PROTECTED]> -----
Date: Sat, 4 Oct 2008 01:18:15 +0200
From: Rafał Mużyło <[EMAIL PROTECTED]>
To: Nicola Fontana <[EMAIL PROTECTED]>
Subject: Re: gtkmm and autoconf
Message-ID: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 -----
_______________________________________________
gtk-app-devel-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
