[galtgendo o2 pl: Re: gtkmm and autoconf]



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]