cmake issues:

Question

cmake issues:

sezero opened this issue 2 years ago · 20 comments

Unix full versioned name of libSDL2 (i.e. libSDL2-2.0.so.2.90.0)
is wrong: SDL's SDL2 branch creates libSDL2-2.0.so.0.2700.0, so we
should decide what to do.
P.S.: 90 looks like a bad version number, considering incremented
versions will quickly go past 99.
Mac: X11_INCLUDE_DIR usage is wrong: That variable is set by the
FindX11 module, and not by find_package()
Mac: X11_INCLUDE_DIR addition to include dirs should be conditional
(also see above):

CMake Error at CMakeLists.txt:74 (include_directories):
  include_directories given empty-string as include directory.

Mac linkage fails because we commented out DYLIB_COMPAT_VERSION
and DYLIB_CURRENT_VERSION setting and made them a FIXME instead.
We should set dylib versions. SDL2-2.26.0 sets its to 2601.0.
For simplicity, we can start to 2900.0 I guess. For compatibility
version: assuming that newer releases from SDL2 series won't add
new apis, we can set it to 2601.0? (@icculus?)

ld: malformed 32-bit x.y.z version number: -current_version
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [libSDL2-2.0.0.dylib] Error 1
make[1]: *** [CMakeFiles/SDL2.dir/all] Error 2
make: *** [all] Error 2

~~testgles* builds fail miserably when GLES[2] isn't installed~~
(fixed by #7)

CC: @madebr

Answer 1 · 2022-11-29T17:43:42.000Z

assuming that newer releases from SDL2 series won't add
new apis

I can't promise that. It would not surprise me if we had to, say, add a new game controller function or whatever in there before SDL3 is ready to ship.

That would be a "we need this right now" thing and not a "we're adding features to SDL" thing, though.

Answer 2 · 2022-11-30T00:07:52.000Z

I think all CMake issues have been addressed by #9, but somebody with a Mac should confirm.

About versioning, perhaps we should ask @smvc whether 2.90 is a good starting point and what pitfalls we should be aware of?

Answer 3 · 2022-11-30T00:12:37.000Z

DYLIB_COMPAT_VERSION and DYLIB_CURRENT_VERSION still need setting to proper values: Are those proper values supposed to match SDL2 cmake'ry?

Our version number 90 is probably bad (see above), but that's not a cmake issue.

Answer 4 · 2022-11-30T00:25:06.000Z

DYLIB_COMPAT_VERSION and DYLIB_CURRENT_VERSION still need setting to proper values: Are those proper values supposed to match SDL2 cmake'ry?

dylib versions should be solved by 06f3adb

Answer 5 · 2022-11-30T01:16:50.000Z

P.S.: 90 looks like a bad version number, considering incremented versions will quickly go past 99.

We can change this, but I just wanted it to be extremely far from anything real SDL2 might publish...also, like sdl12-compat, my intention was to never change the minor version (or only change it when the patch number gets really high), but just keep bumping the patch version...but I guess we have more flexibility here, since SDL 1.2 locked down that second number, and SDL 2.x started using it.

Assuming there will be more SDL 2.x.0 releases, using 50 seems too low. Maybe 70?

There was also a concern about SDL_VERSIONNUM not handling large numbers--I saw a patch go into SDL3 about it--but I don't know what the situation is with that.

Answer 6 · 2022-11-30T02:44:43.000Z

P.S.: 90 looks like a bad version number, considering incremented versions will quickly go past 99.

We can change this, but I just wanted it to be extremely far from anything real SDL2 might publish...also, like sdl12-compat,

Here is the math: sdl12-compat started with 50, we are now at 61, and considering the number scheme we've been following the next release will be 64, with only three (?) point releases. Unless we change that, sdl2-compat will have trouble.

Assuming there will be more SDL 2.x.0 releases, using 50 seems too low. Maybe 70?

Sensible, I guess.

Answer 7 · 2022-11-30T13:39:14.000Z

Alternately: we could say "this is meant to match SDL 2.26.0" and keep the version number in sync, until SDL stops getting new releases, and then carry on from there with new numbers.

Answer 8 · 2022-11-30T13:49:39.000Z

Alternately: we could say "this is meant to match SDL 2.26.0" and keep the version number in sync, until SDL stops getting new releases, and then carry on from there with new numbers.

Umm?? You mean make it 26, 28, ... and keep it in sync? If I read that correctly, sounds inviting trouble.
70 should be fine, I think. (What does the others say?)
EDIT: Can even make it 71 considering this is not a release version yet.

Answer 9 · 2022-11-30T14:01:45.000Z

Crazy idea... what if we keep it using double the public release minor version, and then bump patch release as needed?

Answer 10 · 2022-12-02T03:06:36.000Z

Verdict on versioning?

Answer 11 · 2022-12-02T17:43:00.000Z

Personally,I like @slouken's suggestion.
Freeze at 2.90, and shift SDL2's version.
So SDL2-compat 2.90.26.x is compatible with SDL2 2.26, SDL2-compat 2.90.28.x compatible with SDL2 2.28 etc.

Answer 12 · 2022-12-02T21:27:21.000Z

We only have a tuple for version, right? So you couldn't have 2.90.26.x

Answer 13 · 2022-12-02T21:57:02.000Z

With the SDL_version struct, yes.
CMake also has a tweak version.
Perhaps an idea for SDL3?
Adding an Uint8 tweak; to the SDL_Version struct is free, when you factor in alignment.

Back to versioning sdl2-compat, how about adding 50?
Then, you can still do 25 ordinary SDL2 releases before you bump into sdl2-compat's versions.

Is there a limit to 4 numbers to the SO minor version? Can't it be 10000, or more?

Answer 14 · 2022-12-02T21:58:38.000Z

There won't be 25 ordinary SDL2 releases. Let's just make it 2.50.x and call it a day.

Answer 15 · 2022-12-02T22:01:03.000Z

Will the development version be versioned 2.49 and bumped to 2.50 when released?

Answer 16 · 2022-12-02T22:01:31.000Z

Actually, we probably need to consider the fact that we may still add APIs to SDL2. I think the major and minor version of sdl2-compat needs to match SDL2, and maybe we start the patch version at 100?

Answer 17 · 2022-12-02T22:02:02.000Z

I don't think we'll have development versions of sdl2-compat.

Answer 18 · 2022-12-05T19:02:26.000Z

Actually, we probably need to consider the fact that we may still add APIs to SDL2. I think the major and minor version of sdl2-compat needs to match SDL2, and maybe we start the patch version at 100?

I'm fine with this. The reason I suggested we keep it in sync with SDL2 release numbers is that there could be programs that check for some future SDL 2.35.0 to see if an API is safe to use, and here we come with 2.70.0 that doesn't have that future API at all.

I don't think we'll have development versions of sdl2-compat.

Probably not in any serious way; sdl12-compat had to perform a lot of archeology and heroic efforts that I'm hoping we'll avoid here. But I may be a fool to believe this. :)

Answer 19 · 2022-12-05T19:34:18.000Z

Actually, we probably need to consider the fact that we may still add APIs to SDL2. I think the major and minor version of sdl2-compat needs to match SDL2, and maybe we start the patch version at 100?

I'm fine with this. The reason I suggested we keep it in sync with SDL2 release numbers is that there could be programs that check for some future SDL 2.35.0 to see if an API is safe to use, and here we come with 2.70.0 that doesn't have that future API at all.

That's why I suggested keeping the sdl2-compat major and minor versions in sync with SDL2 releases, and using patch 100+ to indicate sdl2-compat.

Answer 20 · 2023-08-03T15:31:18.000Z

This can be closed now: See #90