Re: [RFA 1/2]: Don't ignore target_header_dir when deciding inhibit_libc

[Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>]

> From: Ulrich Weigand <uweigand@de.ibm.com>
> Date: Tue, 6 Oct 2015 18:55:53 +0200

> Hans-Peter Nilsson wrote:
> 
> > Sanity-check: you do have a $target_header_dir/stdio.h right?
> 
> Well, no.  That was the point of my original mail :-)

But you apparently have something that *would* fit.

> > Maybe make with_headers=yes (i.e. not a path) have the effect of
> > setting target_header_dir to include instead of sys-include?

(...and inspect both, use the first one that works?)

> That would solve my problem.  However, if with_headers is not set at all,
> shouldn't we then *also* set it to include?

Definitely not, only one reason of several being as that'd break
current use.

> I don't really particularly want to use --with-headers, it's just that
> this is what worked in the past.  Ideally, it would be best if everything
> just worked as expected without any option if there are indeed already
> headers installed in the prefix.

--enable-dwim? :]

> > Anyway, with_headers=yes/no should simply short-circuit an
> > inspection of $target_header_dir regarding setting inhibit_libc.
> > I guess.  But then again, target_header_dir really needs to be
> > set usefully for inspection, or else every use of it needs to be
> > dominated by a with_headers=yes test or something.
> 
> Well, every other use of $target_header_dir does not in fact matter
> on the SPU (because they check for features that aren't present in
> newlib and/or on the SPU anyway).  That's why the weird behaviour
> did not really matter in the past ...
>
> So short-circuting just for inhibit_libc would get everything back
> to where we were before your patch.  But I agree this is not really
> the right solution.
> 
> My preferred solution would be to set $target_header_dir to include
> instead of sys-include, always.  I'm just a bit worried if this may
> break other users that have a workflow that somehow works with the
> current setup using sys-include.

(T would: proof of existence here.)  I'm more than worried!
Please don't suggest to change a toolchain configuration item
only because you used something that half-way worked, then
broke, like this.  Not the least when also saying the below:

>  I guess my underlying problem is
> that I don't quite understand how the whole sys-include thing was
> intended to work in the first place ... 

I don't know when "include" will work and not, in particular
compared to "sys-include".

> [ Note there's also CROSS_SYSTEM_HEADER_DIR, which is also sometimes
> set to sys-include ... ]

Always, in the absence of sysroot.

brgds, H-P