[GSOC] : Patches for merging different syslog.h
Rempel, Cynthia
cynt6007 at vandals.uidaho.edu
Sun Apr 14 16:50:08 UTC 2013
Hi Vipul Nayyar,
Thanks for doing this research! This is really encouraging!
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.
I suspect the following headers should be verified as private /machine/, and /bsp/ (and not to be installed)
I have no idea if /score/ headers should be public or private, but they might be private, (in which case we could ask they not be installed instead of merged)... further research of the rtems documentation is needed
Not merging some of the /sys/ headers may be okay (depending on opengroup guidance).
Part of this project could be to outline how we can verify not installing those headers won't break building external applications, such as example-v2, then to outline what's left to do (hopefully we could get this detailed out to the point we could take care of this using Google Code In 2013/2014 assistance, as the remaining work lends itself to micro-projects).
I suspect one approach to verifying we can get by with not installing private headers is to export the rtems/testsuite to a stand-alone git, so it's an external application, and build the testsuite again on a fresh rtems install for each removed header. We would probably also want to include script to check the output of the testsuite for breakage. Running the script would have to be documented in the README. We would also want a to keep the exported testsuite as in sync with the internal testsuite as feasible... to export the testsuite means dealing with a small amount of issues with the build system... but this would also require assistance from someone with committer access...
Once that's completed, the outline could be improved by using it to identify which private headers we can get rid of, and submitting patches to rtems-devel to make them private, and verifying all the steps for the outline are there... it may be interesting to see what headers still need merging after not installing them (if any)...
If it helps, typically I update the preinstall.am by runing ./bootstrap -c && ./bootstrap -p && ./bootstrap .
Over the summer, we typically have patches reviewed on rtems-devel to verify we don't accidentally break something... We'll probably need to identify which committer(s) will commit your patches, although we may be getting build-bot at some point, but I'm not sure how soon that will happen...
Hope this helps! Thanks again for the script, seeing the big picture sure puts things into perspective...
Cynthia Rempel
________________________________________
From: Vipul Nayyar [nayyar_vipul at yahoo.com]
Sent: Sunday, April 14, 2013 7:27 AM
To: Rempel, Cynthia
Cc: rtems-devel at rtems.org
Subject: [GSOC] : Patches for merging different syslog.h
Hello Cynthia Rempel,
As advised by you, I tried to merge header files with same name getting installed into different places. For this task, I chose to merge two 'syslog.h' files present in libnetworking directory , as a starting point. After merging them and editing other files which required this header file, I re-compiled RTEMS successfully. I've attached two patches with this email. Please check them if they're ok and good to be applied.
To have an idea that how many duplicate header files are actually present in /opt/rtems-4.11/sparc-rtems4.11 , I wrote a shell script for that. The output of that bash script is also attached with this email. As you can see in that text file, there are quite many duplicate header files present . Please tell me any plan or steps that I should use to merge so many files, if possible.
Also please explain the procedure to obtain committer access as written here : http://rtems.org/wiki/index.php/Git_Committers.
Thanks for your support in advance.
Regards
Vipul Nayyar
Computer Engineering
Jamia Millia Islamia
New Delhi
More information about the devel
mailing list