Re: Fwd: [PATCH] gcc: Fix sysroot relative paths for MinGW

[Jeff Law <law at redhat dot com>]

On 09/29/2016 09:21 PM, Tadek Kijkowski wrote:
> Can I have plain-text mode, please, gmail?
:-)  Only because you're asking nicely...



> > >  # Directory in which the compiler finds libraries etc.
> > >  libsubdir =
> > > $(libdir)/gcc/$(real_target_noncanonical)/$(version)$(accel_dir_suffix)
> > >  # Directory in which the compiler finds executables
> > > @@ -2751,14 +2763,14 @@
> > >  PREPROCESSOR_DEFINES = \
> > >    -DGCC_INCLUDE_DIR=\"$(libsubdir)/include\" \
> > >    -DFIXED_INCLUDE_DIR=\"$(libsubdir)/include-fixed\" \
> > > -  -DGPLUSPLUS_INCLUDE_DIR=\"$(gcc_gxx_include_dir)\" \
> > > +  -DGPLUSPLUS_INCLUDE_DIR=\"$(call
> > > sysroot_relative_path,$(gcc_gxx_include_dir),$(filter-out
> > > 0,$(gcc_gxx_include_dir_add_sysroot)))\" \
> >
> > So why the $(filter-out 0, ....)?
> >
> > I'd really like to avoid being too clever here and write this code in the
> > most straightforward way possible.
>
> Hmm... that's partially leftover from the abandoned idea to pass
> @TARGET_SYSTEM_ROOT@ as second parameter of sysroot_relative_path.
> Sysroot is prepended to GPLUSPLUS_INCLUDE_DIR in runtime only if
> $(gcc_gxx_include_dir) is 1.
> Since sysroot_relative_path checks for non-empty string the easiest
> way was to use filter-out. But I agree this way it's confusing.
>
> How about if I change the sysroot_relative_path function to explicitly
> check for 1? But still - since $(if) checks for empty string, it will
> have to use filter or filter-out.
I think with the improved comments you showed in V2, that'd be fine.


> N.B. I'd prefer to use backticks over "$()", but it could clash if
> some include paths already contain backtick expressions.
So the concern is we might use backticks to get an evaluation of 
something at build time.  Conceptually one could even create a pathname 
with literal backticks, but I suspect somewhere, somehow that's going to 
fail independent of your change.

Jeff