Hey,
The reason submodules don't work is that libarchive does not compile with
> the latest tip on Visual Studio, so one has to use the last v3.1.2 release.
> On Linux, v3.1.2 fails due to missing CMake scripts, so one has to use the
> latest master. I could not find a way to set this up correctly with git,
> unless we exclude on operating system upfront.
> This is exactly why I added 'git checkout v3.1.2' in the build
> instructions and the reason for the failures mentioned above. ;-)
I see. So, v3.1.2 should be used on Windows, and the latest master should
be used on Linux?
> I'm confused. There should be no .dll from neither libarchive nor zlib in
> use here. That's the whole purpose of the Findarchive-static.cmake and
> Findzlibstatic.cmake scripts: They only grab the static libraries and link
> these.
Well, I guess the static libraries aren't used when building on Windows.
The program works only if libarchive.dll is in the same folder as the
executable. It seems that only zlib is linked statically.
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.
I used external_project() the first time I integrated Libarchive. Later
switched to add_subdirectory() thinking it was better that way... I'll try
with external_project() one more time.
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 ;-)
Is there no other way to fix this except building in-source? Not that
building in-source is a problem.
2.) and 3.) don't sound much shorter than what we have now?
I think they do. The idea is to configure and generate with CMake only once
(both zlib and libarchive with one CMakeLists). Currently, one must
configure zlib, generate zlib makefiles, build zlib, configure libarchive,
generate libarchive makefiles, and build libarchive. Having one CMakeLists
ofr both of them wouldn't be *that* much of an improvement, but would
certainly help ease the process.
This boils down to find_package() in libarchive being able to detect zlib
> without zlib being built yet...
And how can we test this? The libarchive.dll generated with the CMakeLists
I added in external/ folder works fine with the benchmark executable. Which
means (I think) that both zlib and libarchive were properly built and
linked.
Regards, Namik
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/viennacl-devel
