Packaging the new OSLib release

[John Tytgat]

In message <SNT136-ds10A8C11DB5B54EAE7E5CEBF0310 at phx.gbl>
          "Alan Buckley" <alan_baa at hotmail.com> wrote:

> > John Tytgat wrote on Thursday, Dec 13, 2012 6:03 PM:
> 
> > 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.

Are the boost libary build differences also ABI differences ?

> > 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.

After giving this a bit of thought I think it would be less confusing
and less trouble for the user and later support to have only one OSLib 7.00
packages and holding the different flavours internally.  And have
by default setup the OSLib$Dir/OSLib$Path to the AOF flavour (which is
compatible with 6.80).  And include 3 obey file inside !OSLib which
redefine OSLib$Dir/OSLib$Path for the 3 other flavours : GCC4 UnixLib,
GCC4 SCL App and GCC4 SCL Mod.

So the Norcroft/GCC3 users don't have to change anything after OSLib 7.00
upgrade.  The GCC4 users have to run the right Obey file once before
compiling.

We can workout the details via private mail if you want.

Aside, it crossed my mind that for a next version of OSLib, the GCC4
flavours could only be headers and no library (or a very small one) as
all the SWI stub code can actually be inlined in the header.  But that's
only applicable for OSLib not OSLibSupport and needs first to be tried
out if that really would work out.

> 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.

Indeed.  And I'm also hesitent to create possible legacy packages
by doing this.

> 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.

The less setup needed the better of course.  But on the other hand,
I wouldn't be surprised if most programmers didn't have a setup file to
run for building their project.  Can't be hardly the end of the world.

> 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.

Again, introducing extra system variables will require changing Makefiles
if you want to use them.  I don't see any improvement in doing that.

John.
-- 
John Tytgat, in his comfy chair at home
John.Tytgat at aaug.net