R devel - Mar 2007 - PKG_CFLAGS/CFLAGS and PKG_CXXFLAGS/CXXFLAGS

Why is it that R places CFLAGS after PKG_CFLAGS and not before when  
compiling a package (e.g. through R CMD build pkg)? This can be  
problematic if, for instance, you want to use -O3, but -O2 is in  
R_HOME/etc/Makeconf. If -O2 (in CFLAGS) appears after -O3 (in  
PKG_CFLAGS), you are left with what you didn't want: -O2.

In R-exts, it says that "Flags which are set in file etc/Makeconf can  
be overridden by the environment variable MAKEFLAGS (at least for  
systems using GNU make), as in (Bourne shell syntax)" but this  
doesn't work if I set either MAKEFLAGS or CFLAGS/CXXFLAGS in my  
configure.ac script or package Makevars.

Does anyone have any ideas on how to reliably override the default  
CFLAGS/CXXFLAGS given in Makeconf?

Many thanks,

Ernest

On Mar 20, 2007, at 7:58 PM, Ernest Turro wrote:
> Why is it that R places CFLAGS after PKG_CFLAGS and not before when
> compiling a package (e.g. through R CMD build pkg)? This can be
> problematic if, for instance, you want to use -O3, but -O2 is in
> R_HOME/etc/Makeconf. If -O2 (in CFLAGS) appears after -O3 (in
> PKG_CFLAGS), you are left with what you didn't want: -O2.
>
> In R-exts, it says that "Flags which are set in file etc/Makeconf can
> be overridden by the environment variable MAKEFLAGS (at least for
> systems using GNU make), as in (Bourne shell syntax)" but this
> doesn't work if I set either MAKEFLAGS or CFLAGS/CXXFLAGS in my
> configure.ac script or package Makevars.
In you example above you want to force the user to use a higher  
optimization flag. But (s)he may have very valid reasons for not  
doing so - and are you really sure that you are comfortable setting - 
O3 on _all_ platforms? Also -O. is GCC specific so it does not work  
for all compilers.

If a user really wants a super fast R (s)he will (should) compile it  
with -O3.

Having said that, I think it is problematic that one cannot   
_downgrade_ the optimization. I am maintaining a package including an  
external library (outside of my control) which does not work with -O2  
on some platforms, due to alignment problems.
> Does anyone have any ideas on how to reliably override the default
> CFLAGS/CXXFLAGS given in Makeconf?
I was given the following code some while ago by Simon Urbanek:

all: $(SHLIB)

MYCXXFLAGS=-O0

%.o: %.cpp
         $(CXX) $(ALL_CPPFLAGS) $(ALL_CXXFLAGS) $(MYCXXFLAGS) -c $< - 
o $@

(this is for C++, I imagine the syntax is straightforward for C). Put  
it in src/Makevars.

But as I said above, I think it is a bad idea to raise the  
optimization level for all users.

Kasper
> Many thanks,
>
> Ernest
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

On 20 March 2007 at 18:58, Ernest Turro wrote:
| Why is it that R places CFLAGS after PKG_CFLAGS and not before when  
| compiling a package (e.g. through R CMD build pkg)? This can be  
| problematic if, for instance, you want to use -O3, but -O2 is in  
| R_HOME/etc/Makeconf. If -O2 (in CFLAGS) appears after -O3 (in  
| PKG_CFLAGS), you are left with what you didn't want: -O2.
| 
| In R-exts, it says that "Flags which are set in file etc/Makeconf can  
| be overridden by the environment variable MAKEFLAGS (at least for  
| systems using GNU make), as in (Bourne shell syntax)" but this  
| doesn't work if I set either MAKEFLAGS or CFLAGS/CXXFLAGS in my  
| configure.ac script or package Makevars.
| 
| Does anyone have any ideas on how to reliably override the default  
| CFLAGS/CXXFLAGS given in Makeconf?

It's one of my token problems too for the Debian package builds. 

Often it is simply not possible to do this easily due to the automated
insertion 'at the wrong' place that you mention.  

One way around is to set CFLAGS (or CXXFLAGS) inside a MAKEFLAGS variable. It
must be properly quoted -- which seems to lead to the restriction that you
get only one token at a time, see below.

I.e. the following was once useful when I needed to tone down the
optimization due to an architecture-specific optimisation bug:

	MAKEFLAGS="FFLAGS=-O1" R CMD INSTALL -l $(debRlib) --clean .

An example of the 'one toke only' problem is 

	MAKEFLAGS="CXXFLAGS+=-I/some/path/some/header \
		CXXFLAGS+=-I/some/other/header \
		LDFLAGS+=-L/some/where \
		LDFLAGS+=-llibfoo LDFLAGS+=-llibbar"  \
		R CMD INSTALL foo

This issue has come up before, and e.g. Kurt has, IIRC, made some suggestions
about overrides below ~/.R.  In my particular case that wouldn't always help
as automated Debian builds are disconnected from individual user accounts.

Dirk

-- 
Hell, there are no rules here - we're trying to accomplish something. 
                                                  -- Thomas A. Edison