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 happ
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 rewr
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 ori
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)
ADD_CUSTO
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
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)
includ
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
On 04.03.12 13:36:57, Kevin Nathan wrote:
> On Sun, 04 Mar 2012 21:30:21 +0100
> Rolf Eike Beer wrote:
>
> >Remove it altogether. Link_directories() is never needed when linking
> >to a target built in the same CMake project. You must only make sure
> >that the library is built before the executa
Am Sonntag, 4. März 2012, 13:36:57 schrieb Kevin Nathan:
> On Sun, 04 Mar 2012 21:30:21 +0100
>
> Rolf Eike Beer wrote:
> >Remove it altogether. Link_directories() is never needed when linking
> >to a target built in the same CMake project. You must only make sure
> >that the library is built befo
On Sun, 04 Mar 2012 21:30:21 +0100
Rolf Eike Beer wrote:
>Remove it altogether. Link_directories() is never needed when linking
>to a target built in the same CMake project. You must only make sure
>that the library is built before the executables.
>
I need it, though, for additional libs (KDE,
Am Sonntag, 4. März 2012, 12:55:40 schrieb Kevin Nathan:
> On Sun, 04 Mar 2012 19:50:50 +0100
>
> Rolf Eike Beer 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 ./
On Sun, 04 Mar 2012 19:50:50 +0100
Rolf Eike Beer 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 look for
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 ab
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 autoto
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 pr
@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.
Thank
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 build
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
18 matches
Mail list logo
