Jesse Keating wrote:
On Tue, 2009-04-21 at 15:27 -0600, Jerry James wrote:
I've seen a number of cases where the upstream developers think they know the best compiler flags to use, so they ignore the usual means of supplying CFLAGS and just set their own. This means that the /how/ you are asking for involves manual inspection of configuration scripts and makefiles. Fun for the whole family!
In some cases yes, but in the general case, I had to do make %{?_smp_mflags} CFLAGS="$RPM_OPT_FLAGS"
and I had to google around to figure out where to stuff the RPM_OPT_FLAGS at. This kind of info should be in the guidelines.
Current paragraph: """ Compilers used to build packages should honor the applicable compiler flags set in the system rpm configuration. As of Aug 2006, this means in practice $RPM_OPT_FLAGS/%{optflags} for C, C++, and Fortran compilers. Honoring means that the contents of that variable is used as the basis of the flags actually used by the compiler during the package build. Adding to and overriding or filtering parts of these flags is permitted if there's a good reason to do so; the rationale for doing so should be reviewed and documented in the specfile especially in the override and filter cases. """
Proposed additional paragraph:
""" Most C, C++, and Fortran programs will pick up the correct compiler flags from the %configure macro. If your program does not use %configure the de facto standard is that C compiler flags are picked up via the CFLAGS make variable, C++ Compiler flags via the CXXFLAGS variable, and Fortran flags via FFLAGS. So, you could have something like this in your spec file:
<pre> make CFLAGS=%{optflags} all </pre>
If the build still does not pick up the proper compiler flags, you will have to look in the configure script or Makefiles to diagnose what's going on. """
If you guys like this, I'll propose it to the Packaging Committee.
-Toshio