[cmake-developers] [CMake 0013015]: cpack deb generator components specify output names
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=13015
==
Reported By:Andrew Aladjev
Assigned To:
==
Project:CMake
Issue ID: 13015
Category: CPack
Reproducibility:always
Severity: feature
Priority: normal
Status: new
==
Date Submitted: 2012-03-04 04:47 EST
Last Modified: 2012-03-04 04:47 EST
==
Summary:cpack deb generator components specify output names
Description:
http://stackoverflow.com/questions/9538642/cpack-deb-generator-components-output-names
Steps to Reproduce:
install (TARGETS ${PROJECT_NAME}_shared DESTINATION ${CMAKE_INSTALL_PREFIX}/lib
COMPONENT runtime)
install (TARGETS ${PROJECT_NAME}_static DESTINATION
${CMAKE_INSTALL_PREFIX}/lib
COMPONENT development)
install (FILES ${INCLUDES} DESTINATION ${CMAKE_INSTALL_PREFIX}/include
COMPONENT development)
...
set (CPACK_PACKAGE_FILE_NAME
lib${CPACK_PACKAGE_NAME}_${CPACK_PACKAGE_VERSION}_${CPACK_DEBIAN_PACKAGE_ARCHITECTURE})
I have 2 deb packages as a result:
libmpreal_0.1.1-1_amd64-development.deb
libmpreal_0.1.1-1_amd64-runtime.deb
But I want to have for debian standarts another names:
libmpreal-dev_0.1.1-1_amd64.deb
libmpreal_0.1.1-1_amd64.deb
Additional Information:
Now I am reading [this][1] at the method **cmCPackDebGenerator::PackageOnePack**
here is a code:
outputFileName(
std::string(this-GetOption(CPACK_PACKAGE_FILE_NAME))
+ - + packageName + this-GetOutputExtension()
);
Does this mean that I cant specify a name for my packages?! I would like to make
a mistake..
[1]:
https://github.com/Kitware/CMake/blob/master/Source/CPack/cmCPackDebGenerator.cxx
==
Issue History
Date ModifiedUsername FieldChange
==
2012-03-04 04:47 Andrew Aladjev New Issue
==
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Modifying RPATH feature to run tests uninstalled
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 the relink/chrpath paths should not need to return true always when SKIP_INSTALL_RPATH is on. Sorry this took so long. I have updated the branch (It is now e96c16ae23885be2e66d67291344369585ebfece) -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Making GUI applications by default
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. The generators should look for this property first and only if not set look for the platform- specific property. If either is set the effect is the same. I see. That's a bit more painful. That will mean touching all generators, and I don't have the easy visual studio or mac access to implement or test them. I happened to read a little bit about CPack recently http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#Overview The recommendation is to not use MACOSX_BUNDLE when using cpack, so I thought maybe that makes it different enough to WIN32_EXECUTABLE that they should be different CMAKE_ properties. set(CMAKE_WIN32_EXECUTABLE ON) set(CMAKE_MACOSX_BUNDLE ON) That would also mean that I can actually submit the patch. I'm not so keen on having to change every generator instead. Actually I think the existing patch is better than touching every generator anyway (that's at least in part why there is an abstraction). Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] GenerateExportHeader gcc version test failure?
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 noticed that the branch was merged. Was there no interest in finding out why the determination of the GCC version suddenly failed? -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Convention driven CMAKE_USE_PACKAGE macro
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 here in August 2010: http://www.mail-archive.com/cmake-developers- wchdc6uyxvpytjvyw6y...@public.gmane.org/msg00128.html and results for what casing is used in cmake and in kdelibs here: http://www.mail-archive.com/cmake-developers- wchdc6uyxvpytjvyw6y...@public.gmane.org/msg00157.html The concensus seems to be that ExactCase is used. It also makes a lot more sense to me for several reasons but that's off topic for this thread. It's unfortunate that the ambiguity didn't get resolved in general. For Qt5 and config files I think exact case makes even more sense because using config files sets ExactCase_FOUND to true if found. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] avoid rebuilding targets depending on generated source files
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 CMake - that's what I actually meant
with minimal but complete as I don't have the org.antlr.Tool
Java program:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(P NONE)
SET(CMAKE_VERBOSE_MAKEFILE ON)
SET(GrammarSource ${PROJECT_BINARY_DIR}/src)
FILE(MAKE_DIRECTORY ${PROJECT_BINARY_DIR}/src)
ADD_CUSTOM_TARGET(GrammarBuild ALL
COMMAND ${CMAKE_COMMAND} -E echo \${X}
${GrammarSource}/testLexer.h
COMMAND ${CMAKE_COMMAND} -E echo \${X}
${GrammarSource}/testLexer.c
COMMAND ${CMAKE_COMMAND} -E echo \${X}
${GrammarSource}/testParser.h
COMMAND ${CMAKE_COMMAND} -E echo \${X}
${GrammarSource}/testParser.c
COMMAND ${CMAKE_COMMAND} -E echo \${X}
${PROJECT_BINARY_DIR}/test.tokens
)
ADD_CUSTOM_COMMAND(TARGET GrammarBuild POST_BUILD
COMMAND ${CMAKE_COMMAND} -E copy_if_different
${GrammarSource}/testLexer.h
${PROJECT_BINARY_DIR}/parser/testLexer.h
COMMAND ${CMAKE_COMMAND} -E copy_if_different
${GrammarSource}/testLexer.c
${PROJECT_BINARY_DIR}/parser/testLexer.c
COMMAND ${CMAKE_COMMAND} -E copy_if_different
${GrammarSource}/testParser.h
${PROJECT_BINARY_DIR}/parser/testParser.h
COMMAND ${CMAKE_COMMAND} -E copy_if_different
${GrammarSource}/testParser.c
${PROJECT_BINARY_DIR}/parser/testParser.c
COMMAND ${CMAKE_COMMAND} -E copy_if_different
${PROJECT_BINARY_DIR}/test.tokens
${PROJECT_BINARY_DIR}/parser/test.tokens
)
After configuration, you can run the target by make X=0 and check the
timestamps by ls -l --full-time test.tokens parser src. Issuing make
X=0 again reveals that the copied files aren't rewritten as it happens
after make X=1. Thus, AFAICS, everything works as expected. Could you
check if the above-noted example also works on your system?
What exactly does not work with your example? You wrote:
I have 4 cmake -E copy_if_different commands, one for each file.
Only the last file is not copied (if similar). [...]
Does this mean that the last file out of four - in fact, your example
handles five files - is not copied *although* the source file and the
destination file are different, i.e. similar but not equal?
You wrote further:
[...] The others are copied
even if they are the same.
I verfied that they are the same with a diff.
Does this mean that source files are copied *although* they are equal
to their respective destination file? How do you determine that they
have been copied? Do you check the timestamps? With --full-time?
Regards,
Michael
PS: Does org.antlr.Tool write to the source tree? If so: Don't do that.
On Sat, Mar 3, 2012 at 3:54 PM, Michael Hertling mhertl...@online.dewrote:
On 03/04/2012 12:14 AM, Ajay Panyala wrote:
No, it wouldn't; check it out:
% touch a
% rm -f b
% ls b
ls: cannot access b: No such file or directory
% cmake -E copy_if_different a b
% ls b
b
% cksum a b
4294967295 0 a
4294967295 0 b
It works with one file, but I have 4 files that are generated.
I have 4 cmake -E copy_if_different commands, one for each file.
Only the last file is not copied (if similar). The others are copied
even if they are the same.
I verfied that they are the same with a diff.
Any idea what might be happening here ?
Please provide a minimal but complete example for this issue.
Regards,
Michael
On Sat, Mar 3, 2012 at 2:47 PM, Michael Hertling mhertl...@online.de
wrote:
On 03/03/2012 10:36 PM, Ajay Panyala wrote:
Try cmake -E copy_if_different ...
cmake -E copy_if_different build/test1.c build/tests/test1.c
That would work when make is run atleast once.
When running make for the 1st time test1.c was never
copied to build/tests before. So I would be comparing a file with
another non-existant file and that would result in an error halting
the make process.
No, it wouldn't; check it out:
% touch a
% rm -f b
% ls b
ls: cannot access b: No such file or directory
% cmake -E copy_if_different a b
% ls b
b
% cksum a b
4294967295 0 a
4294967295 0 b
Regards,
Michael
On Sat, Mar 3, 2012 at 1:20 PM, Hendrik Sattler
p...@hendrik-sattler.de
wrote:
Am Samstag, 3. März 2012, 21:41:49 schrieb Ajay Panyala:
I have a custom target which runs a command to generate
a C source file say test1.c
ADD_CUSTOM_TARGET(TestGen ALL
COMMAND genExec ${PROJECT_SOURCE_DIR}/Main.java
DEPENDS ${PROJECT_SOURCE_DIR}/Main.java
)
And I have a custom command that moves the generated *test1.c *
to a new directory inside the build directory.
ADD_CUSTOM_COMMAND(
TARGET TestGen
POST_BUILD
COMMAND mv
ARGS ${PROJECT_BINARY_DIR}/test1.c ${PROJECT_BINARY_DIR}/tests/
)
Each time I run make, the custom
Re: [CMake] Question regarding source tree structure and how to find libraries easily within that structure
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 and create workspace etc. from there. The created workspace should then also build all necessary libraries for the application. Any ideas on this? Kind regards, Andreas -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Problems with CMake and static Qt plugins
@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.
Thanks to all
Best Regards
NoRulez
Am 04.03.2012 um 00:07 schrieb Michael Hertling mhertl...@online.de:
On 03/02/2012 02:48 PM, NoRulez wrote:
Hello,
I use Qt 4.8.0 from the QtSDK and Iwant to generate a static qt plugin.
In my main.cpp I have the following:
#includeQApplication
#includeQtPlugin
Q_IMPORT_PLUGIN(Local)
intmain(intargc,char*argv[]){
QApplicationapp(argc,argv);
.
.
.
return app.exec();
}
The corresponding CMakeLists.txt for the LocalPlugin looks like the
following:
SET(LOCALPLUGIN_HEADERS
LocalPlugin.h
)
SET(LOCALPLUGIN_SOURCES
LocalPlugin.cpp
)
SET(QT_USE_QTGUITRUE)
SET(QT_USE_QTPLUGINTRUE)
QT4_AUTOMOC(${LOCALPLUGIN_SOURCES})
QT4_WRAP_CPP(LOCALPLUGIN_MOC${LOCALPLUGIN_HEADERS})
ADD_LIBRARY(Local STATIC ${LOCALPLUGIN_HEADERS} ${LOCALPLUGIN_SOURCES}
${LOCALPLUGIN_MOC})
TARGET_LINK_LIBRARIES(Local ${QT_LIBRARIES})
The corresponding CMakeLists.txt for the main app looks like the following:
SET(QT_USE_QTMAINTRUE)
SET(QT_USE_QTGUI TRUE)
ADD_EXECUTABLE(MyApp WIN32 ${APP_SOURCES} ${APP_RCC} MyApp.rc)
TARGET_LINK_LIBRARIES(MyAppLocal ${QT_LIBRARIES})
When I compile it I get the following error:
In function `StaticLocalPluginInstance': undefined reference to
`qt_plugin_instance_Local()'
Please, could anybody help me to get it working?
Did you INCLUDE(${QT_USE_FILE}) in the correct place, i.e. after
setting the QT_USE_QT* variables? QT_LIBRARIES is populated in
that file.
Moreover, the lines
SET(QT_USE_QTGUITRUE)
SET(QT_USE_QTMAINTRUE)
SET(QT_USE_QTPLUGINTRUE)
QT4_WRAP_CPP(LOCALPLUGIN_MOC${LOCALPLUGIN_HEADERS})
are obviously missing blanks - just typos in your report?
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Generated library location
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 problem: 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 it in ./old-common. Is there a command I can use to cause CMake to actually build the lib in ./old-common (or move it there) or do I need to write a command to copy it after generation? Or should I just use an in-source build (which I would prefer not to do)? Or is there another obvious solution which I cannot see? I have been looking through this mailing list and combing through the CMake docs but I just cannot see an easy solution... . |-build |---old-common |---src |-prog2 |-dao |-prog3 |-reports |-types |-lib (not yet used) |-old-common (old lib source) |-src (contains prog1 source) |---prog2 (source) |---dao (lib source) |---prog3 (source) |---reports (lib source) |---types (lib source) -- Kevin Nathan (Arizona, USA) http://www.project54.com Open standards. Open source. Open minds. The command line is the front line. Linux 2.6.37.6-0.11-desktop 11:27am up 18 days 20:45, 13 users, load average: 0.10, 0.22, 0.23 -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Generated library location
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 autotools), I am probably missing something obvious, but here is my problem: 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 it in ./old-common. Is there a command I can use to cause CMake to actually build the lib in ./old-common (or move it there) or do I need to write a command to copy it after generation? Or should I just use an in-source build (which I would prefer not to do)? Or is there another obvious solution which I cannot see? I have been looking through this mailing list and combing through the CMake docs but I just cannot see an easy solution... target_link_libraries(prog2 old-common) target_link_libraries(prog3 old-common) Eike signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] avoid rebuilding targets depending on generated source files
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 about 10 different targets - all of which were
rebuilt because the 5 files (test*.*) were overwritten.
If you want to try running the test project on your system
test.g is at http://pastie.org/private/agzor3ibzoa5pom6q31qq
org.antlr.Tool is at www.antlr.org/download/antlr-3.4-complete.jar
After configuration, you can run the target by make X=0 and check the
timestamps by ls -l --full-time test.tokens parser src. Issuing make
X=0 again reveals that the copied files aren't rewritten as it happens
after make X=1. Thus, AFAICS, everything works as expected. Could you
check if the above-noted example also works on your system?
It does not work. The files are still overwritten.
What exactly does not work with your example? You wrote:
I have 4 cmake -E copy_if_different commands, one for each file.
Only the last file is not copied (if similar). [...]
Does this mean that the last file out of four - in fact, your example
handles five files - is not copied *although* the source file and the
destination file are different, i.e. similar but not equal?
Yes the file test.tokens is not copied overwritten since they are
exactly (diff) similar files. This is the case with the other 4 files as
well,
but they are still copied over and rewritten.
You wrote further:
[...] The others are copied
even if they are the same.
I verfied that they are the same with a diff.
Does this mean that source files are copied *although* they are equal
to their respective destination file? How do you determine that they
have been copied? Do you check the timestamps? With --full-time?
Yes, I do check with ls -l --full-time. Except test.tokens, all the other
files
are copied over (rewritten) even though they are exactly the same (diff
same I mean).
This is what is confusing me about the behavior of copy_if_different.
that is why it works only with test.tokens and not others.
PS: Does org.antlr.Tool write to the source tree? If so: Don't do that.
Yes, it generates the files in the source dir itself (where test.g is
present)
I now modified CMakeLists to copy test.g to the project build folder and
run it there. The new CMakeLists is at
http://pastie.org/private/p1yi0l8so9cqimqlywfmhw
Thank You
Ajay
On Sun, Mar 4, 2012 at 12:52 AM, Michael Hertling mhertl...@online.dewrote:
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 CMake - that's what I actually meant
with minimal but complete as I don't have the org.antlr.Tool
Java program:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(P NONE)
SET(CMAKE_VERBOSE_MAKEFILE ON)
SET(GrammarSource ${PROJECT_BINARY_DIR}/src)
FILE(MAKE_DIRECTORY ${PROJECT_BINARY_DIR}/src)
ADD_CUSTOM_TARGET(GrammarBuild ALL
COMMAND ${CMAKE_COMMAND} -E echo \${X}
${GrammarSource}/testLexer.h
COMMAND ${CMAKE_COMMAND} -E echo \${X}
${GrammarSource}/testLexer.c
COMMAND ${CMAKE_COMMAND} -E echo \${X}
${GrammarSource}/testParser.h
COMMAND ${CMAKE_COMMAND} -E echo \${X}
${GrammarSource}/testParser.c
COMMAND ${CMAKE_COMMAND} -E echo \${X}
${PROJECT_BINARY_DIR}/test.tokens
)
ADD_CUSTOM_COMMAND(TARGET GrammarBuild POST_BUILD
COMMAND ${CMAKE_COMMAND} -E copy_if_different
${GrammarSource}/testLexer.h
${PROJECT_BINARY_DIR}/parser/testLexer.h
COMMAND ${CMAKE_COMMAND} -E copy_if_different
${GrammarSource}/testLexer.c
${PROJECT_BINARY_DIR}/parser/testLexer.c
COMMAND ${CMAKE_COMMAND} -E copy_if_different
${GrammarSource}/testParser.h
${PROJECT_BINARY_DIR}/parser/testParser.h
COMMAND ${CMAKE_COMMAND} -E copy_if_different
${GrammarSource}/testParser.c
${PROJECT_BINARY_DIR}/parser/testParser.c
COMMAND ${CMAKE_COMMAND} -E copy_if_different
${PROJECT_BINARY_DIR}/test.tokens
${PROJECT_BINARY_DIR}/parser/test.tokens
)
After configuration, you can run the target by make X=0 and check the
timestamps by ls -l --full-time test.tokens parser src. Issuing make
X=0 again reveals that the copied files aren't rewritten as it happens
after make X=1. Thus, AFAICS, everything works as expected. Could you
check if the above-noted example also works on your system?
What exactly does not work with your example? You wrote:
I have 4 cmake -E copy_if_different commands, one for each file.
Only the last file is not copied (if similar). [...]
Does this mean that the last file out of four - in fact, your
Re: [CMake] Generated library location
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 look for it in ./old-common. target_link_libraries(prog2 old-common) target_link_libraries(prog3 old-common) Thanks, Eike! That's what I was doing, so your suggestion told me I hadn't messed up there and I went looking for the problem a little deeper. That's when I found that in the link_directories command, in two of the CMakeLists.txt files, was pointing to an old dir (from the old code) and I hadn't updated it to use the old-common dir. (The curse of copy/paste when you aren't sure of what you're doing!) Now, it's working -- thanks, again! -- Kevin Nathan (Arizona, USA) http://www.project54.com Open standards. Open source. Open minds. The command line is the front line. Linux 2.6.37.6-0.11-desktop 12:49pm up 18 days 22:08, 13 users, load average: 0.12, 0.19, 0.22 -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Generated library location
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 in ./build/old-common but the source for prog2 and prog3 all look for it in ./old-common. target_link_libraries(prog2 old-common) target_link_libraries(prog3 old-common) Thanks, Eike! That's what I was doing, so your suggestion told me I hadn't messed up there and I went looking for the problem a little deeper. That's when I found that in the link_directories command, in two of the CMakeLists.txt files, was pointing to an old dir (from the old code) and I hadn't updated it to use the old-common dir. (The curse of copy/paste when you aren't sure of what you're doing!) Now, it's working -- thanks, again! 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. Eike signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] avoid rebuilding targets depending on generated source files
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 cleanup the big CMakeLists file
I had and removed about 10 different targets - all of which were
rebuilt because the 5 files (test*.*) were overwritten.
If you want to try running the test project on your system
test.g is at http://pastie.org/private/agzor3ibzoa5pom6q31qq
org.antlr.Tool is at www.antlr.org/download/antlr-3.4-complete.jar
After configuration, you can run the target by make X=0 and check the
timestamps by ls -l --full-time test.tokens parser src. Issuing make
X=0 again reveals that the copied files aren't rewritten as it happens
after make X=1. Thus, AFAICS, everything works as expected. Could you
check if the above-noted example also works on your system?
It does not work. The files are still overwritten.
Could you run the following shell script in a build tree configured
with the CMakeLists.txt from my previous reply and post the output?
# check.sh:
make X=0 21 /dev/null
echo After make X=0 (1):
echo ---
echo
ls --full-time test.tokens src parser
echo -ne \n\n
sleep 3
make X=0 21 /dev/null
echo After make X=0 (2):
echo ---
echo
ls --full-time test.tokens src parser
echo -ne \n\n
sleep 3
make X=1 21 /dev/null
echo After make X=1:
echo ---
echo
ls --full-time test.tokens src parser
# End of check.sh
BTW, which CMake version do you use?
Regards,
Michael
PS: Could you set up your e-mail client so that it marks quoted
text in some way? Currently, one can't distinguish between
the lines you are writing and the lines written by others.
What exactly does not work with your example? You wrote:
I have 4 cmake -E copy_if_different commands, one for each file.
Only the last file is not copied (if similar). [...]
Does this mean that the last file out of four - in fact, your example
handles five files - is not copied *although* the source file and the
destination file are different, i.e. similar but not equal?
Yes the file test.tokens is not copied overwritten since they are
exactly (diff) similar files. This is the case with the other 4 files as
well,
but they are still copied over and rewritten.
You wrote further:
[...] The others are copied
even if they are the same.
I verfied that they are the same with a diff.
Does this mean that source files are copied *although* they are equal
to their respective destination file? How do you determine that they
have been copied? Do you check the timestamps? With --full-time?
Yes, I do check with ls -l --full-time. Except test.tokens, all the other
files
are copied over (rewritten) even though they are exactly the same (diff
same I mean).
This is what is confusing me about the behavior of copy_if_different.
that is why it works only with test.tokens and not others.
PS: Does org.antlr.Tool write to the source tree? If so: Don't do that.
Yes, it generates the files in the source dir itself (where test.g is
present)
I now modified CMakeLists to copy test.g to the project build folder and
run it there. The new CMakeLists is at
http://pastie.org/private/p1yi0l8so9cqimqlywfmhw
Thank You
Ajay
On Sun, Mar 4, 2012 at 12:52 AM, Michael Hertling mhertl...@online.dewrote:
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 CMake - that's what I actually meant
with minimal but complete as I don't have the org.antlr.Tool
Java program:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(P NONE)
SET(CMAKE_VERBOSE_MAKEFILE ON)
SET(GrammarSource ${PROJECT_BINARY_DIR}/src)
FILE(MAKE_DIRECTORY ${PROJECT_BINARY_DIR}/src)
ADD_CUSTOM_TARGET(GrammarBuild ALL
COMMAND ${CMAKE_COMMAND} -E echo \${X}
${GrammarSource}/testLexer.h
COMMAND ${CMAKE_COMMAND} -E echo \${X}
${GrammarSource}/testLexer.c
COMMAND ${CMAKE_COMMAND} -E echo \${X}
${GrammarSource}/testParser.h
COMMAND ${CMAKE_COMMAND} -E echo \${X}
${GrammarSource}/testParser.c
COMMAND ${CMAKE_COMMAND} -E echo \${X}
${PROJECT_BINARY_DIR}/test.tokens
)
ADD_CUSTOM_COMMAND(TARGET GrammarBuild POST_BUILD
COMMAND ${CMAKE_COMMAND} -E copy_if_different
${GrammarSource}/testLexer.h
${PROJECT_BINARY_DIR}/parser/testLexer.h
COMMAND ${CMAKE_COMMAND} -E copy_if_different
${GrammarSource}/testLexer.c
${PROJECT_BINARY_DIR}/parser/testLexer.c
COMMAND ${CMAKE_COMMAND} -E copy_if_different
${GrammarSource}/testParser.h
Re: [CMake] Code and API review request for Qt5 CMake files
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)
include_directories(${Qt5Declarative_INCLUDE_DIRS})
add_definitions(${Qt5Declarative_DEFINITONS})
target_link_libraries(foo ${Qt5Declarative_LIBRARIES})
Each find_package finds its dependencies and adds its dependencies values to
its own variables. So already, the core module (and in the above example,
the gui module) don't need to be explicitly mentioned.
This is one of the things I'd like feedback on, and on of the reasons I'm
asking people to try this out, or to read the generated Config files.
Can anyone say they've read the generated files? Has anyone confirm they
have run this or something like it? :
git clone git://gitorious.org/qt/qtbase.git
cd qtbase
./configure
ls lib/cmake
To see the input files for the generated config files see:
https://qt.gitorious.org/qt/qtbase/blobs/master/mkspecs/cmake/Qt5BasicConfig.cmake.in
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Code and API review request for Qt5 CMake files
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 a good opportunity. Yes, please! And a good start would be cleaning up FindwxWidgets.cmake and porting it to use FPHSA so we get REQUIRED handling for free. Has this resulted in anything concrete being raised on the -developers list? Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] avoid rebuilding targets depending on generated source files
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_CUSTOM_TARGET(...)
ADD_CUSTOM_COMMAND(...)
i.e I am totally avoiding the process of rebuilding the test.g file and
copying the generated files to build/parser
*IF* test.g has not been modified.
Thank you very much
Ajay
PS: Could you set up your e-mail client so that it marks quoted
text in some way? Currently, one can't distinguish between
the lines you are writing and the lines written by others.
Sorry. I did not realize that. I use gmail and when I checked my sent
emails,
quoted text appears to be clearly marked. Is the quoted text in this email
marked properly.
On Sun, Mar 4, 2012 at 4:05 PM, Michael Hertling mhertl...@online.dewrote:
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 cleanup the big CMakeLists file
I had and removed about 10 different targets - all of which were
rebuilt because the 5 files (test*.*) were overwritten.
If you want to try running the test project on your system
test.g is at http://pastie.org/private/agzor3ibzoa5pom6q31qq
org.antlr.Tool is at www.antlr.org/download/antlr-3.4-complete.jar
After configuration, you can run the target by make X=0 and check the
timestamps by ls -l --full-time test.tokens parser src. Issuing make
X=0 again reveals that the copied files aren't rewritten as it happens
after make X=1. Thus, AFAICS, everything works as expected. Could you
check if the above-noted example also works on your system?
It does not work. The files are still overwritten.
Could you run the following shell script in a build tree configured
with the CMakeLists.txt from my previous reply and post the output?
# check.sh:
make X=0 21 /dev/null
echo After make X=0 (1):
echo ---
echo
ls --full-time test.tokens src parser
echo -ne \n\n
sleep 3
make X=0 21 /dev/null
echo After make X=0 (2):
echo ---
echo
ls --full-time test.tokens src parser
echo -ne \n\n
sleep 3
make X=1 21 /dev/null
echo After make X=1:
echo ---
echo
ls --full-time test.tokens src parser
# End of check.sh
BTW, which CMake version do you use?
Regards,
Michael
PS: Could you set up your e-mail client so that it marks quoted
text in some way? Currently, one can't distinguish between
the lines you are writing and the lines written by others.
What exactly does not work with your example? You wrote:
I have 4 cmake -E copy_if_different commands, one for each file.
Only the last file is not copied (if similar). [...]
Does this mean that the last file out of four - in fact, your example
handles five files - is not copied *although* the source file and the
destination file are different, i.e. similar but not equal?
Yes the file test.tokens is not copied overwritten since they are
exactly (diff) similar files. This is the case with the other 4 files as
well,
but they are still copied over and rewritten.
You wrote further:
[...] The others are copied
even if they are the same.
I verfied that they are the same with a diff.
Does this mean that source files are copied *although* they are equal
to their respective destination file? How do you determine that they
have been copied? Do you check the timestamps? With --full-time?
Yes, I do check with ls -l --full-time. Except test.tokens, all the other
files
are copied over (rewritten) even though they are exactly the same (diff
same I mean).
This is what is confusing me about the behavior of copy_if_different.
that is why it works only with test.tokens and not others.
PS: Does org.antlr.Tool write to the source tree? If so: Don't do that.
Yes, it generates the files in the source dir itself (where test.g is
present)
I now modified CMakeLists to copy test.g to the project build folder and
run it there. The new CMakeLists is at
http://pastie.org/private/p1yi0l8so9cqimqlywfmhw
Thank You
Ajay
On Sun, Mar 4, 2012 at 12:52 AM, Michael Hertling mhertl...@online.de
wrote:
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 CMake - that's what I actually meant
with minimal but complete as I don't have the org.antlr.Tool
Java program:
Re: [CMake] Code and API review request for Qt5 CMake files
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 post?
Absolutely, I would greatly appreciate a well-designed and component-
aware Qt5Config.cmake.
Yes. This thread confirms though that it is not a simple issue as I wrote
before :)
In general, there might be reasons why a multi-
component package's components that are to be used together should not
be requested in separate FIND_PACKAGE() invocations, see [1] and look
for package X with components A and B. However, I don't know if Qt5
will be the first example of that kind.
Your exact example is not covered by the Qt5 situation as far as I can tell.
However, similar issues already crop up (with Qt4 based systems). Can you
confirm whether you are aware of the issues around code like this regarding
the use of -DQT_GUI_LIB with the foo target so I know if I need to explain
it and whether we are on the same page? :
find_package(Qt4 REQUIRED Gui Test)
include(${QT_USE_FILE})
add_executable(bar ${QT_QTCORE_LIBRARIES} ${QT_QTGUI_LIBRARIES})
add_executable(foo ${QT_QTCORE_LIBRARIES} ${QT_QTTEST_LIBRARIES})
Referring to Qt5_XYZ_FOUND alone is not reliable because this variable
wouldn't have received a definite value if Qt5Config.cmake hasn't been
found by FIND_PACKAGE().
I don't actually see the problem with checking Qt5_XYZ_FOUND. Unset
variables are well defined as false in the if() command. Maybe I
misunderstand you?
I.e., the user would refer to this variable's
value before the FIND_PACKAGE() call; probably, that's not expected.
Why would the user refer to Qt5_Xml_FOUND before
find_package(Qt5 REQUIRED Xml)
?
[...] At least, I think
something like qt5_use_package is a better idea anyway.
First of all, I definitely agree to your criticism of UseQt4.cmake in
[5], and I appreciate your attempt to get rid of such a use file for
Qt5. However, I'd choose a Qt5Config.cmake over qt5_use_package(),
and my current vision for the former's usage is roughly, e.g.,
FIND_PACKAGE(Qt5 REQUIRED Xml)
SET_TARGET_PROPERTIES(t1 PROPERTIES
COMPILE_DEFINITIONS ${Qt5_DEFINITIONS}
Again, just to disseminate information, each Qt5moduleConfig.cmake file
sets Qt5module_DEFINITIONS for use with the add_definitions() command, and
Qt5module_COMPILE_DEFINITIONS for use with the COMPILE_DEFINITIONS
property. The difference is that one already contains the '-D' and the other
doesn't (and breaks if it is present).
So, in your example, that would be ${Qt5_COMPILE_DEFINITIONS} if a
Qt5Config.cmake exists some day.
INCLUDE_DIRECTORIES ${Qt5_INCLUDE_DIRS}) # If available one day.
The patches for this are in next but didn't get merged to master yet. It
should indeed be part of CMake 2.8.8 and function similar to what you write
here.
TARGET_LINK_LIBRARIES(t1 ${Qt5_LIBRARIES})
FIND_PACKAGE(Qt5 REQUIRED Sql)
SET_TARGET_PROPERTIES(t2 PROPERTIES
COMPILE_DEFINITIONS ${Qt5_DEFINITIONS}
INCLUDE_DIRECTORIES ${Qt5_INCLUDE_DIRS}) # If available one day.
TARGET_LINK_LIBRARIES(t2 ${Qt5_LIBRARIES})
with t2 not being overlinked due to accumulated results.
Yes, accumulation versus replacement for the values of all the variables set
by Qt5Config.cmake is also a complication that it introduces.
Some spontaneous questions/remarks on {cmake,qt5}_use_package():
- Do they need to be macros?
You mean as opposed to functions? I think they could be functions instead.
- What if _package is a multi-component one?
The macro as it is currently written (in a unit test in the Qt5 repo)
guardss the check for ${_package} with ${${_package}_FOUND}. My assumption
was that the convention was that if ${${_package}_FOUND} is true it doesn't
need to be found again, so in special cases where components need to be
specified, you would simply invoke find_package before the cmake_use_package
call:
cmake_use_package(t1 PNG)
find_package(Foo REQUIRED Xxx Yyy)
# Foo variables contain the requirements for Xxx and Yyy too.
cmake_use_package(t1 Foo) # Doesn't find Foo again, but uses the variables.
This thread indicates that that is not as conventional as I thought, but
this feature could be used to define what the convention should be as well
as create the incentive to create the convention.
- What about COMPILE_DEFINITIONS_CONFIG properties?
to be decided :) along with include directories for different configs (which
don't even have a syntax for representation in CMake yet, but it's not going
to be INCLUDE_DIRECTORIES_CONFIG) etc too.
- Target property INCLUDE_DIRECTORIES coming up in 2.8.8?
Yep.
- Using SET_PROPERTY(... APPEND_STRING ...) on COMPILE_FLAGS?
That doesn't account for duplicates.
- Do
list(APPEND _flags ...)
...
set_target_properties(... PROPERTIES
Re: [CMake] avoid rebuilding targets depending on generated source files
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 the source files - i.e., they receive a new
timestamp - but their contents do not change. Thus, the destination
files in the parser directory are *not* touched by the second make
X=0, and this can be seen clearly by reference to the timestamps.
It's the subsequent make X=1 which provides for a new content of
the source files and makes cmake -E copy_if_different copy the
sources to the destinations. That's why I said everything works
as expected, but you wrote:
It does not work. The files are still overwritten.
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
- not copy a file although the destination does not
exist or does not have the same content as the source?
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_CUSTOM_TARGET(...)
ADD_CUSTOM_COMMAND(...)
i.e I am totally avoiding the process of rebuilding the test.g file and
copying the generated files to build/parser
*IF* test.g has not been modified.
...and if test.g is once modified, you won't have a custom target which
regenerates the source files and copies them to the parser directory -
I'm pretty sure this is not what you intend. Recall the difference
between configuration time and build time in CMakified projects.
PS: Could you set up your e-mail client so that it marks quoted
text in some way? Currently, one can't distinguish between
the lines you are writing and the lines written by others.
Sorry. I did not realize that. I use gmail and when I checked my sent
emails,
quoted text appears to be clearly marked. Is the quoted text in this email
marked properly.
Yes, it is.
Regards,
Michael
On Sun, Mar 4, 2012 at 4:05 PM, Michael Hertling mhertl...@online.dewrote:
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 cleanup the big CMakeLists file
I had and removed about 10 different targets - all of which were
rebuilt because the 5 files (test*.*) were overwritten.
If you want to try running the test project on your system
test.g is at http://pastie.org/private/agzor3ibzoa5pom6q31qq
org.antlr.Tool is at www.antlr.org/download/antlr-3.4-complete.jar
After configuration, you can run the target by make X=0 and check the
timestamps by ls -l --full-time test.tokens parser src. Issuing make
X=0 again reveals that the copied files aren't rewritten as it happens
after make X=1. Thus, AFAICS, everything works as expected. Could you
check if the above-noted example also works on your system?
It does not work. The files are still overwritten.
Could you run the following shell script in a build tree configured
with the CMakeLists.txt from my previous reply and post the output?
# check.sh:
make X=0 21 /dev/null
echo After make X=0 (1):
echo ---
echo
ls --full-time test.tokens src parser
echo -ne \n\n
sleep 3
make X=0 21 /dev/null
echo After make X=0 (2):
echo ---
echo
ls --full-time test.tokens src parser
echo -ne \n\n
sleep 3
make X=1 21 /dev/null
echo After make X=1:
echo ---
echo
ls --full-time test.tokens src parser
# End of check.sh
BTW, which CMake version do you use?
Regards,
Michael
PS: Could you set up your e-mail client so that it marks quoted
text in some way? Currently, one can't distinguish between
the lines you are writing and the lines written by others.
What exactly does not work with your example? You wrote:
I have 4 cmake -E copy_if_different commands, one for each file.
Only the last file is not copied (if similar). [...]
Does this mean that the last file out of four - in fact, your example
handles five files - is not copied *although* the source file and the
destination file are different, i.e. similar but not equal?
Yes the file test.tokens is not copied overwritten since they are
exactly (diff) similar files. This is the case with the other 4 files as
well,
but they are still copied over and rewritten.
You wrote further:
[...] The others are copied
even if they are the same.
I verfied that they are the same with a diff.
Does this mean that source files are copied *although* they are equal
to their respective destination file? How do you determine that they
have been copied? Do you check the timestamps? With --full-time?
Re: [CMake] avoid rebuilding targets depending on generated source files
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 happened. I must have done something
wrong by overlooking some detail. It works now.
*I did not initially run the CMakeLists you had provided.*
I had run my own version of CMakeLists by inserting some rules
from the CMakeLists file you had provided and I did something
wrong there. Hence, that did not work.
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_CUSTOM_TARGET(...)
ADD_CUSTOM_COMMAND(...)
i.e I am totally avoiding the process of rebuilding the test.g file and
copying the generated files to build/parser
*IF* test.g has not been modified.
...and if test.g is once modified, you won't have a custom target which
regenerates the source files and copies them to the parser directory -
I'm pretty sure this is not what you intend. Recall the difference
between configuration time and build time in CMakified projects.
No, if test.g is modified the *if* condition is true and the new version
is copied over to the build directory; the custom target builds it
and the custom command moves the generated files into build/parser.
For the initial run of make test.g is not present in the build folder,
since it
was never copied before. For this case, I have another IF(EXISTS
build/test.g) conditional
which copies it from src to build folder and then executes it.
Thanks
Ajay
On Sun, Mar 4, 2012 at 7:35 PM, Michael Hertling mhertl...@online.dewrote:
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 the source files - i.e., they receive a new
timestamp - but their contents do not change. Thus, the destination
files in the parser directory are *not* touched by the second make
X=0, and this can be seen clearly by reference to the timestamps.
It's the subsequent make X=1 which provides for a new content of
the source files and makes cmake -E copy_if_different copy the
sources to the destinations. That's why I said everything works
as expected, but you wrote:
It does not work. The files are still overwritten.
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
- not copy a file although the destination does not
exist or does not have the same content as the source?
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_CUSTOM_TARGET(...)
ADD_CUSTOM_COMMAND(...)
i.e I am totally avoiding the process of rebuilding the test.g file and
copying the generated files to build/parser
*IF* test.g has not been modified.
...and if test.g is once modified, you won't have a custom target which
regenerates the source files and copies them to the parser directory -
I'm pretty sure this is not what you intend. Recall the difference
between configuration time and build time in CMakified projects.
PS: Could you set up your e-mail client so that it marks quoted
text in some way? Currently, one can't distinguish between
the lines you are writing and the lines written by others.
Sorry. I did not realize that. I use gmail and when I checked my sent
emails,
quoted text appears to be clearly marked. Is the quoted text in this
email
marked properly.
Yes, it is.
Regards,
Michael
On Sun, Mar 4, 2012 at 4:05 PM, Michael Hertling mhertl...@online.de
wrote:
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 cleanup the big CMakeLists file
I had and removed about 10 different targets - all of which were
rebuilt because the 5 files (test*.*) were overwritten.
If you want to try running the test project on your system
test.g is at http://pastie.org/private/agzor3ibzoa5pom6q31qq
org.antlr.Tool is at www.antlr.org/download/antlr-3.4-complete.jar
After configuration, you can run the target by make X=0 and check the
timestamps by ls -l --full-time test.tokens parser src. Issuing make
X=0 again reveals that the copied files aren't rewritten as it happens
after make X=1. Thus, AFAICS, everything works as expected. Could you
check if the above-noted example
[Cmake-commits] CMake branch, next, updated. v2.8.7-3051-gd8adfc2
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 b43cd1252c9e7d5dfe7ed9ef9bbd4671b38a535d (commit)
via 76bff6029222449e0194b9348ac146ab8adfe4e9 (commit)
via ac2979e4b36577e10b2180624050e600179a53da (commit)
from b60b277d9e6b8929864daf88260e2cadd3eea847 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d8adfc2f12b866396f56b2fae89987dafe370734
commit d8adfc2f12b866396f56b2fae89987dafe370734
Merge: b60b277 b43cd12
Author: Rolf Eike Beer e...@sf-mail.de
AuthorDate: Sun Mar 4 07:59:35 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Sun Mar 4 07:59:35 2012 -0500
Merge topic 'test-getpropery' into next
b43cd12 add test for get_property() errors
76bff60 KWSys Nightly Date Stamp
ac2979e KWSys Nightly Date Stamp
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b43cd1252c9e7d5dfe7ed9ef9bbd4671b38a535d
commit b43cd1252c9e7d5dfe7ed9ef9bbd4671b38a535d
Author: Rolf Eike Beer e...@sf-mail.de
AuthorDate: Sun Mar 4 13:43:23 2012 +0100
Commit: Rolf Eike Beer e...@sf-mail.de
CommitDate: Sun Mar 4 13:43:23 2012 +0100
add test for get_property() errors
diff --git a/Tests/CMakeTests/CMakeLists.txt b/Tests/CMakeTests/CMakeLists.txt
index aa4d52e..7450dc5 100644
--- a/Tests/CMakeTests/CMakeLists.txt
+++ b/Tests/CMakeTests/CMakeLists.txt
@@ -22,6 +22,7 @@ AddCMakeTest(ConfigureFile )
AddCMakeTest(SeparateArguments )
AddCMakeTest(ImplicitLinkInfo )
AddCMakeTest(ModuleNotices )
+AddCMakeTest(GetProperty )
AddCMakeTest(If )
AddCMakeTest(String )
AddCMakeTest(Math )
diff --git a/Tests/CMakeTests/GetProperty-Bad-Argument.cmake
b/Tests/CMakeTests/GetProperty-Bad-Argument.cmake
new file mode 100644
index 000..382dabb
--- /dev/null
+++ b/Tests/CMakeTests/GetProperty-Bad-Argument.cmake
@@ -0,0 +1 @@
+get_property(FOO GLOBAL PROPERTY FOO FOO)
diff --git a/Tests/CMakeTests/GetProperty-Bad-Directory.cmake
b/Tests/CMakeTests/GetProperty-Bad-Directory.cmake
new file mode 100644
index 000..cdbfa80
--- /dev/null
+++ b/Tests/CMakeTests/GetProperty-Bad-Directory.cmake
@@ -0,0 +1 @@
+get_property(FOO DIRECTORY NonExistentSubDir PROPERTY FOO)
diff --git a/Tests/CMakeTests/GetProperty-Bad-Scope.cmake
b/Tests/CMakeTests/GetProperty-Bad-Scope.cmake
new file mode 100644
index 000..ea8566b
--- /dev/null
+++ b/Tests/CMakeTests/GetProperty-Bad-Scope.cmake
@@ -0,0 +1 @@
+get_property(FOO FOO FOO)
diff --git a/Tests/CMakeTests/GetProperty-Bad-Target.cmake
b/Tests/CMakeTests/GetProperty-Bad-Target.cmake
new file mode 100644
index 000..9992dab
--- /dev/null
+++ b/Tests/CMakeTests/GetProperty-Bad-Target.cmake
@@ -0,0 +1 @@
+get_property(FOO TARGET FOO PROPERTY FOO)
diff --git a/Tests/CMakeTests/GetProperty-Bad-Test.cmake
b/Tests/CMakeTests/GetProperty-Bad-Test.cmake
new file mode 100644
index 000..44bf3eb
--- /dev/null
+++ b/Tests/CMakeTests/GetProperty-Bad-Test.cmake
@@ -0,0 +1 @@
+get_property(FOO TEST FOO PROPERTY FOO)
diff --git a/Tests/CMakeTests/GetProperty-Doc-Properties.cmake
b/Tests/CMakeTests/GetProperty-Doc-Properties.cmake
new file mode 100644
index 000..6c2c362
--- /dev/null
+++ b/Tests/CMakeTests/GetProperty-Doc-Properties.cmake
@@ -0,0 +1,10 @@
+get_property(FOO_BRIEF GLOBAL PROPERTY FOO BRIEF_DOCS)
+get_property(FOO_FULL GLOBAL PROPERTY FOO FULL_DOCS)
+
+if (NOT FOO_BRIEF STREQUAL NOTFOUND)
+ message(SEND_ERROR property FOO has BRIEF_DOCS set to '${FOO_BRIEF}')
+endif ()
+
+if (NOT FOO_FULL STREQUAL NOTFOUND)
+ message(SEND_ERROR property FOO has FULL_DOCS set to '${FOO_FULL}')
+endif ()
diff --git a/Tests/CMakeTests/GetProperty-Global-Name.cmake
b/Tests/CMakeTests/GetProperty-Global-Name.cmake
new file mode 100644
index 000..497700c
--- /dev/null
+++ b/Tests/CMakeTests/GetProperty-Global-Name.cmake
@@ -0,0 +1 @@
+get_property(FOO GLOBAL FOO PROPERTY FOO)
diff --git a/Tests/CMakeTests/GetProperty-Missing-Argument.cmake
b/Tests/CMakeTests/GetProperty-Missing-Argument.cmake
new file mode 100644
index 000..f0d004d
--- /dev/null
+++ b/Tests/CMakeTests/GetProperty-Missing-Argument.cmake
@@ -0,0 +1 @@
+get_property()
diff --git a/Tests/CMakeTests/GetProperty-No-Cache.cmake
b/Tests/CMakeTests/GetProperty-No-Cache.cmake
new file mode 100644
index 000..9719fe7
--- /dev/null
+++ b/Tests/CMakeTests/GetProperty-No-Cache.cmake
@@ -0,0 +1 @@
+get_property(FOO CACHE PROPERTY FOO)
diff --git a/Tests/CMakeTests/GetProperty-No-Property.cmake
b/Tests/CMakeTests/GetProperty-No-Property.cmake
new file mode 100644
index 000..bee230d
--- /dev/null
+++
[Cmake-commits] CMake branch, master, updated. v2.8.7-560-g17a099d
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 76bff6029222449e0194b9348ac146ab8adfe4e9 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=17a099dd1379051eaa6c0a66a5ee6df5aea49089 commit 17a099dd1379051eaa6c0a66a5ee6df5aea49089 Author: KWSys Robot kwro...@kitware.com AuthorDate: Mon Mar 5 00:01:07 2012 -0500 Commit: KWSys Robot kwro...@kitware.com CommitDate: Mon Mar 5 00:05:06 2012 -0500 KWSys Nightly Date Stamp diff --git a/Source/kwsys/kwsysDateStamp.cmake b/Source/kwsys/kwsysDateStamp.cmake index 92b9f64..d4dcea9 100644 --- a/Source/kwsys/kwsysDateStamp.cmake +++ b/Source/kwsys/kwsysDateStamp.cmake @@ -18,4 +18,4 @@ SET(KWSYS_DATE_STAMP_YEAR 2012) SET(KWSYS_DATE_STAMP_MONTH 03) # KWSys version date day component. Format is DD. -SET(KWSYS_DATE_STAMP_DAY 04) +SET(KWSYS_DATE_STAMP_DAY 05) --- Summary of changes: Source/kwsys/kwsysDateStamp.cmake |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
