Packaging the new OSLib release

[Alan Buckley]

> John Tytgat wrote on Thursday, Dec 13, 2012 6:03 PM:

> In message <SNT136-W535A8725EA67342FCBC4B2F04E0 at phx.gbl>
>           alan buckley <alan_baa at hotmail.com> wrote:

> > Hi I'd like to update my OSLib package at the
> > RISC OS packaging site to the new 7.00 version.
> >
> > To do so I think it would be simpler if I could
> > include all the different builds of the library
> > in a single !OSLib directory. Would you object
> > if I did this?

> I wouldn't object but just curious why it would be simpler, for you as
> packager, or as user ? I had (and still have) mixed feelings on whether
> to have OSLib 7.00 as one big release holding those 4 flavours, or
> having the 4 flavours separately released.  I went for the latter mainly
> because I thought I would be easier for the user, like "I'm using XYZ
> compiler so I need to download this zip file".

It's easier for me as a packager as there are fewer packages
and easier as a user as you can just get the OSLib package
and know you've got it all. I don't feel it's the end of the
world if it's not packaged this way though;-)

> > To be able to do this it needs that the only
> > difference between the various downloads is
> > the library files themselves (i.e. not the
> > headers or documentation). Is this the case?

> Documentation and the C/C++ headers are the same.

> The assembler headers are different for the AOF and ELF versions as the
> former follows the ObjAsm syntax (used by Acorn/Norcroft, GCCSDK GCC 3.4.x
> and AsAsm in GCCSDK GCC 4.x) and the latter the GNU as assembler syntax
> (used in GCCSDK GCC 4.x).

> > Also I will need to give different names to
> > the various variants of OSLib for the different
> > builds. Is this OK with you? If so do you have
> > any preferred nameing convention. My initial
> > thoughts were a code so we got.
> >
> > libOSLib32.a - standard soft-float unixlib build
> > libOSLib32h.a - hard-float unixlib build

> BTW, there is no hard-float UnixLib build.

> > libOSLib32s.a - SCL build
> > libOSLib32m.a - Module build
> >
> > The old AOF build can remain the same as it is
> > put in an "o" directory.
> >
> > (similar changes would be made to the support
> > library).

> I'm not in favour of changing the library leafname as this will
> result in changing Makefiles when people switch between the official
> OSLib binaries vs the packaged version of OSLib.  Neither I would like
> to set a precedent that different build options or runtime libraries used,
> result in different library names.

I was looking at things like the boost libraries and others which do
have different leaf names for various builds of the libraries.
See my comments later though.

> I can only come up with suggestion to create 4 (sub)directories holding
> the contents of the 4 flavours minus documentation and SetVars files
> and have at the directory holding those 4 subdirectories the documentation
> and 4 SetVars alike files selecting the right flavour.  Something like:

>   oslib-700
>     - SetVars Acorn GCC3         -> sets OSLib$Dir/OSLib$Path to Acorn 
> GCC3 subdir
>     - SetVars GCC4 UnixLib soft  -> sets OSLib$Dir/OSLib$Path to GCC4 
> UnixLib soft subdir
>     - SetVars GCC4 SCL App       -> sets OSLib$Dir/OSLib$Path to GCC4 SCL 
> App subdir
>     - SetVars GCC4 SCL Mod       -> sets OSLib$Dir/OSLib$Path to GCC4 SCL 
> Mod subdir
>     - ChangeLog, COPYING, OSLib_API, OSLib_readme, WideFuncts
>     - Acorn GCC3
>        - o
>           - OSLib32
>        - oslib
>           - h
>              ...
>           - Hdr
>              ...
>     - GCC4 UnixLib soft
>        - libOSLib32/a
>        - oslib
>           - h
>              ...
>           - Hdr
>              ...
>     - GCC4 SCL App
>        ...
>     - GCC4 SCL Mod

> And yes, this would duplicate the h and Hdr (ELF only) directory contents
> but it probably the least disruptive from user point of view.  He just
> dbl clicks on the right SetVars and he uses the right OSLib header/binary
> set.

The way OSLib is packaged at the moment is that there is a !OSLib and
!OSLibSupport application which sets the variables so you can use
the libraries just by adding -IOSLib: to the compile flags and
-LOSLib: -loslib to the linker flags. This has precedent with other
libraries in the RISC OS world and I believe is the recommended practice
on the RISC OS Packaging website. I personally find it a very convenient
way of using libraries when compiling on RISC OS.

So to achieve the equivalent of your suggestion above I would
either want to create packages for each variant or use the
suffixing above.

It sounds as if you would prefer different packages. If this
is still the case can you tell me which is equivalent to OSLib 6.80
as I want to upgrade this with the equivalent new package.

The other packages will need to be named differently, maybe
OSLibUnixLibSoft, OSLibSCLApp, OSLibSCLMod. This also means
you will need to change your make files. I can't see any real
way around this though for packaging.

My preferences at the moment is have OSLib for Acorn/GCC3
and OSLibELF (or OSLibGCC4) for the others with suffixes for
the variants. Your objection about the official and packaged
OSLibs being different makes a lot of sense to me, but I
strongly believe I should be able to install OSLib and then
use it without having to figure out and run a SetVars script
somewhere first.

I know it's a cheeky suggestion, but you could always
modify your official OSLib to set a new OSLibELF variable
and use the suffixes so the packaged and non-packaged
versions work the same.

Regards,
Alan