Hey,
But does it also decompress the .tar.gz files? That's a direct test for it.
> If zlib isn't used inside libarchive, it will try to either run gzip (and
> fail) or throw an error right away. I had a couple of such builds when I
> tried to use both with add_subdirectory()
At first I also thought it won't be able to decompress them. But, after
testing it seems it indeed does decompress .tar.gz files.
I used a dependency checker program to see what dlls were used by the
libarchive dll created with your CMake build, and compared it to the one
created with my build. And there's something very interesting about them:
-your libarchive.dll has a libzlib.dll dependency that is apparently
missing, but the program works non the less
-my libarchive.dll has no mention of lizlib.dll at all, yet the program
works with it as well
If there's no libarchive.dll in the exe's folder, then the program fails to
start, saying that it's missing libarchive. Which means libarchive wasn't
statically linked.
I am now completely confused. These 'magical' build system issues and
solutions are very demoralizing to say the least. The build works, but how
and why remains a mystery to me. I vote we leave it as it is. I'll see what
I can do to bring QMake up to date and that's it. I've had enough of CMake.
Gonna focus on the GUI now.
Regards, Namik
On Sun, Aug 3, 2014 at 6:02 PM, Karl Rupp <r...@iue.tuwien.ac.at> wrote:
> 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?
>>
>
> Yep.
>
>
>
> 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.
>>
>
> With Visual Studio it just linked with the static libraries. Maybe MinGW
> requires extra care, or the Findarchive-static.cmake needs to be polished?
>
>
>
> 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.
>>
>
> I can't think of a fix if the constraint is to *not* alter the included
> CMakeLists.txt. Well, we could of course ask the package maintainer to
> change this...
>
>
>
> 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.
>>
>
> Sure, if you can simplify the current process without sacrificing
> portability, please go for it :-)
>
> Another option to *greatly* simplify the process is to write our own
> decompressor for .tar files. This would allow us to get rid of libarchive
> completely, and the .tar format is not that complicated. Have a look here:
> http://en.wikipedia.org/wiki/Tar_%28computing%29
>
> However, considering that it is August 3rd already, some more progress on
> the rest of the GUI is much-needed, asking for acceptance of the current
> imperfect, but functional, build 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.
>>
>
> But does it also decompress the .tar.gz files? That's a direct test for
> it. If zlib isn't used inside libarchive, it will try to either run gzip
> (and fail) or throw an error right away. I had a couple of such builds when
> I tried to use both with add_subdirectory()
>
> 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
