Re: Multiple shared libraries with a single spec

[Stephen Leake <stephen_leake@acm.org>]

"Lucretia" <lucretia9@lycos.co.uk> writes:

> Stephen Leake wrote:
>
>> > 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.
>>
>> It's one valid way, and has the advantage of being compiler
>> independent. But it isn't operating system independent; you can't do
>> this on Windows.
>
> This isn't compiler independent as the library generated won't be able
> to be used from another Ada compiler, i.e. the name mangling may not be
> the same.

What I meant was 'using file system symbolic links' is compiler
independent. My option of using GNAT project files is not compiler
independent. 

Hmm. Maybe I misread what you wrote, and you didn't mean 'file system
symbolic links'.

> But you should be able to do this on Windows, 

Windows does not support file system symbolic links.

>> > Has anyone else done this sort of thing with GNAT?
>>
>> I use GNAT project files for this; one project file per target. The
>> Source_Dirs value specifies what Ada bodies to use, by specifying the
>> directory search path. All objects are placed in one build directory;
>> one build directory per target.
>
> Hmmm, haven't used project files yet.

They are very nice. For example, they make it easy to specify compiler
options on a per-file basis (which I use to work around compiler bugs
:). 

> I ask about this, because I'm generating 2 libs, each have slightly
> different ALI's and I was wondering whether this way would cause
> problems in the future?

Of course it can cause problems. But using per-target build
directories, and using project files, can solve those problems.

-- 
-- Stephe