Re: Multiple shared libraries with a single spec

[Niklas Holsti <nobody@nowhere.fi>]

Lucretia wrote:
> Hi,
> 
> One of the things I need to know how to achieve is having a single
> specification but different bodies, to create a set of similar shared
> libraries. As an example, take the implementation of some maths
> routines (vector). I can have a version which will work on all machines
> i386 and FPU, then more specific versions which use SSE, MMX, etc. All
> of these different libs do the same thing, have the same spec, but
> different bodies. So I may have a directory structure like this:
> 
> vector.ads
> i386/vector.adb
> i386/libvector.so
> sse/vector.adb
> sse/libvector.so
> mmx/vector.adb
> mmx/libvector.so
> 
> <snip>
> 
> I have just created a test program which creates 2 shared libs (in
> separate directories with separate makefiles) and then created adalib
> and adainclude directories in which the lib, ali and ads files were
> linked to. I then built the test app which linked to the files in
> adalib and adainclude. I could then use a symlink to change the library
> used. This works, but I'm not too sure if it's the correct way to do
> this.
> 
> Has anyone else done this sort of thing with GNAT?

I'm working on an Ada program that has different versions, as in 
your example. I put the different versions of the package bodies 
(and specifications, too, for some packages) in different 
source-code directories, as you do. To build a specific version of 
the program, I list the source-code directories for the desired 
version in ADA_INCLUDE_PATH (and also in ADA_OBJECTS_PATH, but I 
think this is unnecessary for me) and then run "gnatmake" in a 
directory dedicated to this version. The .ali and .o files and the 
executable go in this version-specific directory. I don't use 
symlinks, just ADA_INCLUDE_PATH.

Mine is a simple and crude approach (it recompiles everything 
separately for each version of the program instead of sharing the 
compilation of shared libraries) but it works well enough for me. 
The library code changes so rarely that its recompilation time is 
irrelevant.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .