[U-Boot] [RFC] Proposal to change include search model

[Vasili Galka]

Hi Jeroen,

On Tue, Jun 10, 2014 at 11:40 PM, Jeroen Hofstee <dasuboot at myspectrum.nl>
wrote:
> This sounds way too complex if you ask me for what your are trying to
> fix. For one thing #include<> versus include "" is compiler specific and
> not defined in general. If I find some time I will see if I can find
> another solution for it. But you're warned heads up that it might
> include one additional -I for standard c libraries for the target (which
> is only errno.h at the moment, afaik) ;)

1. What do you mean by "complex"? Do you think this change will make the
life of the developers more difficult? Or do you mean the amount of work
required to implement this proposal? If the later, I tried it and already
have an almost working version.

2. Regarding <> versus "" - it's a very good point. Although I doubt that
someone builds U-Boot on a different compiler than gcc (maybe clang - which
claims to be compatible). So I don't see a reason to strictly stick to
the C standard. Besides, all compilers I see behave the same on this point.
But in any case, you can see the rule <> vs "" just as an emphasis for
readability.
If this poses a problem with a different compiler in the future (which I
strongly doubt), the -iquote can be replaced by -I and everything shall
continue to build. Because the key idea here is that most of the headers
are specified with path prefixes (u-boot/ inc/ arch/ soc/) which prevents
possible clash with headers provided by environment.

3. When I think about it, maybe it's a good idea to simplify further and
use "u-boot/include/xxx.h" form instead of "inc/xxx.h". A little more
lengthy but much more explicit. One less link to create.

4. Regarding the standard C libraries, I don't really understand why
   -nostdinc -isystem $(shell $(CC) -print-file-name=include)
is used at all. How does it differ from the standard paths that are
searched if these flags are dropped?

Many thanks for the feedback!

Best regards,
Vasili