Re: [Liborigin-devel] [PATCH 1/3] Add install target and remove linking against Qt libs

[Knut F. <Knu...@gm...>]

[2010-11-01 18:55] Miquel Garriga <gbm...@gm...>:
> 2010/11/1 Knut Franke <Knu...@gm...>:
[...]
> > As far as I can see, qmake can build either a static or a dynamic
> > library, but not both at the same time. Adding just this installation
> > target will install whatever liborigin2.a happens to be lieing around
> > from the last time qmake;make was run with CONFIG+=staticlib enabled,
> > which is not a good idea IMHO.
> 
> Not exactly, if you follow the instructions in README. The command
> "qmake liborigin2.pro"
> (i.e. without  CONFIG+=staticlib enabled) produces a Makefile with both
> a (default) dynamic library target and also a static library target.

Looks like I should have RTFM ;-).

> Therefore, the following commands
> qmake liborigin2.pro; make; make clean; make staticlib; make install
> should compile and install both libraries.

That's not exactly what the readme says. Is there a reason for the "make 
clean" step? At least on Linux/GCC, it doesn't seem to make a difference 
whether the files are compiled with "make" or "make staticlib"; but that might 
be different on other platforms...

> > Instead of trying to work around the various shortcomings of qmake, I'd
> > suggest resurrecting CMakeLists.txt from commit f19437 (with a suitably
> > updated VERSION). This is also a much smaller dependency than Qt
> > (assuming someone wants to use liborigin in a non-Qt context), and
> > LabPlot2 / future SciDAVis will most likely be using CMake anyway.
> 
> I would prefer to wait for that change until at least LabPlot2 or
> SciDAVis do change
> to CMake. After all, the best use of liborigin2 capabilities is still
> done with qmake driven applications.

I don't see a big problem with depending on CMake (whether LabPlot/SciDAVis 
depend on it or not), given that it's the build system of choice for KDE4 and 
thus available virtually everywhere. Also, while my above point was invalid, 
there's still the issue with the somewhat unintuitive build process for 
opj2dat. Maybe that patch could include at least a suitable note in the 
readme...

> Another possibility would be to
> keep both (qmake and CMake) building
> scripts.

I suspect that would add more confusion than it's worth, given that the point 
of using CMake is to simplify the build process. I'd rather stick with qmake 
(for now) than trying to maintain both scripts.

If we do that, I'd suggest replacing
> +QT -= core gui
with
+CONFIG -= qt
which removes even more Qt-specific stuff.

Knut