I forgot to reply to Matthew's mail.

All is well and the benchmark looks great.  It's really coming along
> nicely.  Great work Namik!


Thanks. It would've been a lot better if the build system hadn't caused so
much troubles.

 blas, vector and copy benchmarks ran great.  Sparse fails though...


That's because the matrix data files are missing. Try copying the testdata
folder from project root to the folder where the executable is located,
that should do it. I haven't automated this as these files are to be
replaced with an on-the-fly generation procedure in the near future.

And thanks for your feedback! I'm glad we can test the project on multiple
platforms to make it as robust as possible.

Regards, Namik


On Sun, Aug 3, 2014 at 5:29 PM, Namik Karovic <namik.karo...@gmail.com>
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?
>
>
>
>> 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
ViennaCL-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/viennacl-devel

Reply via email to