[Buildroot] $(TARGET_CONFIGURE_OPTS) $(MAKE) vs $(MAKE) $(TARGET_CONFIGURE_OPTS)

[Bernhard Fischer <rep.dot.nop@gmail.com>]

On Mon, Jul 09, 2007 at 03:41:35PM +0200, Julien Letessier wrote:
>I'm following the discussion and would like to make a point:
>all of this is irrelevant for packages that use the GNU auto* tools properly
>(i.e. a whole lot of packages).
>
>Their configure script uses the TARGET_CONFIGURE_OPTS to generate correct
>makefiles, and no flags should thereafter be passed to $(MAKE) directly (or
>they'll break).
>So IMO,
>  $(MAKE) -C $(FOO_DIR) $(TARGET_CONFIGURE_OPTS)
>will almost always break such a package. Even packages that just
>  $(MAKE) -C $(FOO_DIR) CC=$(TARGET_CC)
>break more often than not.

yes. we should not change stuff after the configure stage.
[]
>>> 2) CFLAGS are wrong as CXXFLAGS
>>>
>>So when compiling C++ code, and if I want the -Os and other options,
>>how do you suggest we pass them.

Unfortunately we will have to have TARGET_CXXFLAGS or filter out flags
from CFLAGS that are rejected by the CXX compiler. The latter is of
course ugly and will most likely not work reliably.
I do not see a viable alternative to TARGET_CXXFLAGS (or fortran, ada,
java, objc, you-name-it for that matter).
>>
>>> 3) since your change we end up using the default flags from the
>>> packages, which more often than not default to -O2. Let me refer you to
>>> options.c of gcc (or the respective docs for the gory details).
>>>
>>Thanks, I am able to read code.

yea, i know.
>>
>>> I am going to revert this change for now. What were you trying to
>>> do/solve?
>>>
>>A number of packages break unless the above is done. By overriding
>>CFLAGS in the top-level makefile, CFLAGS in packages themselves get
>>overridden and fail to build. Essentially if you do not like the
>>method above, then a bunch of packages will need to be changed in
>>order to work properly with CFLAGS be specified at the very top.

Patching the affected packages is cumbersome and complicates
maintenance. Just thinking loud.. what about patching the cross-compiler
to use -Os unconditionally for any or no -O? Not really nice either, i
fear. The native compiler would not be affected by this.

What do you think?