2016-03-14 14:35 GMT+03:00 Fat-Zer fatzer2@gmail.com:

2016-03-14 6:35 GMT+03:00 Slávek Banko slavek.banko@axis.cz:

...

On Thursday 25 of February 2016 04:27:55 Fat-Zer wrote:

...

subj; Build files are mostly identical but usability test are required.

I'm a little confused. Although in Makefile.am libraries have given version 3.0.2, when building using automake libraries are created with version 1.2.0! It is not clear to me what causes 3.0.2 => 1.2.0. Hovewer, during build along with a patch for cmake conversion libraries are created with version 3.0.2. This causes an unexpected change in version number of libraries.

We should change the version in the cmake patch to 1.2.0?

I believe there is some bug in the autotools because Makefiles.am contains "-version-info 3:0:2"; I've got no idea where 1.2.0 may show up from...

PS: May those changes break anything?

2016-03-14 18:33 GMT+03:00 Slávek Banko slavek.banko@axis.cz:

Dne po 14. března 2016 Fat-Zer napsal(a): I traced that it's not a bug in autotools, but that there are two different options:

-version-info current[:revision[:age]]

If output-file is a libtool library, use interface version information current, revision, and age to build it (see Versioning). Do not use this flag to specify package release information, rather see the -release flag.

-version-number major[:minor[:revision]]

If output-file is a libtool library, compute interface version information so that the resulting library uses the specified major, minor and revision numbers. This is designed to permit libtool to be used with existing projects where identical version numbers are already used across operating systems. New projects should use the -version-info flag instead.

Source: http://www.gnu.org/software/libtool/manual/html_node/Link-mode.html#Link-mod...

When instead of -version-info 3:0:2 is used -version-number 3:0:2, the library gets the expected ouptut file:

@libkolf.so @libkolf.so.3 *libkolf.so.3.0.2

Automake option -version-info is obviously something else than VERSION for cmake build. I think that's not a good idea to change the version number of the libraries, when there is no reason to do so. I therefore propose to change the in cmake files VERSION to 1.2.0.

What is your opinion?

-- Slávek

Ok... Go ahead...

I still don't really understand what the version-info is and what for libtool versioning is used but I figured out how the "1.2.0" is related to 3:0:2 : It's (current-age).(age).(revision).

2016-03-15 0:27 GMT+03:00 Slávek Banko slavek.banko@axis.cz:

On Monday 14 of March 2016 17:52:39 Fat-Zer wrote:

...

I still don't really understand what the version-info is and what for libtool versioning is used but I figured out how the "1.2.0" is related to 3:0:2 : It's (current-age).(age).(revision).

Can make a sense to add to the macro tde_add_library possibility to specify version by option VERSION_INFO - with the same behavior as is in libtool? What do you think?

IMHO it doesn't... I'm still not sure, but I suspect the "version-info" is just a libtool-specific way to set the library version and to deal with the dependency hell... Normal conventions like «you increase major if you break backward compatibility, you increase minor if you break forward compatibility and you increase revision if you break neither» seams to me more straight-forward and got mostly the same meaning... May be this version syntax is also a workaround for some weird platforms nobody cares about any-more. Afterall I don't think we are in general too careful (should we/are we?) about such things because of very limited man-power... so I suspect we don't even really support release mixing (do we?) and there are no third-party applications that depends on us (except a couple in the neighbouring thread)...