Hi,

 > As far as I know, Qt offers three licenses:
>
> 1. Commercial - both static & dynamic, both closed & open source, may
> modify Qt source code as you please without publishing changes, not
> required to say "This software uses Qt"
> 2. GPL - both static & dynamic, open source ONLY (so no issues there),
> must publish all Qt source code modifications, required to say "This
> software uses Qt"
> 3. LGPL - dynamic only, both closed & open source, cannot use modified
> Qt dll files, required to say "This software uses Qt"
>
> I've done quite a lot of research on the subject of Qt licensing and
> that's how I interpret it.

Okay, then we're good to go with both.


>     Well, if the static link works, why should we bother with a dynamic
>     link? Note that QMake fails on Linux because there is no precompiled
>     shared library in the repository, so the -llibarchive is only a
>     shortcut and does not tell the full story.
>
> Isn't dynamic building a lot faster than static? I'd rather spend time
> maintaining a dynamic build system than waiting a couple of minutes to
> compile the smallest modification.

No, this is more a matter of memory optimization for the OS rather than 
about build times. For the build it really does not matter whether the 
functionality resides in libarchive.{dll/so} or libarchive.{o/lib}. We 
are not changing any parts of libarchive or zlib, so they will only be 
build once. It just a matter of what the linker needs to merge into the 
final executable and what will be loaded on invocation of the 
executable. Static links can result in faster program launches at this 
point.


> And now I'm beginning to think that our QMake build is obsolete. If
> we're going to depend on CMake to generate Zlib and Libarchive library
> objects, then we might as well switch to CMake entirely. Is there a
> point in having a QMake build that depends on CMake?

If we need to have QMake depend on CMake directly, there's no point in 
maintaining it. However, I think we can provide instructions for users 
to build libarchive and zlib themselves through CMake, and use a 
predefined QMake environment to use this prebuild targets.


> I have to say I like QMake more than CMake, and would like to see it
> stay as an optional build system. Perhaps I could do the same thing I
> did with OpenCL in QMake: make a CMakeLists.txt in external/ that could
> be used to generate zlib and libarchive binaries. Specify in QMake to
> use these CMake-generated binaries, and make a fallback to using
> user-specified hard-coded locations. Is that complicating things too much?

It's a matter of who is going to maintain it. If you're taking care of 
QMake, I'm fine. Frankly, I have no ambitions on maintaining a QMake 
build myself, because it cannot get the whole job done (i.e. compiling 
libarchive and zlib as needed outside QMake is way too complicated).



>     As far as I can tell, we only need to dynamically link with Qt,
>     don't we?
>
>
>   If we are to generate a single executable then we need to statically
> link with Qt.
>
> And let me get this straight: you were planning to dynamically link
> against Qt, and statically against all other libraries? How does that
> even work? I always thought it was either full dynamic or full static.
> That or some heavy compiler configuring to allow both linking types.

This is not at all unusual. One can mix and match dynamic and static 
libraries for a final executable as needed.



>     Which problems did you run into? I got everything to compile on a
>     fairly virgin Windows 7 yesterday, so my setup shouldn't be that
>     different from yours.
>
>
> Dynamic linking: crashes on start without any feedback.

I always got a message box telling me that a certain library cannot be 
found. Did you run the executable through the terminal, or by 
double-clicking? In worst case, you can always run in a debugger to find 
out more about the reason for a crash.


> Static linking: didn't compile Qt statically yet.

My Qt 5.3 installation comes with prebuilt static libraries for Visual 
Studio 2012. There are articles on the web on how to do the same with 
MinGW, but since we only need the static version for deploying the 
release, it's probably sufficient to use these prebuilt libraries.

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

Reply via email to