Further cmake modernizations

[pedrolcl]

After #969 already merged, I've found a few rusty pieces. The first one is:

https://github.com/FluidSynth/fluidsynth/blob/015c6af52d8233eaae556242b5200290558ba415/CMakeLists.txt#L35

For CMake 3.13 and later, there is another project() command signature: https://cmake.org/cmake/help/v3.13/command/project.html

This also would simplify the following lines (and related):

https://github.com/FluidSynth/fluidsynth/blob/015c6af52d8233eaae556242b5200290558ba415/CMakeLists.txt#L41-L46

Another proposal is to remove the following code which is utterly deprecated:

https://github.com/FluidSynth/fluidsynth/blob/015c6af52d8233eaae556242b5200290558ba415/CMakeLists.txt#L886-L903

It may be replaced by a git export command, but anyway the cpack targets (package, package_source) already provide a quick and easy way of packaging as tarballs both the sources and the binaries. It only needs modernization this line:

https://github.com/FluidSynth/fluidsynth/blob/015c6af52d8233eaae556242b5200290558ba415/CMakeLists.txt#L921

If nobody needs/uses it, the alternative is to remove the cpack support entirely:

https://github.com/FluidSynth/fluidsynth/blob/015c6af52d8233eaae556242b5200290558ba415/CMakeLists.txt#L909-L931

[derselbst]

Thanks for bringing this up.

1. I don't see too much benefit in moving to the new project() syntax.
2. true, can be removed
3. I never used cpack before. Github takes care of creating the source tarballs. I just tried creating the binary tarball and this looks promising. Maybe I'll use it for tarball creation in our CI build in the future. So I'd prefer to keep it.

[pedrolcl]

Thanks for bringing this up.

1. I don't see too much benefit in moving to the new project() syntax.

It is only a cosmetic thing for now, but the advantage to adopt it early (well, it has been around since cmake 3.0) may be that the moment cmake deprecates the old syntax, there will be no hurry to migrate.

3. I never used cpack before. Github takes care of creating the source tarballs. I just tried creating the binary tarball and this looks promising. Maybe I'll use it for tarball creation in our CI build in the future. So I'd prefer to keep it.

Github does a git export for each tag, which is fine. Also git export is easy to execute by hand too. CPack is handy for packaging at any arbitrary time, by anybody, saving the packaging specs together with the build system specs. BTW, some metadata is populated from the project() new signature variables :slightly_smiling_face: Reference https://cmake.org/cmake/help/latest/module/CPack.html#packaging-targets

The real star is the huge collection of generators it provides, for instance the NSIS and WIX generators for Windows. Reference: https://cmake.org/cmake/help/latest/manual/cpack-generators.7.html

[derselbst]

I think most of / all of the points should be addressed by now. I'll keep cpack in mind.