Hi, > I couldn't help myself from trying to make a more convenient build > process for zlib and libarchive. > > I added a new CMakeLists.txt to the external folder. It's purpose is to > build both zlib and libarchive in one go. It seems to work alright on my > machine. One CMake configure and one mingw32-make command generates the > library files for both zlib and libarchive. I don't know how robust the > process is, but it would definitely be neat to make it work in this way.
The issue of taking the correct versions of libarchive were mentioned in my previous email. The problem with CMake, though, is that CMakeLists.txt in libarchive contains a find_package(zlib), which I doubt will work when using add_subdirectory(). The reason is that at the point of probing zlib, the (static) zlib library has not been built yet, so find_package() will *always* fail. You can find some background on this in this write-up: https://coderwall.com/p/y3zzbq The suggested use of external_project() is probably worth a try, but zlib does not export its targets. This implies that we would have to modify CMakeLists.txt from zlib, which is something I'd really like to avoid, as it will sooner or later result in maintaining our own zlib repository. Anyway, feel free to play with that, maybe you can find a more convenient solution to this. > One thing to note is that zconf.h kept on being renamed to zconf.h.in > <http://zconf.h.in> by CMake, which prevented compiling zlib. I had to > manually rename it back to zconf.h after each CMake configuring. I noticed the same, but it is not a problem if you build in-source, i.e. source dir and build dir are equal. CMake generates a 'new' zconf.h in the build directory. Another reason to follow the build instructions closely ;-) > And if we were to go back to submodules, we could build all the > dependencies with no more than 4 commands: > 1. git submodule update ---init (both zlib and libarchive automatically > fetched by git) won't work with libarchive because of build failures if the version of archive and the OS version don't match up. > 2. configure external CMake build (properly prepare libarchive with zlib) > 3. generate external CMake makefiles 2.) and 3.) don't sound much shorter than what we have now? > 4. build the libs (generate zlib, then libarchive libs with one make > command) This boils down to find_package() in libarchive being able to detect zlib without zlib being built yet... > Would this be a good solution to simplify the build process? Is it feasible? I tried various options yesterday for a couple of hours but could not find a fully satisfying solution. This does not mean that there is no better way than what we have now, but at least the current build process is verified to work on two different OSes with different compilers. More than we had before ;-) Best regards, Karli ------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds _______________________________________________ ViennaCL-devel mailing list ViennaCL-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viennacl-devel
