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

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

Hans-Peter Nilsson wrote:
> 
> > From: Ulrich Weigand <uweigand@de.ibm.com>
> > Date: Tue, 6 Oct 2015 18:55:53 +0200
> 
> > > 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?)

So what does "works" mean, here?  Do you expect that all headers are
present either in include or all in sys-include?  Or is there a
scenario where some headers may be in either directory, and you'd
have to check separately for any header you want to access?

> > 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".

So I wondering: what is your current setup?  What headers do you have
in sys-include, and how did they get there?  I'm aware of the copying
done when using --with-headers=<dir>, but this case should still work,
since $target_header_dir is set directly to <dir> in this case anyway.
Is there some *other* case, where you do not use --with-headers=<dir>,
but still have a pre-existing sys-include directory in the prefix?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com