[Bug other/59365] Configure script does not pass CFLAGS/CXXFLAGS down to subtargets @ stage1

["djfd at mail dot ru" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59365

djfd at mail dot ru changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|WORKSFORME                  |FIXED

--- Comment #10 from djfd at mail dot ru ---
(In reply to Andrew Pinski from comment #8)
> (In reply to djfd from comment #7)
> > just noticed. there is ./config/mt-ospace file with the contents
> 
> That is a prebuilt target config. You can do the same for you need too.
> FOR_TARGET is the target libraries options that are used.
> 
> GCC Makefile options are different from most Makefiles due to not all
> options supplied work for the first or later stages. Think you start with
> something besides GCC which don't take say -fmyoption but the new GCC does.
> You cannot simply set CFLAGS to -fmyoption as that won't work. The other way
> around is the same issue. This is why CFLAGS is only done for host
> libraries. 
> 
> 
> > # Build libraries optimizing for space, not speed.
> >  CFLAGS_FOR_TARGET = -g -Os
> >  CXXFLAGS_FOR_TARGET = -g -Os
> > 
> > it is resulting to next lines in Makefile:
> > #### host and target specific makefile fragments come in here.
> > CXXFLAGS_FOR_TARGET = $(CXXFLAGS) -D_GNU_SOURCE
> > # Build libraries optimizing for space, not speed.
> >  CFLAGS_FOR_TARGET = -g -Os
> >  CXXFLAGS_FOR_TARGET = -g -Os
> > ###
> > 
> > BUT at that moment we have already C(XX)?FLAGS_for target set earlier:
> > CFLAGS_FOR_TARGET = -g --sysroot=/
> > CXXFLAGS_FOR_TARGET = -g --sysroot=/
> > 
> > thus, when we choose to optimize target libraries for size, our custom flags
> > will be overwritten. Maybe it would be better to have ./config/mt-ospace
> > like this:
> > # Build libraries optimizing for space, not speed.
> >  CFLAGS_FOR_TARGET += -g -Os
> >  CXXFLAGS_FOR_TARGET += -g -Os
> > 
> > (append instead of replace)

Well, that is fine. Beside the options I am using ( btw, these are
understandable by both compilers, working one and the one to be built),
conceptual question still remains. Is it ok if some prebuilt target config
*destroys* already established (it does not matter what way was used:
prepending to configure, passing to make, using -e option) flags and assigns
new ones "-g -Os"? If user set some C(XX)?FLAGS then it means he knows what he
is doing and he is required in these options. But configure script considers
user's approach is wrong and assigns own flags )) that is good!