[GSOC] : Patches for merging different syslog.h

[Joel Sherrill]

On 4/14/2013 5:46 PM, Chris Johns wrote:
> Joel Sherrill wrote:
>> On 4/14/2013 11:50 AM, Rempel, Cynthia wrote:
>>> Wow, there are a lot of header files... Looks like we might be
>>> identifying which headers to not install more than merging, in either
>>> case, verifying each change to the installed headers won't break
>>> something will probably not be possible over the summer, so one of the
>>> primary goals of this project would be to outline how to identify
>>> which installed headers should be private (and not install them
>>> instead of merging them), and then outline how to merge the headers
>>> together by name.
>> Good point. Not installing a conflicting .h file is even better. :)
>>
>> If you only need <uart.h> to build your BSP. Leave it in the source
>> tree. This IS TESTABLE because the scope of the change is limited.
> When I last looked there where about 5 uart.h files and all were
> different so you need to find them, match them to the specific source
> and rename.
>
>> I am assuming that for chip specific .h files, this is possible but for
>> bus oriented ones
>> which might be used to access cards/devices added by the user, this is
>> not possible.
>> For example, user applications might include device drivers for VMEBus,
>> CompactPCI,
>> PCI, and AMBA bus devices.
> I seem to remember there is also case problems. One or more headers have
> different cases for the same name. This also needs to be fixed. The
> issues show up on file systems that are case insensitive.
Are you wanting all to lower case? Or just to compare "basename" in a case
independent manner?
> There are also a class of files with almost the same contents. These
> require more effort because you need to make sure you can merge them,
> rename them or what-ever.
And these are often deliberately duplicated since the RTEMS model is
to use the same file name supported by different targets and BSPs.
I hope we are proposing that  the files which do not fit "known patterns"
for source portability are the candidates.

In other words. We are not merging the contents of all bsp.h files. But
there shouldn't be twelve files installed as <bsp/uart.h> since that doesn't
fit any "portability pattern".

That's why I said we had to know the rules for the duplicate file names.
bsp.h, bspopts.h, tm27.h, support for frameworks, are allowed.
Arbitrary reuse of an installed file name is not.
> Chris


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985