Hans-Peter Nilsson wrote: > > > From: Ulrich Weigand <uweig...@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.weig...@de.ibm.com
