Open kloczek opened 4 years ago
Also compare #102
I would like to close it based on not supporting automake builds anymore.
In the cmake variant the test-binaries are downloaded in the configure-step. Since it is hard to create problematic zip-files on-the-fly, those "bad zip" files are needed to get a proper idea if things do work.
In the cmake variant the test-binaries are downloaded in the configure-step. Since it is hard to create problematic zip-files on-the-fly, those "bad zip" files are needed to get a proper idea if things do work.
Are you aware fact that most of the build systems used by differebt distributions are intentionally cut off from public network? Why it is not possible to distribute those files with dist tar ball?
@kloczek - there is no tarball generation anymore in the sense that automake would package a list of files.
The intention of the current setup is to allow tests to be skipped if the binaries are not available. Stopping the download with -DZZIP_TESTCVE=OFF should be possible.
The intention of the current setup is to allow tests to be skipped if the binaries are not available. Stopping the download with -DZZIP_TESTCVE=OFF should be possible
That is OK however I think that those test units are not about testing donloading sometning so IMO still it would be good to add those test files to source tree and sist tarr ball.
BTW just tested 0.13.72 and looks like there in new version when cmake is used there is no test suite
+ cd zziplib-0.13.72
+ /usr/bin/make -O -j48 V=1 VERBOSE=1 -C x86_64-redhat-linux-gnu test ARGS=--output-on-failure
make: Nothing to be done for 'test'.
[tkloczko@barrel x86_64-redhat-linux-gnu]$ cmake -L
CMake Warning:
No source or binary directory provided. Both will be assumed to be the
same as the current working directory, but note that this warning will
become a fatal error in future CMake releases.
CMake Error: The source directory "/home/tkloczko/rpmbuild/BUILD/zziplib-0.13.72/x86_64-redhat-linux-gnu" does not appear to contain CMakeLists.txt.
Specify --help for usage, or press the help button on the CMake GUI.
-- Cache values
BUILD_SHARED_LIBS:BOOL=ON
BUILD_STATIC_LIBS:BOOL=OFF
BUILD_TESTS:BOOL=ON
CMAKE_BUILD_TYPE:STRING=RelWithDebInfo
CMAKE_INSTALL_PREFIX:PATH=/usr
MKZIP:FILEPATH=/usr/bin/zip
MSVC_STATIC_RUNTIME:BOOL=ON
UNZIP:FILEPATH=/usr/bin/unzip
XMLTO:FILEPATH=/usr/bin/xmlto
ZZIPBINS:BOOL=ON
ZZIPDOCS:BOOL=ON
ZZIPFSEEKO:BOOL=ON
ZZIPMMAPPED:BOOL=ON
ZZIPSDL:BOOL=ON
ZZIPTEST:BOOL=ON
ZZIPWRAP:BOOL=ON
ZZIP_COMPAT:BOOL=ON
ZZIP_HTMLSITE:BOOL=OFF
ZZIP_HTMPAGES:BOOL=OFF
ZZIP_INSTALL_ACLOCAL:BOOL=ON
ZZIP_INSTALL_BINS:BOOL=ON
ZZIP_LIBTOOL:BOOL=ON
ZZIP_MANPAGES:BOOL=ON
ZZIP_PKGCONFIG:BOOL=ON
ZZIP_TESTCVE:BOOL=ON
You can disable tests from the default ZZIPTEST:BOOL=ON and there is target "check" as I used it to have.
The binaries will not go into the source tree. I am doing devops consulting as a day job where the existance of a binary repository can be assumed. The current project allows to pre-download the CVE zips and to copy them to the internal network if the build processes require that depth of checks. For packagers of opensource distributions it will work to wrap the pre-downloaded cve zips into a tarball as a kind of patch object. I don't see a need to support more than that.
In general it would be great if the cve zips can be generated through code - at the moment I don't know how they came to be originally, and I am just including them for regression testing, so that the problems do not come up again.
You can disable tests from the default ZZIPTEST:BOOL=ON and there is target "check" as I used it to have.
Hmm .. but why you are breaking semantics of cmake/ctest and provide test suite under DIY target?🤔
BTW: do you have any plans to make new release soon?
Any update about use standard ctest instead custom target? 🤔