Add versioning support and update CMake configuration

[lum1n0us]

No description provided.

[lum1n0us]

@jirutka Please inform me if platforms other than Linux require the SONAME feature.

[jirutka]

The same applies to all Unix and Unix-like systems, so also BSDs and macOS.

[yamt]

maybe you can do it for all platforms and let cmake do whatever appropriate?
https://cmake.org/cmake/help/latest/prop_tgt/SOVERSION.html

[yamt]

build-tested for macOS.

master:

libiwasm.dylib:
        @rpath/libiwasm.dylib (compatibility version 0.0.0, current version 0.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1351.0.0)

with this PR:

libiwasm.dylib:
        @rpath/libiwasm.2.dylib (compatibility version 2.0.0, current version 2.2.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1351.0.0)

iirc, on macOS, a dylib can be loaded if

• the filename matches
• and compatibility version is larger than requested

[yamt]

looks reasonable to me

[yamt]

can you document the procedure?
eg. 1. update version.cmake, 2. run something (what?) to regen this file, 3. commit this generated file as well.

[lum1n0us]

@yamt @loganek @TianlongLiang @xujuntwt95329 @wenyongh @no1wudi
Do you have any comments?

[TianlongLiang]

LGTM

[loganek]

frequent release cycle would strain customers' testing resources

Not sure if I agree with that; customers can still choose to stick to a particular version or keep moving to the latest one. In fact, for some of the usecases it more frequent releases are better as it helps narrowing down any potential regressions which can only be seen when running WAMR at scale.

and add extra deployment work

Agree with that, we should probably discuss automating the process within TSC as much as we can to streamline the releases.

[lum1n0us]

Are you proposing that we should streamline the release process (reduce manual work compared to the current method) and issue releases on a regular schedule, such as monthly?

[loganek]

given we have .in file now, does this file still have to be checked-in?

[lum1n0us]

thanks for reminding.

[lum1n0us]

@no1wudi We are considering generating the version.h file from version.h.in during the CMake configuration process and removing version.h from the source code tree. The Nuttx CI is failing because it uses make instead of CMake and cannot create the version.h file. Is there a method to still generate version.h using make?