<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/3.26.0">
</HEAD>
<BODY>
On Fri, 2010-03-19 at 12:06 -0700, Dan Nicholson wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
On Fri, Mar 19, 2010 at 11:42 AM, Gaetan Nadon
&lt;<A HREF="mailto:gaetan.nadon@videotron.ca">gaetan.nadon@videotron.ca</A>&gt; wrote:
&gt;
&gt; Rather than posting 43 patches, I'll summarize the changes and include the
&gt; diffs here.
&gt;
&gt; Automake produces a warning about the INCLUDES variable being deprecated.
&gt; There were only 43 out of 240 modules still using it. It has been replaced
&gt; with AM_CPPFLAGS. In some modules, both INCLUDES and AM_CPPFLAGS were used.
&gt;
&gt; Further more, there isn't a good separation between pre-processor and
&gt; compiler flags. The lint tool only accepts pre-processor flags, so the lint
&gt; target had to be reworked. Separation is also required to allow user to
&gt; override with CFLAGS and CPPFLAGS on the configure invocation.
&gt;
&gt; In addition of replacing/merging INCLUDES and AM_CPPFLAGS, compiler and
&gt; pre-processor flags have been regrouped in AM_CFLAGS and AM_CPPFLAGS
&gt; respectively. The order of -I has been preserved the INCLUDES variable
&gt; taking precedence over AM_CPPFLAGS. Attention has been given so as not alter
&gt; the final gcc command emitted. One exception is that Automake does not pass
&gt; pre-processor flags when linking a library which were previously lumped
&gt; together with C flags.

I'm not sure that putting the package CFLAGS into AM_CPPFLAGS won't
cause problems. While it's very likely that $(PKG_CFLAGS) only
contains preprocessor directives, we don't know that and have no way
of enforcing it. I think it would be better to take the safe route and
put them in AM_CFLAGS even if it means -I include paths will be passed
when linking.

</PRE>
</BLOCKQUOTE>
It's been a real pain to decide. Either way there are potential problems. Tools like lint don't like compiler flags, but you can workaround that. I have seen some projects making patches essentially for two reasons. One is that some compilers will break, which does not seem to be our case, and that users can't override correctly with CFLAGS and CPPFLAGS, which may be for the same first reason.<BR>
<BR>
The server sticks -fvisibility compiler flag in the pkg Cflags which does not help while 99% of pkg-config files on my distro are compiler flags free. I don't see an elegant solution to this. There are a few modules where some improvement can be made, I'lll submit those individually.<BR>
<BR>
Thanks<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
--
Dan
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>