Am 03.02.21 um 13:03 schrieb jp charras:
> OTOH, a version.h file is not a bad idea (read: for me a very good idea):
>
> at least the name is already a useful comment and it request only a very
> few amount of work.
>
> Many tools use this trick (for instance opencascade, and most of other
> to
Le 03/02/2021 à 11:38, Carsten Schoenert a écrit :
Hello Holger,
Am 03.02.21 um 11:20 schrieb Holger Vogt:
I remember some time ago I tried to address the libtool versioning, but
I did not understand it, so abandoned it again.
libtool isn't really easy, yes, but the more complicated thing is
Hello Holger,
Am 03.02.21 um 11:20 schrieb Holger Vogt:
>
> I remember some time ago I tried to address the libtool versioning, but
> I did not understand it, so abandoned it again.
libtool isn't really easy, yes, but the more complicated thing is to
integrate the things correctly into configur
I remember some time ago I tried to address the libtool versioning, but
I did not understand it, so abandoned it again.
What about adding and distributing alongside of sharedspice.h a version
header file verngspice.h which contains only some version info?
Holger
_
On Wed, Feb 3, 2021 at 7:34 AM Holger Vogt wrote:
> To obtain version information of the currently available libngspice-0.so
> version, you might do the following:
>
> load libngspice-0 dynamically
> initialze libngspice
> send the command 'version -s'
> retrieve some text response similar to the
Am 03.02.21 um 08:34 schrieb Holger Vogt:
> To obtain version information of the currently available libngspice-0.so
> version, you might do the following:
>
> load libngspice-0 dynamically
> initialze libngspice
> send the command 'version -s'
> retrieve some text response similar to the followi
6 matches
Mail list logo
