Packaging the new OSLib release

[John Tytgat]

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

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

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