[U-Boot] Building under Cygwin - "-ansi" flag?

[Vasili Galka]

Hi Masahiro,

>> 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.
>
> True.
> What we should do is not to tweak the inclusion order.
>
>
> I guess we should follow what happended in Linux Kernel world:
>
> They split out the user-space API content in separated headers
> and put them into  new   include/uapi/  and  arch/$(ARCH)/include/uapi/
> directories.
>
>
> So, the right direction we should go is:
>
> - Define the exact tools-API  which should be exported to
>   host program space. (For ex.  image structure)
>
> - Put the tool-API headers into a new directory.
>     (I have no idea about a good dir name.   include/host-api/ ? )
>  This directory is added to include-path for  both U-Boot and host programs.
>
>
>                include                                          include
>  U-Boot  ---------->   include/host-api/    <--------   Host programs
>
>
> U-boot  includes:  include/host-api/  +  include/   + arch/$ARCH/include/
>
> Host programs include:  include/host-api/ + headers provided by environments

What you propose sounds good. But are you sure that no tools require a
really deep details of U-Boot internals? In such case separating the
details into an interface won't be possible. If (hopefully) that's not
the case, interfaces seem to be the right direction. Although
implementing them requires great work.
In any case, as a new comer, I don't think I know U-Boot enough for
such design decision. I would be glad to hear the opinion of other
major developers.

As about the solution I initially thought of, here is a more detailed design:
https://docs.google.com/document/d/1D86EedRrViJHsTZrf9bEQB-DYsEweHDKaJyZYI2Yr3I/edit?usp=sharing
It does not contradict what you propose and these two can be used
together. My proposal does not target only the specific compilation
issues descussed here but the general ease of code understanding and
navigation. I think it is much easier to implement and can provide a
good short term solution. Since re-factoring host-api requires much
effort and deep understanding of existing code. The only drawback of
my proposal I see is the large patch footprint. But maybe you see
other weaknesses. I'll be glad for your opinion.

Best regards,
Vasili