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
