[gccsdk] Autobuilder library packaging

Theo Markettos theo at markettos.org.uk
Sun Dec 6 08:37:54 PST 2015

Alan intended to send this to the list...

----- Forwarded message from alan buckley <alan_baa at hotmail.com> -----

From: alan buckley <alan_baa at hotmail.com>
To: Theo Markettos <theo at 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

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.


----- End forwarded message -----

More information about the gcc mailing list