search

gdraheim / zziplib

The ZZIPlib provides read access on ZIP-archives and unpacked data. It features an additional simplified API following the standard Posix API for file access
Other
62 stars 50 forks source link

change to cmake #23

Open gdraheim opened 6 years ago

gdraheim commented 6 years ago

zziplib has been used outside of the unix-world quite heavily where it is beneficial to create a build pipeline without make.

There had been some examples floating around that showed how to build zziplib with cmake. The only problem was that they did mostly only care about zzip/.c but not bins/ or the variant-builds of 32/64 off_t.

Those example should be reviewed and integrated into the main zziplib.

mojca commented 6 years ago

Or meson?

gdraheim commented 6 years ago

cmake allows to generated even vstudio/msbuild input files, which is sometimes used for zziplib by other developers.

mojca commented 6 years ago

Isn't that the case for meson as well?

The only annoying part is that it won't (yet?) generate project files for an arbitrary non-installed version of MSVS. And that it's slightly less straightforward to install it on Windows.

paroj commented 6 years ago

maybe you can build upon this: https://github.com/paroj/ZZIPlib/commit/ffa7f0c35144de24f38d1ee4721b317de9bc83da

paroj commented 6 years ago

@mojca VS has native CMake support since VS15, whereas a meson build would be as alien as the current autotools solution. https://docs.microsoft.com/en-gb/cpp/ide/cmake-tools-for-visual-cpp

mojca commented 6 years ago

I agree that a built-in support for CMake makes quite a difference, but it's not true that meson would be equally alien. Autotools are by definition Windows-unfriendly, while meson is simply too new to catch up with CMake's popularity just yet. It is in my opinion far easier to use than either CMake or autotools and it's totally windows-friendly. I was pulling my hair off when trying to implement cross-compilation for Windows in CMake, while it was a piece of cake with meson, including the ability to run the unit tests with wine without any additional configuration whatsoever. They offer msi installer and I assume one doesn't really need anything else to use it from VS.

Not that this is really relevant since you need someone to eventually write the code, and random users' opinion does not count unless they contribute patches. I just wanted to point out that meson should not be compared to autotools. At least on Windows it's by far superior choice compared to autotools (which is basically useless unless used via msys or cygwin).

gdraheim commented 6 years ago

I have added the patch from @paroj to the "develop" branch which can now build with cmake.

I do compile tests with make all and the resulting shared libraries seem to be correct. However the testsuite has not been checking on it.

So more testing is needed before it may be shipped. I'll keep the "master" branch using the automake build system to allow downstream distro makers to provide patches easily.

gdraheim commented 6 years ago

I have added dozens of commits on the "develop" branch while working on the cmake scripting. I think that the structure is far better than automake, so I would like to stay with it.

However... I did find a difference between cmake linking and automake's libtool linker. That's because I had used the "--release 0" feature of the latter, which leads to "libzzip.so" symlink to "libzzip-0.so13.0.69". Note the different basename whereas cmake only has a single "output_name" which is either "libzzip" or "libzzip-0".

I can fix that with a postinstall shell script so that cmake has about the same effect as libtool. That will work on linux/solaris and similar operating systems with a *.so/*.sl shared library format (bsd, hpux, aix). I am not sure sure about osx *.dylib and win *.dll. And what about android or even embedded systems?

In any case @paroj and @mojca .... would you be able to check on osx / win configurations with cmake to match with the old automake stuff? Or do you think that automake had not been used for that for a while anyway? I don't like to break binary compatibility just for changing over to cmake linking.

paroj commented 6 years ago

actually I just write a small cmake file whenever I encounter an autotools build on windows as it is faster then getting autotools to run there for me. Therefore I would say we just should not care. Can not say anything about for OSX. Seems the brew repository is just using *.so libs like on Linux though.

gdraheim commented 4 years ago

It took some time to create some test cases that could show the cmake approach makes the same files as the automake approach. But it is looking good now.

I haope that it can also fix the windows and darwin problems. @paroj and @mojca

paroj commented 4 years ago

some of the latest changes broke the static build on android & iOS: https://travis-ci.com/github/OGRECave/ogre/jobs/320742335#L751

will try the v0.13.71 tag

gdraheim commented 4 years ago 
-- lib zzipfseeko  to be compiled: OFF
-- lib zzipmmapped to be compiled: OFF

I haven't tried this one in my testbuilds.py.... but it does look related to the error. @paroj

gdraheim commented 4 years ago

@paroj - see the latest patch on develop. May be that helps.

paroj commented 4 years ago

that gets me to the next error: https://travis-ci.com/github/OGRECave/ogre/jobs/320758264#L768

v0.13.71 works though, so I will stay with that for now

gdraheim commented 4 years ago

I had renamed ZZIPCOMPAT to ZZIP_COMPAT to be in line with the newer options.

However that should not make the step itself to fail

[  8%] Generating compat/zzip.h
/bin/sh: 1: ../sh: not found
zzip/CMakeFiles/compat.dir/build.make:60: recipe for target 'zzip/compat/zzip.h' failed
make[2]: *** [zzip/compat/zzip.h] Error 127
CMakeFiles/Makefile2:94: recipe for target 'zzip/CMakeFiles/compat.dir/all' failed
make[1]: *** [zzip/CMakeFiles/compat.dir/all] Error 2
Makefile:129: recipe for target 'all' failed
make: *** [all] Error 2