On 03/04/2012 01:06 AM, Ajay Panyala wrote:
Please provide a minimal but complete example for this issue.
Please find it in the following link
http://pastie.org/private/pd13u33s9xpfihf2dbzc1q
The following project is a boiled-down version of yours but doesn't
need any programs except for
Hello,
thanks for the responses. The problem I have is, that we have more than one
application in the directory. So if I put an CMakeLists.txt in the Src
directory I do not have the choice (only by options). I would prefer a solution
where I change into the application directory I want to
@Michael: This was a copy/paste failure
@Thiago: QT_STATICPLUGIN does the trick
Another mistake from me was to use a different name for Q_IMPORT_PLUGIN and for
Q_EXPORT_PLUGIN2.
One more hint, if someone would make a static plugin is to use the
QPluginLoader::staticInstances() function.
I have inherited maintenance (and updating) on a program that was
spread over three different source root trees and I have incorporated
them into one source tree. Since I am fairly new to CMake (and really
loving it compared to autotools), I am probably missing something
obvious, but here is my
Am Sonntag, 4. März 2012, 11:28:47 schrieb Kevin Nathan:
I have inherited maintenance (and updating) on a program that was
spread over three different source root trees and I have incorporated
them into one source tree. Since I am fairly new to CMake (and really
loving it compared to
The following project is a boiled-down version of yours but doesn't
need any programs except for CMake - that's what I actually meant
with minimal but complete as I don't have the org.antlr.Tool
Java program:
I am sorry. I was mainly trying to cleanup the big CMakeLists file
I had and removed
On Sun, 04 Mar 2012 19:50:50 +0100
Rolf Eike Beer e...@sf-mail.de wrote:
Am Sonntag, 4. März 2012, 11:28:47 schrieb Kevin Nathan:
...doing an out-of-source build, my 'old-common' library (which will
eventually be phased out) ends up in ./build/old-common but the
source for prog2 and prog3 all
Am Sonntag, 4. März 2012, 12:55:40 schrieb Kevin Nathan:
On Sun, 04 Mar 2012 19:50:50 +0100
Rolf Eike Beer e...@sf-mail.de wrote:
Am Sonntag, 4. März 2012, 11:28:47 schrieb Kevin Nathan:
...doing an out-of-source build, my 'old-common' library (which will
eventually be phased out) ends up
On 03/04/2012 08:02 PM, Ajay Panyala wrote:
The following project is a boiled-down version of yours but doesn't
need any programs except for CMake - that's what I actually meant
with minimal but complete as I don't have the org.antlr.Tool
Java program:
I am sorry. I was mainly trying to
Michael Hertling wrote:
Suppose the Qt folks decide that Qt5's core module doesn't need to
be explicitly requested because it is prerequisite for everything
else.
Just to disseminate information here, this is already the case.
You can currently do this:
find_package(Qt5Declarative)
Rolf Eike Beer wrote:
Michael Hertling wrote:
My main conclusion from the above-noted mess among CMake's current
component-aware find modules is that we urgently need a convention
how such modules and config files are intended to work. Hopefully,
we can take a step forward; Qt5's advent is
I use cmake version 2.8.3.
If I use CMakeLists from your previous reply, it avoids overwriting files
when X=0.
I have attached the output of your script.
It works for my CMakeLists as well now. What I did now is
if(${GrammarSource}/test.g IS_NEWER_THAN ${PROJECT_BINARY_DIR}/test.g)
Michael Hertling wrote:
* Currently there is no Qt5Config.cmake.
Such a thing could probably exist and use the FIND_COMPONENTS to find
what was requested. [...]
Hi there,
Thank you for your insights on this issue. Do you have any other insights
into other issues I raised in the original
On 03/05/2012 01:59 AM, Ajay Panyala wrote:
I use cmake version 2.8.3.
If I use CMakeLists from your previous reply, it avoids overwriting files
when X=0.
I have attached the output of your script.
Actually, this is exactly what I was talking about: The second make
X=0 invocation rewrites
So, my question again: What exactly does not work?
I.e., does cmake -E copy_if_different
- copy a file although the destination exists
and has the same content as the source, or
Sorry for the confusion.
I thought something like the above mentioned happened, but in reality
nothing like it
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=13015
==
Reported By:Andrew Aladjev
Assigned To:
Brad King brad.king@... writes:
That's a good start. However I do not think the logic plays well
with BUILD_WITH_INSTALL_RPATH as currently written. If that is
set then the build tree should end up with the install-tree rpath
which should be empty if SKIP_INSTALL_RPATH is on. Therefore
Stephen Kelly steveire@... writes:
Brad King wrote:
The implementation is not what I had in mind when I said implies
the platform-specific property. This should be its own property
that one can set/get normally with no special C++-implemented
mapping to the other two properties.
Stephen Kelly steveire@... writes:
Any idea what would cause that? It must be one of these:
http://open.cdash.org/viewUpdate.php?buildid=2016288
Note that the GenerateExportHeader_MinorFix makes the problem go away, but
doesn't explain why the problem occured in the first place.
I
Alexander Neundorf wrote:
The question whether the standard-conforming name is FOO_INCLUDE_DIRS or
Foo_INCLUDE_DIRS, i.e. ExactCase or UPPERCASE, is not decided.
readme.txt is ambiguous in this point, since it uses as example
FindXXX.cmake, i.e. an UPPERCASE package name.
There was a thread
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via d8adfc2f12b866396f56b2fae89987dafe370734 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via 17a099dd1379051eaa6c0a66a5ee6df5aea49089 (commit)
from
22 matches
Mail list logo