Menu
▾
▴
liborigin-devel
|
From: Knut F. <Knu...@gm...> - 2010-11-01 17:27:22
|
[ Sorry for not replying properly; I managed to screw up my first subscription attempt and didn't receive the first three mails. ] > +targeta.path = $$INSTALLBASE/lib/liborigin2 [...] > +targeta.files = liborigin2.a 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. 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. Knut |
|
From: Miquel G. <gbm...@gm...> - 2010-11-01 17:55:09
|
2010/11/1 Knut Franke <Knu...@gm...>: > [ Sorry for not replying properly; I managed to screw up my first subscription > attempt and didn't receive the first three mails. ] > >> +targeta.path = $$INSTALLBASE/lib/liborigin2 > [...] >> +targeta.files = liborigin2.a > > 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. Therefore, the following commands qmake liborigin2.pro; make; make clean; make staticlib; make install should compile and install both libraries. > 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. Another possibility would be to keep both (qmake and CMake) building scripts. Miquel |
|
From: Knut F. <Knu...@gm...> - 2010-11-02 07:38:31
|
[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 |
|
From: Miquel G. <gbm...@gm...> - 2010-11-03 12:38:27
|
2010/11/2 Knut Franke <Knu...@gm...>: > 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... That's the only reason. Other platforms may need the "make clean" step. > 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... What I dislike of CMake is: a) There is no easy way of removing the CMake generated files (like "make distclean" does for qmake), other that creating a "build" subdir and start cmake from there. That solution is (almost equivalent) to use a subdir for opj2dat. b) There is no easy way to see what the make command will do. The usual "make -n" command only shows a series of CMake related commands. Maybe in the long run handmade Makefile(s) will be the simplest solution. > If we do that, I'd suggest replacing >> +QT -= core gui > with > +CONFIG -= qt > which removes even more Qt-specific stuff. OK. > > Knut > > ------------------------------------------------------------------------------ > Nokia and AT&T present the 2010 Calling All Innovators-North America contest > Create new apps & games for the Nokia N8 for consumers in U.S. and Canada > $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing > Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store > http://p.sf.net/sfu/nokia-dev2dev > _______________________________________________ > Liborigin-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/liborigin-devel > |
|
From: Knut F. <Knu...@gm...> - 2010-11-03 21:25:10
|
[2010-11-03 13:38] Miquel Garriga <gbm...@gm...>:
> What I dislike of CMake is:
> a) There is no easy way of removing the CMake generated files (like
> "make distclean"
> does for qmake), other that creating a "build" subdir and start cmake
> from there.
Yes, that would be the preferred solution with CMake (for good reasons, I'd say[1]).
> That solution is (almost equivalent) to use a subdir for opj2dat.
Why? Subdirs aren't evil if used with some consideration. I wouldn't even say a subdir for opj2dat would be totally out of the question, although a subdir for a single source
file is a bit suboptimal due to the (mental) overhead it creates. Having a separate directory for output files makes perfect sense to me, also since this keeps the source
directory free from non-source files (and thus easier to understand) at all times.
Besides, if you insist on in-source builds, you can use Git to determine which files were added (e.g. using "git status -s") and possibly even write a small script which removes
them.
> b) There is no easy way to see what the make command will do.
> The usual "make -n" command only shows a series of CMake related
> commands.
Admittedly the "make -n" output with CMake isn't as nice as with qmake, but it shows not *only* CMake-related commands (at least on my system). A small script munging the "make
-n" output a bit may help. Try something like
make -n | awk '/cmake_echo|cmake_progress/ {next} /cmake_link_script/ {getline < $4} //'
> Maybe in the long run handmade Makefile(s) will be the simplest
> solution.
I hope not. Having to maintain separate Makefiles for all sorts of different platforms is annoying and error-prone.
By the way, we already did have this approach in liborigin1 (last commit was dba976c); not suprprisingly, the implemented functionality varied widely between the relatively
complete Linux Makefile (with lots of settings, install and uninstall targets) and the Solaris one (which only supported rudimentary opj2dat and clean targets). With a cross-
platform build tool, all platforms get the same set of features. Not to mention none gets outdated, e.g. if the set of source files changes.
Just to be clear on this point, I don't think CMake is anywhere near perfect (although I have different gripes with it than you). I just think it's the least undesirable of the
available options.
Knut
[1] http://www.cmake.org/Wiki/CMake_FAQ#CMake_does_not_generate_a_.22make_distclean.22_target._Why.3F
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X