How to add qt script tools support in cmake?
dmitry chernov
project(context2d)
FIND_PACKAGE(Qt4 REQUIRED)
SET( QT_USE_QTSCRIPT TRUE )
add_definitions(-DQT_NO_SCRIPTTOOLS)
SET(context2d_SRCS
main.cpp
context2d.cpp
domimage.cpp
environment.cpp
qcontext2dcanvas.cpp
window.cpp
)
SET(context2d_HEADERS
context2d.h
domimage.h
environment.h
qcontext2dcanvas.h
window.h
)
QT4_WRAP_CPP( context2d_HEADERS_MOC ${context2d_HEADERS} )
SET(context2d_RESOURCES context2d.qrc)
QT4_ADD_RESOURCES(context2d_RESOURCES_RCC ${context2d_RESOURCES})
INCLUDE(${QT_USE_FILE})
ADD_DEFINITIONS(${QT_DEFINITIONS})
ADD_EXECUTABLE(context2d ${context2d_SRCS}
${context2d_RESOURCES_RCC}
${context2d_HEADERS_MOC} )
TARGET_LINK_LIBRARIES(context2d ${QT_LIBRARIES})
Filip Brcic
On уторак, 21. јун 2011. 8.35.41 dmitry chernov wrote:
> Do anybody have proper CMakeLists.txt to build qt's example Context2D? I
> had to add -DQT_NO_SCRIPTTOOLS. When I build this example with .pro file
> it builds ok. So I want to know how to add qt script tools support in
> cmake. Now I use following CMakeLists.txt :
I saw you didn't specify the modules in the find_package directive:
> FIND_PACKAGE(Qt4 REQUIRED)
Try using it like this:
find_package(Qt4 COMPONENTS QtCore QtGui QtScript REQUIRED)
Then you won't have to set qt_use_script to true.
Also, if I were you, I'd add include(${QT_USE_FILE}) right after
find_package(Qt4), as that's how it was intended to be used, IMHO.
Please try that and see if you still need to set -DQT_NO_SCRIPTTOOLS.
Best regards,
Filip
--
Filip Brcic <br...@gna.org>
WWWeb: http://brcha.com
Jabber : br...@kdetalk.net
GPG 0x2537C379
Fingerprint: 287D 5F24 50AA A36C 977F AC9A F1FD C7EB 2537 C379
Filip Brcic
> had to add -DQT_NO_SCRIPTTOOLS. When I build this example with .pro file
> it builds ok. So I want to know how to add qt script tools support in
> cmake
Here's the CMakeLists.txt that works:
project(context2d)
find_package(Qt4 COMPONENTS QtCore QtGui QtScript QtScriptTools REQUIRED)
include(${QT_USE_FILE})
SET(context2d_SRCS
main.cpp
context2d.cpp
domimage.cpp
environment.cpp
qcontext2dcanvas.cpp
window.cpp
)
SET(context2d_HEADERS
context2d.h
domimage.h
environment.h
qcontext2dcanvas.h
window.h
)
QT4_WRAP_CPP( context2d_HEADERS_MOC ${context2d_HEADERS} )
SET(context2d_RESOURCES context2d.qrc)
QT4_ADD_RESOURCES(context2d_RESOURCES_RCC ${context2d_RESOURCES})
ADD_DEFINITIONS(${QT_DEFINITIONS})
ADD_EXECUTABLE(context2d ${context2d_SRCS}
${context2d_RESOURCES_RCC}
${context2d_HEADERS_MOC} )
TARGET_LINK_LIBRARIES(context2d ${QT_LIBRARIES})
It seams this example needs both QtScript and QtScriptTools (as is written in
the .pro file).
dmitry chernov
But it still says that : error: QScriptEngineDebugger: No such file or directory.
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
dmitry chernov
include_directories(file /usr/include/QtScriptTools) and changing this:
TARGET_LINK_LIBRARIES( context2d ${QT_LIBRARIES} /usr/lib/libQtScriptTools.so )
So0mething is broken or smth. I've got rather old system Fedora11...
Luis Gustavo Spern Barreto
Add these variables to the include_directories() and target_link_libraries():
include_directories(${QT_....} ${QT_QTSCRIPTTOOLS_INCLUDE_DIR})
target_link_libraries(${QT_....} ${QT_QTSCRIPTTOOLS_LIBRARY})
If you need Qt script:
${QT_QTSCRIPT_INCLUDE_DIR}
${QT_QTSCRIPT_LIBRARY}
Luis Gustavo Spern Barreto,
http://www.gustavobarreto.net
+55 53 9144.4318
2011/6/24 dmitry chernov <diman4ik...@gmail.com>:
dmitry chernov
Joachim Langenbach
since we need the qca-ossl-plugin within one of our project, I've thought
about improving the cmake support. Starting with it, I've noticed, that the
plugin consists of only one really big file. So I thought it is much better to
split them up into several files containing only one class. But before starting
this big effort, I want to ask, if someone other than me is interested in it
and also thought it would be nice to have it splitted up.
Regards,
Joachim
Brad Hards
> Good morning all,
>
> since we need the qca-ossl-plugin within one of our project, I've thought
> about improving the cmake support.
Note that cmake is considered a secondary build system for QCA (hence the .qc
/ .qcm / .pro files).
> Starting with it, I've noticed, that the
> plugin consists of only one really big file. So I thought it is much better
> to split them up into several files containing only one class.
What do you want to achieve by splitting it up?
Brad
Joachim Langenbach
> > since we need the qca-ossl-plugin within one of our project, I've
> > thought
> > about improving the cmake support.
>
> What problems are you seeing?
>
> Note that cmake is considered a secondary build system for QCA (hence the
> .qc / .qcm / .pro files).
Ok, but the actual one supported doesn't allow easy builds on windows. So I
decided to take the cmake script which they provide (more or less nothing)
and extend it (I know KDE has also one, but KDE does not have the newest
version in repository and has another structure of the sources related to
qca and the plugins).
Yes, I've worried that they do not really want to support cmake. But
compiling it on windows is a big horror and I've seen, that nearly any
linux distribution applies many patches to their sources. So tonight I
thought, it might be easier to create a new repository, import their
sources, apply the patches, used by every distribution and merge the
changes from the original source back into the new repository if they
appear from time to time. This may be much more efficient than create
patches independent at every distribution. Also windows and mac users (and
kde) doesn't profit from the process right now.
> > Starting with it, I've noticed, that the
> > plugin consists of only one really big file. So I thought it is much
> > better to split them up into several files containing only one class.
> What do you want to achieve by splitting it up?
During the compile and linking process I get many errors and it is really
difficult to get the overview, if all appears at the same file. So a more
structured source, should made the debugging during the compile run much
more easy. Also create patches should be easier, since it is easier to
understand the logic behind the source code.
Regards,
Joachim
P.s.: Brad, thanks, I want to post it to the list! ;-)
Brad Hards
> Ok, but the actual one supported doesn't allow easy builds on windows.
dated though). Checking for support on the delta mailing list may be useful.
> So I
> decided to take the cmake script which they provide (more or less nothing)
> and extend it (I know KDE has also one, but KDE does not have the newest
> version in repository and has another structure of the sources related to
> qca and the plugins).
I'm not following you here. Can you explain further?
> Yes, I've worried that they do not really want to support cmake.
The background to the cmake support is that it was added to kdesupport, and
QCA was part of that, so it was an easy way for KDE developers to build QCA.
> But
> compiling it on windows is a big horror and I've seen, that nearly any
> linux distribution applies many patches to their sources.
Many? I had a quick look at Debian (which is usually the worst, and there is
only a few (mostly for more recent OpenSSL versions). Do you have links for
these patches.
> So tonight I
> thought, it might be easier to create a new repository, import their
> sources, apply the patches, used by every distribution and merge the
> changes from the original source back into the new repository if they
> appear from time to time. This may be much more efficient than create
> patches independent at every distribution. Also windows and mac users (and
> kde) doesn't profit from the process right now.
Sounds like it should be done in the repo. Why not?
> During the compile and linking process I get many errors and it is really
> difficult to get the overview, if all appears at the same file. So a more
> structured source, should made the debugging during the compile run much
> more easy. Also create patches should be easier, since it is easier to
> understand the logic behind the source code.
I think it would be harder, more duplicated headers etc. The whole structure
of QCA is simple: its a Bridge. Each plugin has factory that creates objects
of the right kind. There are a lot of capabilities in the ossl plugin so its
long, but the hard part of that plugin in the hideous OpenSSL API that it
uses.
I think this is a bad idea to do this kind of change- too much code churn
which could break things, not enough unit test coverage, and not enough benefit
to justify the work.
Brad
Joachim Langenbach
> > So I
> > decided to take the cmake script which they provide (more or less
> > nothing) and extend it (I know KDE has also one, but KDE does not have
> > the newest version in repository and has another structure of the
> > sources related to qca and the plugins).
>
> I'm not following you here. Can you explain further?
Yes. If you download the sources from the delta page, you get one source
structure for qca and another one for qca-ossl. So I had the oppinion, that
the used qca-ossl plugin is another one as in the kde repository. But today I
realized, that QCA is hosted only at kde (at least the delta website implies
that). So if this (kde repo is the "root" repo) is correct now, why does delta
remove the cmake support at their tarballs and why do they split the structure
into qca and qca-ossl plugin (or any other plugin)?
>
> > Yes, I've worried that they do not really want to support cmake.
>
> The background to the cmake support is that it was added to kdesupport, and
> QCA was part of that, so it was an easy way for KDE developers to build QCA.
>
> > But
> > compiling it on windows is a big horror and I've seen, that nearly any
> > linux distribution applies many patches to their sources.
>
> Many? I had a quick look at Debian (which is usually the worst, and there is
> only a few (mostly for more recent OpenSSL versions). Do you have links for
> these patches.
No, I've do not counted them. During my google searches to build errors, if
found a lot Bugfixes, so I only assumed that their are also many patches. ;-)
But espacially those patches to support more OpenSSL verions, are very
important for windows users, because they have no repository where a
distribution manages the dependencies. They must download one of the OpenSSL
builds for windows and must live with one of them. That's the problem for me
right now, because Debian seems to have such a patch and it was my problem the
last time I build QCA with QCA-OSSL on windows last year. I'm trying to apply
the patch from debian tomorrow and report, if it helps.
>
> > So tonight I
> > thought, it might be easier to create a new repository, import their
> > sources, apply the patches, used by every distribution and merge the
> > changes from the original source back into the new repository if they
> > appear from time to time. This may be much more efficient than create
> > patches independent at every distribution. Also windows and mac users
> > (and kde) doesn't profit from the process right now.
>
> Sounds like it should be done in the repo. Why not?
Espacially if the kde repo is the main repository (see above).
>
> > During the compile and linking process I get many errors and it is
> > really
> > difficult to get the overview, if all appears at the same file. So a
> > more
> > structured source, should made the debugging during the compile run much
> > more easy. Also create patches should be easier, since it is easier to
> > understand the logic behind the source code.
>
> I think it would be harder, more duplicated headers etc. The whole structure
> of QCA is simple: its a Bridge. Each plugin has factory that creates
> objects of the right kind. There are a lot of capabilities in the ossl
> plugin so its long, but the hard part of that plugin in the hideous OpenSSL
> API that it uses.
>
> I think this is a bad idea to do this kind of change- too much code churn
> which could break things, not enough unit test coverage, and not enough
> benefit to justify the work.
Thanks for your oppinion, than I leave the structure untouched.
Regards,
Joachim
Joachim Langenbach
> > > But
> > > compiling it on windows is a big horror and I've seen, that nearly
> > > any
> > > linux distribution applies many patches to their sources.
> >
> > Many? I had a quick look at Debian (which is usually the worst, and
> > there is only a few (mostly for more recent OpenSSL versions). Do you
> > have links for these patches.
>
> No, I've do not counted them. During my google searches to build errors, if
> found a lot Bugfixes, so I only assumed that their are also many patches.
> ;-) But espacially those patches to support more OpenSSL verions, are very
> important for windows users, because they have no repository where a
> distribution manages the dependencies. They must download one of the
> OpenSSL builds for windows and must live with one of them. That's the
> problem for me right now, because Debian seems to have such a patch and it
> was my problem the last time I build QCA with QCA-OSSL on windows last
> year. I'm trying to apply the patch from debian tomorrow and report, if it
> helps.
>
Yes, the patch from this bug http://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=622017 allows to compile the sources within the actual
tarball from kde windows of qca. I have used OpenSSL 1.0.0d and Qt 4.7.3. Also
it does not compile on windows x64, but thats ok so far.
So may be you want to put this patch in your repo?
Regards,
Joachim