[fpc-pascal] Re: linux: should we hard-code versioned or unversioned shared libraries in our apps?

[Reinier Olislagers]

On 15-8-2012 16:19, Michael Van Canneyt wrote:
> On Wed, 15 Aug 2012, Reinier Olislagers wrote:
>> On 15-8-2012 15:59, Graeme Geldenhuys wrote:
>>> Umm, so ideally the ibconnection.pp unit should really be split into
>>> various units with version numbers in their names. That way we will
>>> know to which Firebird version they are referring too.
>>>
>>> eg:   ibconnection.pp   // old interbase only (eg: Delphi 7)
>>>         firebird-1.x.pp
>>>         firebird-2.1.pp
>>>         firebird-2.5.pp
>>>
>>> Include files could probably be used to reduce some duplication of code.
>> OT: that would be useful for another reason.
>> Firebird 3 will introduce the BOOLEAN datatype and other innovations
>> (encrypted connections, etc).
>> Interbase has had BOOLEAN support for a while now.
>>
>> It would be nice to be able to support new functionality without
>> sacrificing the ability to connect to older clients.
> 
> That has nothing to do with dyn versus static linking.
Yes, that's why I mentioned it's OT ;)

> You can perfectly detect which library version you are loading, and
> enable/disable certain functions based on this.
Ok.
And you can use the (Firebird/Interbase Services IIRC) API to get the
server version. I seem to remember Ludo's recent addition to FPC has
this functionality.

> Firebird has a long tradition of keeping the API and structures
> backwards/forwards compatible, thus obliviating the need for different
> units for each version.
Yep.

> Conclusion: At least for firebird, there will be 1 unit, loading
> dynamically what is available. If you want to load something else than
> the default, you have been able to do so since day 1.
> 
> Contrary to Marco's belief, I am firmly convinced that this is the best
> and easiest approach.
As far as FB is concerned, that might indeed very well be true.

Thanks,
Reinier