[Xenomai-core] Re: [PATCH] move RTDM headers

[Philippe Gerum <rpm@xenomai.org>]

Jan Kiszka wrote:
> Philippe Gerum wrote:
> 
>>Jan Kiszka wrote:
>>
>>
>>>Philippe Gerum wrote:
>>>
>>>
>>>>Jan Kiszka wrote:
>>>>
>>>>
>>>>
>>>>>Hi Philippe,
>>>>>
>>>>>this patches cleans up the include/rtdm folder by moving internal
>>>>>headers to ksrc/skins/rtdm, leaving only rtdm.h, rtdm_driver.h, the two
>>>>>profile headers, and syscall.h there. The latter is still only needed
>>>>>for building Xenomai itself, thus it will not be installed.
>>>>>Successfully
>>>>>built for 2.4 and 2.6. Additionally, I compiled latest RTnet SVN
>>>>>against
>>>>>it without problems (x86, PPC is currently being fixed by Wolfgang).
>>>>>
>>>>>Please apply/move the involved headers and run bootstrap.
>>>>>
>>>>
>>>>This one broke the build here:
>>>>
>>>>-- 
>>>> CC      kernel/xenomai/skins/rtdm/core.o
>>>>kernel/xenomai/skins/rtdm/core.c:36:18: core.h: No such file or
>>>>directory
>>>>kernel/xenomai/skins/rtdm/core.c:37:20: device.h: No such file or
>>>>directory
>>>>-- 
>>>
>>>
>>>
>>>Updated your repos? As you forgot to apply the moving, I also got
>>>problems and applied my local versions of core.h, device.h, and proc.h,
>>>also removing the three from their previous location.
>>>
>>
>>The problem is that the patch does not recreate those files in
>>ksrc/skin/rtdm, but only deletes them from include/rtdm.
>>
> 
> 
> Oops, indeed. I was sure "svn diff" will include locally added files in
> the output, but it didn't -- ah, my svn version is too old! :)
> 
> 
>>>>Additionally, it's a really very bad idea to start including things like
>>>>"core.h" removing the rtdm/ prefix, while other include files like
>>>>nucleus/core.h exist. For the sake of readability, I'm going to revert
>>>>this particular change at least.
>>>>
>>>
>>>
>>>That's why I use #include "core.h", which -for me- clearly states: "Pick
>>>the local one!"
>>
>>
>>Nope, it "states pick the first one you find outside of the system dirs
>>depending on the order of the directories listed by -I in your
>>Makefile", which is quite different, and leads to all sort of
>>braindamage issues if you happen to screw up your CFLAGS in your Makefile.
> 
> 
> #include "file.h" -> start searching for file.h in that place you found
> the file containing this statement. Likely one can overwrite this
> behaviour with some strange gcc flags.
>

-I- for instance, which bluntly cancels the above behaviour. One 
sometimes may have to make extensive use of it to work around funky 
include directory layouts some applications have; early versions of the 
simulator had even needed this to somewhat control which portion of the 
"include space" was picked.

> 
>> You will now have to tweak the Makefiles again...
>>
>>
>>That's ok, I will do that. The prefix rule is enforced everywhere for
>>internal headers so that nobody gets mad trying to find why the wrong
>>one is included, and the best way not to depend on "-I" pecularities is
>>to avoid playing with them in the first place. Additionally, this leaves
>>no doubt about which header you wanted to include, regardless of the
>>sanity of your Makefile.
> 
> 
> Ok, it's a matter of taste, and if you like to keep it this way for all
> skins, I'm fine with it.
> 
> Jan


-- 

Philippe.