Alan intended to send this to the list... ----- Forwarded message from alan buckley <alan_...@hotmail.com> -----
From: alan buckley <alan_...@hotmail.com> To: Theo Markettos <t...@markettos.org.uk> Subject: RE: [gccsdk] Autobuilder library packaging Date: Mon, 30 Nov 2015 08:44:10 +0000 > On Sun, 29 Nov 2015 23:15:21 +0000 Theo Markettos wrote: > > Can someone explain the difference between the three library packaging > streams? I've been trying to work out what's happening with DeskLib, and > I'm a bit confused. > > There are three archives made: > autobuilder_libraries/desklib_svn_...tar > autobuilder_libraries/desklib_svn_...zip > autobuilder_packages/Library/desklib_svn...zip > > I had assumed that autobuilder_packages/.../*.zip was for publication of RISC > OS > builds that are destined for PackMan installation - ie should be RISC OS > applications containing files suitable for use by a compiler on RISC OS, ie > suffix swapping (h/foo). That is correct. > > I'd assumed that autobuilder_libraries was for downstream consumption by the > autobuilder - ie you can untar autobuilder_libraries/*.tar in your > GCCSDK_INSTALL_ENV to allow the cross compiler to use that library. > > It seems that autobuilder_libraries/*.zip are getting suffix swapped, but > autobuilder_packages/**/*.zip are not. But autobuilder_libraries/*.zip are > not being packaged, they're just collections of header and library files. > So if users install the autobuilder_packages/**/*.zip then they have files > in RISC OS called include.foo/h which GCC won't find. > > I can understand the need for two library packages, but three? > http://www.riscos.info/index.php/Autobuilder_development > just says 'Libraries: to be added' > Originally autobuilder_libraries was zip file with the headers and static libraries in unix format. Peter Naulls created them for me so I could build programs on Cygwin which needed libraries I could not create on Cygwin. They were then also used as an intermediate step in creating the packages for libraries. i.e. they were unzipped copied to the correct place for the package and suffix swapped in the ab_package function in setvars. At some stage it appears that someone modified the ro-libpack file that creates these to do suffix swapping here as well. I'm not sure why. Theo, I thought you created the tgz files for consumption by Jenkins, but it looks like they were done by someone else. I've just modified them so they include symbolic links to work better with Jenkins. Hopefully someone can come along and explain why ro-libpack was changed. I suspect we can probably get rid of the zip file, and use the tgz file in the same way the zip file used to be used. In my opinion, what should be happening in the future is that autobuilder_packages stays the same as it is. i.e. versions destined to be unpacked and used on RISC OS machines via PackMan or the website with suffixes swapped, and autobuilder_libraries should only contain one of tgz or zip which is in a format that can be consumed by Jenkins, copied to a new unix machine and used by ab_package to create the library packages. > Where is the right place to put suffix swapping so that combinations work > out? The Desklib setvars just says: > > ab_package() { > > ab_create_app DeskLib Apps/Library desklib > > rsync -av --exclude='*/.svn*' ../\!DLUser $A/.. > rsync -av --exclude='*/.svn*' ../\!DeskLib $A/.. > rsync -av --exclude='*/.svn*' ../Examples $A/../\!DeskLib > > $AB_HOME/add-riscpkg -name DeskLib -unixlib > } > > Which looks pretty uncontroversial to me. I haven't looked at RISC OS > packages of other libraries, but imagine they're similarly affected. That's fine. It's probably done that way as DeskLib is a pure RISC OS library. As I said above some ported library, also create the autobuilder_libraries version first and then use that in packaging. If Jenkins ever needs to build something that uses DeskLib, it will probably need to create an autobuilder_libraries version as well. This should be done using the variables, so ro-libpack is called. AB_INSTALLENV etc? Sorry I can't check what they are at the moment. > > I can figure some things out from the code, but was wondering what the > philosophy was supposed to be, so I don't end up breaking other things. > I hope that explains it, there have been some modifications I don't understand though and it looks like it could do with being cleaned up. Regards, Alan ----- End forwarded message ----- _______________________________________________ GCCSDK mailing list gcc@gccsdk.riscos.info Bugzilla: http://www.riscos.info/bugzilla/index.cgi List Info: http://www.riscos.info/mailman/listinfo/gcc Main Page: http://www.riscos.info/index.php/GCCSDK
