Hi Jeroen, On Thu, May 22, 2014 at 9:27 PM, Jeroen Hofstee <dasub...@myspectrum.nl> wrote: > Hello Vasili, > > On wo, 2014-05-21 at 11:50 +0300, Vasili Galka wrote: > >> >> This pattern is a >> >> result of the original decision from 2004 to prioritize the host >> >> include paths over the paths from U-Boot tree. >> > >> > any reference? >> >> This decision is a part of the above mentioned commit: e1a3f6b (July 2004) >> I don't know how much the original committer was aware of its long >> term implications. > > If the only valid reason is "Fix host tools building in Cygwin > environment" as mentioned in the original commit, then I am all in favor > of dropping it and finding a decent solution for cygwin. > >> >> I see this happening >> >> again and again with different headers in the future. So here comes >> >> the question, is it really the right thing prioritize the include >> >> paths this way? Why do host paths MUST come first? >> >> I'll try reverting this locally and looking what breaks and what >> >> alternative solutions exist. >> > >> > I have no idea why it is the way it is, but keep in mind that e.g. stdio >> > headers in u-boot is quite something different then stdio for the target >> > userland. >> >> Sure. I'll keep it in mind while I'm designing a solution here. I'm >> afraid there is no easy way to fix it though. >> > This is easier than it sounds. U-boot is build with -nostdinc for the > binary itself. And it tries to get the compiler related includes back > with "isystem $(shell $(CC) -print-file-name=include". (and the printf > declaration and friends are actually in common.h for the loader, which > makes it even harder to do it wrong by accident). > > Can you check what "arm-none-eabi-gcc -print-file-name=include" returns > on cygwin? > > mmm, this one might be also be a challenge for cygwin: > "dirname `arm-none-eabi-gcc -print-libgcc-file-name`", but you will > likely get linker errors if that contains spaces / backslashes or simply > fails. > > But perhaps even easier, can you post the problems you encounter if you > remove the idirafter. Likely easier then guessing what can go wrong in a > cygwin build. > > Regards, > Jeroen > >
Let's suppose there is an application in tools directory that requires both "libfdt_env.h" (from uboot tree) and "errno.h" (from host environment). However, as both headers exist at both places, in the uboot tree and on the host environment, there is no way to solve this just by altering the include paths order. For any reshuffling both headers will be taken either from uboot or from host - which is undesired. I can only think of one bulletproof solution that would fix the above problem. Unfortunately it's conceptual and requires much work: * Currently, almost all include derectives in in uboot code use <> style. I propose to modify this concept. * For each #include directive the developer shall decide from where the header file is obtained - U-Boot source tree or the host environment. * Depending on that, "" shall be used only for headers from U-Boot tree, <> shall be used only for all other (host provided in tools folder) * The -iquote compiler flag can be used for adding "" search paths. The -I flag for adding <> paths. Of course that's just a draft of the idea. What do you think? Best, Vasili _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
