[cmake-developers] To warn or to error out ? - wording and compatiblity
Hi, when using out-of-source builds and the Eclipse CDT project generator, a "linked resource" is created in the Eclipse project file, which points to CMAKE_SOURCE_DIR, so the user can browse the source directory. Now, when CMAKE_BINARY_DIR is a subdirectory of CMAKE_SOURCE_DIR (e.g. MyProject/build/ ), such a "linked resource" can't be created, and the resulting project file still works, but is less usable. I just added a warning, so that cmake now says: "-- Configuring done CMake Warning in CMakeLists.txt: The build directory is a subdirectory of the source directory. This is not supported well by Eclipse. It is strongly recommended to use a build directory which is not a subdirectory of the source directory. -- Generating done" I'm thinking about using FATAL_ERROR instead of warning for this, since the resulting project file without that link really feels wrong, and I recommend everybody to not build in a subdir of the source dir. This would have the effect that a build dir which was working until now does not work anymore with the next cmake release, the user would have to create a new build dir in some other location. Would this be acceptable ? Alex -- 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] Nitpicking ProcessorCount.cmake
On Sunday 23 October 2011, Alexander Neundorf wrote: > Hi, > > I just used ProcessorCount.cmake the first time. > I noticed a small issue: > AFAIK module file names in cmake use CamelCase, while the macros/functions > use underscores: SomeCoolStuff.cmake -> some_cool_stuff() > > ProcessorCount.cmake doesn't do this, the function is named > processorcount() > > IMO we should keep it this way, since it is defacto-standard, and it also > makes sense, since I always recommend to use all-lower-caps style for > commands, or at least all-upper-caps. > And when using all-lower, the function name is not that easy to read > anymore. > > So, should I rename it to processor_count() and add a processorcount() for > backward compatibility ? > > Alex > > P.S. it is similar with ExternalPackage.cmake, externalproject_add() > doesn't use the old style, it would have been external_project_add() > instead. -- Any opinions ? Alex -- 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] To warn or to error out ? - wording and compatiblity
On Tuesday 01 November 2011, Eric Noulard wrote: > 2011/11/1 Alexander Neundorf : ... > > and I'd be very happy if this could be solved. > > Me too. > I'll dig a little bit on the Eclipse side again, but generating 2 > files in the source does not look like a big deal. The thing is that it would not be possible to create multiple build trees with Eclipse project files for one source tree (because the .project/.cproject files from one build tree would overwrite the .project/.cproject files from the other build trees). Do you know whether adding the source dirs as "SOURCE" pathentries maybe makes the version control stuff appear ? Alex -- 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] To warn or to error out ? - wording and compatiblity
2011/11/1 Alexander Neundorf : > On Tuesday 01 November 2011, Eric Noulard wrote: >> 2011/11/1 Alexander Neundorf : > ... >> > and I'd be very happy if this could be solved. >> >> Me too. >> I'll dig a little bit on the Eclipse side again, but generating 2 >> files in the source does not look like a big deal. > > The thing is that it would not be possible to create multiple build trees with > Eclipse project files for one source tree (because the .project/.cproject > files from one build tree would overwrite the .project/.cproject files from > the other build trees). > > Do you know whether adding the source dirs as "SOURCE" pathentries maybe makes > the version control stuff appear ? I don't know but I doubt it. (I tried: but this does not seem to have changed anything). As far as I understand the eclipse team sharing model implies that a "project" is shared as a whole not part of it. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- 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
[cmake-developers] [CMake 0012549]: Provide SccAuxPath support in Visual Studio VCPROJ
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=12549 == Reported By:void.pointer Assigned To: == Project:CMake Issue ID: 12549 Category: CMake Reproducibility:always Severity: feature Priority: high Status: new == Date Submitted: 2011-11-01 08:15 EDT Last Modified: 2011-11-01 08:15 EDT == Summary:Provide SccAuxPath support in Visual Studio VCPROJ Description: in Visual Studio's VCPROJ file, for Perforce source control bindings, is used to provide the perforce connection string which contains the server address, username, and workspace. Providing these here eliminates the Perforce connection window prompt that appears when opening each project in the solution (annoying). Below I have provided patch files that implement this feature. Note that 0002 is the one you want, I had to make a 2nd revision to make SccAuxPath optional (it makes sense, since not every binding source may need AuxPath). Please review the patch and submit it for 2.8.7 if possible. My team is already actively using this addition from the CMake executable I built on my machine with these changes. == Issue History Date ModifiedUsername FieldChange == 2011-11-01 08:15 void.pointer 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] To warn or to error out ? - wording and compatiblity
On Tue, Nov 1, 2011 at 5:58 AM, Alexander Neundorf wrote: > Hi, > > when using out-of-source builds and the Eclipse CDT project generator, a > "linked resource" is created in the Eclipse project file, which points to > CMAKE_SOURCE_DIR, so the user can browse the source directory. > > Now, when CMAKE_BINARY_DIR is a subdirectory of CMAKE_SOURCE_DIR (e.g. > MyProject/build/ ), such a "linked resource" can't be created, and the > resulting project file still works, but is less usable. > > I just added a warning, so that cmake now says: > > "-- Configuring done > CMake Warning in CMakeLists.txt: > The build directory is a subdirectory of the source directory. > > This is not supported well by Eclipse. It is strongly recommended to use a > build directory which is not a subdirectory of the source directory. > > > -- Generating done" > > > I'm thinking about using FATAL_ERROR instead of warning for this, since the > resulting project file without that link really feels wrong, and I recommend > everybody to not build in a subdir of the source dir. > > This would have the effect that a build dir which was working until now does > not work anymore with the next cmake release, the user would have to create a > new build dir in some other location. > > Would this be acceptable ? > > Alex > -- > > 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 > I think a warning is good enough here. I would phrase it in the positive sense, rather than in the negative sense, though: Rather than: > The build directory is a subdirectory of the source directory. > > This is not supported well by Eclipse. It is strongly recommended to use a > build directory which is not a subdirectory of the source directory. How about "It is strongly recommended to use a build directory which is a sibling of the source directory." -- 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] [Development] Installing Qt5Config.cmake from the Qt repo?
On Friday, October 28, 2011 07:58:25 Clinton Stimpson wrote: > On Friday, October 28, 2011 06:21:23 am Stephen Kelly wrote: > > On Friday, October 28, 2011 13:56:20 Thiago Macieira wrote: > > > On Friday, 28 de October de 2011 13:13:20 Stephen Kelly wrote: > > > > * If you want to be easily found for others to depend on, you > > > > write a > > > > > > > > Config.cmake file and install it to a location > > > > CMake > > > > will use> > > > > > > > > to find things like that. I assume this is similar to how > > > > pkgconfig > > > > works, but I have never used pkgconfig. > > > > > > Just like pkgconfig, I'd recommend that we make it one file per > > > library, not one global Qt5Config.cmake. > > > > What I want to investigate (I haven't yet, but I'm confident it will > > work) is if we can have both. We could have Qt5Core.cmake, Qt5Gui.cmake > > etc, and Qt5Config would be an aggregate which include()s the other > > configs based on the FIND_COMPONENTS. > > > > find_package(Qt5 COMPONENTS QtCore) > > or > > find_package(Qt5 COMPONENTS QtGui) > > > > for example. > > > > > Alternatively, let's be very clear: it's Qt5EssentialsConfig.cmake > > > and it includes NO other Qt addon. For those addons, they need to > > > provide the Config files themselves. > > > > Can you remind me where to find out what Qt5Essentials is or where I can > > find out? Searching in http://wiki.qt-project.org/ isn't throwing up > > anything. Is it roughly the contents of qtbase.git? Or does it include > > qtdeclarative.git too? > > > > Details like what would be included in Qt5Config could be discussed once > > there's some prototyping happening. I don't really feel strongly about > > it > > as long as it's roughly equivalent to what was made available by > > FindQt4.cmake. > > > > I'll wait a bit for other objections before prototyping though anyway. > > Then we can start looking at the real details. > > > > Thanks, > > Absolutely no objections from me. I'm glad to see this happening, and am > glad to see the new open governance in Qt. > > Thank you. Cool, you're welcome. I've pushed my work in progress now to gitorious and will send an email about it shortly. > > Lately, there has been more work in FindQt4.cmake to make it more complete. > For example, there has been recent support for building with static plugins > and easy deployment with cpack. > > Have you thought about taking it that far? Yes, that is in scope for the CMake files in Qt I think, but I haven't worked on it yet. > > If you'd like, I can offer some review or input based on my experience > maintaining FindQt4.cmake. Thanks, I'll certainly get in touch when it's getting closer to ready. In the mean-time you can look at what I've done so far in the link in my next email. Thanks, -- Stephen Kelly | Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Nitpicking ProcessorCount.cmake
On Tue, Nov 1, 2011 at 6:11 AM, Alexander Neundorf wrote: > On Sunday 23 October 2011, Alexander Neundorf wrote: >> Hi, >> >> I just used ProcessorCount.cmake the first time. >> I noticed a small issue: >> AFAIK module file names in cmake use CamelCase, while the macros/functions >> use underscores: SomeCoolStuff.cmake -> some_cool_stuff() >> >> ProcessorCount.cmake doesn't do this, the function is named >> processorcount() >> >> IMO we should keep it this way, since it is defacto-standard, and it also >> makes sense, since I always recommend to use all-lower-caps style for >> commands, or at least all-upper-caps. >> And when using all-lower, the function name is not that easy to read >> anymore. >> >> So, should I rename it to processor_count() and add a processorcount() for >> backward compatibility ? >> >> Alex >> >> P.S. it is similar with ExternalPackage.cmake, externalproject_add() >> doesn't use the old style, it would have been external_project_add() >> instead. -- > > Any opinions ? > > Alex > -- > > 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 > I think our intent with the naming introduced by ExternalProject.cmake (and followed with ProcessorCount.cmake) was to adopt a convention wherein the names of functions in a module meant for public consumption should be prefixed with the module name itself, a sort of poor-man's namespace. If all modules followed such a convention, then we can avoid multiple modules defining the same function name by accident. And even if only the modules I've written follow such a convention, my function names are unlikely to conflict with those that exist in another module. I don't much care for recommending all lowercase or all uppercase as CMake-language defined function names because then there's no at-a-glance way to distinguish between built-in commands and module-defined commands. (But I guess there doesn't really need to be either... People who need to know more will go looking for the documentation and find it either way.) I prefer camel case, personally, because I find it easier to read than underscore separated. And I read far too much CMake code compared to the average person. :-) Just my opinion. Would like to hear others, too. David C. -- 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] [Development] Installing Qt5Config.cmake from the Qt repo?
On Friday, October 28, 2011 13:13:20 Stephen Kelly wrote:
> == Summary ==
>
> I'm considering adding some cmake files to Qt, which would be installed by
> Qt, and which would make it easier for CMake based projects to depend on
> Qt.
>
> I'm CC'ing the cmake developers too see what they think of the idea too.
>From the feedback, it seems like this is a welcome idea. So I went ahead and
implemented it. My work is in the KDAB Qt5 clone on gitorious[1].
[1]https://qt.gitorious.org/+kdab-developers/qt/kdab-developers-
qtbase/commit/e79663d1352e7322839dfdfa2fa36bb30aaf4aac
At the moment it's a bit hacky but it does work on linux and it can be cleaned
up. At this point I'm looking for some initial feedback on the cmake
dependency (see below).
I was able to build a library in kdelibs framework branch with code similar
to:
find_package(Qt5 REQUIRED Core Gui Widgets)
include(${Qt5_USE_FILE})
add_library(itemmodels SHARED ${itemmodels_SRCS})
target_link_libraries(itemmodels
${Qt5Core_LIBRARY}
${Qt5Gui_LIBRARY}
${Qt5Widgets_LIBRARY}
)
So, as a proof of concept, I think I can call this a sucess.
>
> == Clarification ==
>
> To avoid misunderstanding:
>
> * This proposal is not about porting the Qt build system to CMake.
> * This would not make Qt depend on CMake at all
> * I am proposing to add some plain text files to the Qt repo for
> installation * Those plain text files would need to be generated while
> building Qt (using existing mechanisms, like perl).
In the branch, I do depend on cmake at configure-time to generate the Targets
files. These are platform specific files that cmake uses to build against
libraries in debug and release versions.
I would like to add this non-optional configure time dependency on cmake to Qt.
The alternative would be to maintain Targets files for multiple platforms by
generating those files at maintenance time (ie, running the script to generate
them, copy the result into place and check it in).
This maintenance burden is not really justifiable. The CMake dependency is
already available where Qt is available.
Depending on CMake would also mean that I could use configure_file() and
file(WRITE ...), which would make the stuff work across platforms already
(currently it depends on sed being available). So I would be able to clean up
the branch considerably.
Additionally, it would be easier to create a similar Config.cmake file for Qt
libraries outside of qtbase.git (such as QtWebKit) as I could simply install
the Qt5BasicConfig.cmake from qtbase and use it from the other repos.
I would make this dependency on CMake non-optional because it is important to
be able to use find_package(Qt5) without having to care about whether the
person who built it had cmake installed at the time. find_package(Qt5) needs
to work for each Qt5 build, so the config files need to be all the time.
Let me know if this is acceptable for Qt.
Thanks,
--
Stephen Kelly | Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Alternative Config.cmake format (was: Installing Qt5Config.cmake from the Qt repo?)
On 10/31/2011 5:20 PM, Alexander Neundorf wrote: Not sure what the other cmake developers would think about supporting an additional file format for the Config.cmake files, e.g. xml or json, so they could be easily used and generated also by other tools. I.e. not only by/for cmake, but basically a standard format for installed libraries to provide information about themselves. Something like: QtCore debug;release /usr/lib/libQtCore.so /usr/include/QtCore ... I've thought about that a few times. This kind of format is hard to define generally without lots of use cases. I suggest that you design a prototype for such a format that is sufficient for Qt's needs. Write a Qt5Config.cmake that comes with Qt5 and *parses* the Qt5Config.xml file itself and sets the proper variables as CMake code expects. Then you can tweak and refine it without being delayed by CMake's release schedule since the parser comes with the format. After it has matured and perhaps a few other projects have picked it up we can consider adding first-class support for it in CMake. -Brad -- 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] Alternative Config.cmake format (was: Installing Qt5Config.cmake from the Qt repo?)
On Tuesday 01 November 2011, Brad King wrote: > On 10/31/2011 5:20 PM, Alexander Neundorf wrote: > > Not sure what the other cmake developers would think about supporting an > > additional file format for the Config.cmake files, e.g. xml or json, so > > they could be easily used and generated also by other tools. I.e. not > > only by/for cmake, but basically a standard format for installed > > libraries to provide information about themselves. > > > > Something like: > > > > > > > > > > QtCore > > debug;release > > /usr/lib/libQtCore.so > > /usr/include/QtCore > > ... > > > > > > > > > > I've thought about that a few times. This kind of format is hard to define > generally without lots of use cases. I suggest that you design a prototype > for such a format that is sufficient for Qt's needs. Write a > Qt5Config.cmake that comes with Qt5 and *parses* the Qt5Config.xml file > itself and sets the proper variables as CMake code expects. Then you can > tweak and refine it without being delayed by CMake's release schedule > since the parser comes with the format. After it has matured and perhaps > a few other projects have picked it up we can consider adding first-class > support for it in CMake. Hmm, ok. Would you prefer XML, JSON or something else ? When you write "Qt5Config.cmake that comes with Qt5 and *parses* the Qt5Config.xml file itself" do you mean to file(READ ...) then xml file in the Config.cmake file and then do a lot of regexp matching on the xml, or do you have a better idea ? Alex -- 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] Alternative Config.cmake format
On 11/1/2011 1:20 PM, Alexander Neundorf wrote: Would you prefer XML, JSON or something else ? I have no preference. If the format is simple enough to parse in CMake code then it can't be too hard to parse with a C++ implementation later ;) However, note that you're trying to set a precedent for a cross-platform replacement of pkg-config .pc files. That may have implications on the format choice. When you write "Qt5Config.cmake that comes with Qt5 and *parses* the Qt5Config.xml file itself" do you mean to file(READ ...) then xml file in the Config.cmake file and then do a lot of regexp matching on the xml, or do you have a better idea ? Yes, I meant that the Qt5Config.cmake file should do the parsing. You can use file(STRINGS) to load the input file as a list of lines suitable for use with foreach()'s "IN LISTS" mode. Note that CMake's list processing doesn't like "[]" in the values due to backward compatibility with registry value syntax, so JSON may be tricky if you use this approach. -Brad -- 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
[cmake-developers] [PATCH] Fixes to ExternalProject and it's tests
These two patches address some issues I found:
-ExternalProject_Add(... DEPENDS something) does not work if that something is
not itself created by ExternalProject_Add(). Fixed and testcase added.
-The testcases for ExternalProject fail to detect on my German system my
Subversion version. We had the issue back in the FindSubversion.cmake some
time again and fixed it there, no need to duplicate the old wrong code here.
The patches are independent of each other.
Greetings,
Eike>From e9e8a581a9c9384beac2390cc867de40e44fc00f Mon Sep 17 00:00:00 2001
From: Rolf Eike Beer
Date: Tue, 1 Nov 2011 18:38:52 +0100
Subject: [PATCH] fix Subversion detection in ExternalProject tests
This test will fail to get a proper version number if running on a (e.g.
German) localized system because the regular expression used to match the
Subversion version output does not match. Instead of duplicating code just
remove the local test altogether and use the version that FindSubversion.cmake
already detects.
---
Tests/ExternalProject/CMakeLists.txt |7 ---
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/Tests/ExternalProject/CMakeLists.txt b/Tests/ExternalProject/CMakeLists.txt
index 4a542d7..ac70129 100644
--- a/Tests/ExternalProject/CMakeLists.txt
+++ b/Tests/ExternalProject/CMakeLists.txt
@@ -343,13 +343,6 @@ endif()
# Only do svn tests with svn >= version 1.2
#
if(do_svn_tests)
- execute_process(COMMAND ${Subversion_SVN_EXECUTABLE} --version
-OUTPUT_VARIABLE Subversion_VERSION_SVN
-OUTPUT_STRIP_TRAILING_WHITESPACE)
- string(REGEX REPLACE "^(.*\n)?svn, version ([.0-9]+).*"
-"\\2" Subversion_VERSION_SVN "${Subversion_VERSION_SVN}")
- message(STATUS "Subversion_VERSION_SVN='${Subversion_VERSION_SVN}'")
-
if(Subversion_VERSION_SVN VERSION_LESS 1.2)
message(STATUS "No ExternalProject svn tests with svn client less than version 1.2")
set(do_svn_tests 0)
--
1.7.3.2
>From 84e6a1774d07baf45c5784f8e2d37cc4f9c4468b Mon Sep 17 00:00:00 2001
From: Rolf Eike Beer
Date: Tue, 01 Nov 2011 18:21:14 +0200
Subject: [PATCH] ExternalProject: make DEPENDS work with "normal" targets
ExternalProject_Add currently expects it's dependencies to have the property
_EP_STAMP_DIR set which is only true for other targets created by
ExternalProject_Add. Now it is first checked if that property is actually
present and is only taken as generated by ExternalProject if it does.
---
Modules/ExternalProject.cmake|8 +++-
Tests/ExternalProject/CMakeLists.txt | 17 +
2 files changed, 24 insertions(+), 1 deletions(-)
diff --git a/Modules/ExternalProject.cmake b/Modules/ExternalProject.cmake
index a37771b..0af6cf9 100644
--- a/Modules/ExternalProject.cmake
+++ b/Modules/ExternalProject.cmake
@@ -1275,8 +1275,14 @@ function(_ep_add_configure_command name)
set(file_deps)
get_property(deps TARGET ${name} PROPERTY _EP_DEPENDS)
foreach(dep IN LISTS deps)
+# Find out if this dependency is itself an external target or not.
+# If it doesn't have _EP_STAMP_DIR we assume it's a normal target.
get_property(dep_stamp_dir TARGET ${dep} PROPERTY _EP_STAMP_DIR)
-list(APPEND file_deps ${dep_stamp_dir}${cfgdir}/${dep}-done)
+if(dep_stamp_dir)
+ list(APPEND file_deps ${dep_stamp_dir}${cfgdir}/${dep}-done)
+else(dep_stamp_dir)
+ list(APPEND file_deps ${dep})
+endif(dep_stamp_dir)
endforeach()
get_property(cmd_set TARGET ${name} PROPERTY _EP_CONFIGURE_COMMAND SET)
diff --git a/Tests/ExternalProject/CMakeLists.txt b/Tests/ExternalProject/CMakeLists.txt
index 4a542d7..19f91a1 100644
--- a/Tests/ExternalProject/CMakeLists.txt
+++ b/Tests/ExternalProject/CMakeLists.txt
@@ -111,6 +111,23 @@ ExternalProject_Add(${proj}
)
set_property(TARGET ${proj} PROPERTY FOLDER "")
+add_custom_target(EmptyTarget)
+
+set(proj DependsOnTarget)
+ExternalProject_Add(${proj}
+ BUILD_COMMAND ""
+ CMAKE_ARGS ""
+ CONFIGURE_COMMAND ""
+ DEPENDS "EmptyTarget"
+ DOWNLOAD_COMMAND ""
+ INSTALL_COMMAND ""
+ PATCH_COMMAND ""
+ STEP_TARGETS install
+ URL ""
+ URL_MD5 ""
+)
+set_property(TARGET ${proj} PROPERTY FOLDER "")
+
# Local DIR:
#
--
1.7.3.2
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Alternative Config.cmake format
On Tuesday 01 November 2011, Brad King wrote: > On 11/1/2011 1:20 PM, Alexander Neundorf wrote: > > Would you prefer XML, JSON or something else ? > > I have no preference. If the format is simple enough to parse in CMake > code then it can't be too hard to parse with a C++ implementation later ;) > > However, note that you're trying to set a precedent for a cross-platform > replacement of pkg-config .pc files. That may have implications on the > format choice. Yes, I'm aware of that. > > When you write "Qt5Config.cmake that comes with Qt5 and *parses* the > > Qt5Config.xml file itself" do you mean to file(READ ...) then xml file in > > the Config.cmake file and then do a lot of regexp matching on the xml, > > or do you have a better idea ? > > Yes, I meant that the Qt5Config.cmake file should do the parsing. You > can use file(STRINGS) to load the input file as a list of lines suitable > for use with foreach()'s "IN LISTS" mode. Ok. Alex -- 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
[cmake-developers] [CMake 0012550]: frameworks with spaces breaks cmake
The following issue has been SUBMITTED.
==
http://cmake.org/Bug/view.php?id=12550
==
Reported By:Aaron Simmons
Assigned To:
==
Project:CMake
Issue ID: 12550
Category: CMake
Reproducibility:always
Severity: major
Priority: high
Status: new
==
Date Submitted: 2011-11-01 17:22 EDT
Last Modified: 2011-11-01 17:22 EDT
==
Summary:frameworks with spaces breaks cmake
Description:
Trying to use target_link_libraries with a framework that contains spaces (such
as the "Adobe AIR.framework" in the AIR SDK) doesn't work.
Steps to Reproduce:
>From an unanswered email on the cmake forums
http://www.mail-archive.com/cmake@cmake.org/msg38710.html:
I'm having trouble linking my OS X application to a specific framework using
CMake without explicitly setting linker flags (somewhat defeating the
purpose of using CMake for cross-platform building). Say I have a framework
called "My Framework.framework". CMake successfully finds the framework
when I run:
find_library(MY_LIB \"My\ Framework\")
Then I link to my target with:
target_link_libraries(MyTarget ${MY_LIB})
The resulting linker flag is:
-Framework My Framework
This of course is incorrect and will cause gcc to try to link to "My" and
"Framework separately.
The solution is to write the linker flags myself, as follows:
set(CMAKE_EXE_LINKER_FLAGS -framework\ \"My\ Framework\")
Is there a better way?
BTW, I tried to fix up the name by replacing " " with "\ " i.e.
string(REPLACE " " "\\ " MY_LIB_FIX ${MY_LIB})
Such that MY_LIB_FIX is /Library/Frameworks/My\ Framework.framework. But to
my dismay, CMake interprets this format differently and produces a warning
that says "[the path] is a full-path but not a valid library file name."
The the resulting linker flag is -l rather than the required -framework.
==
Issue History
Date ModifiedUsername FieldChange
==
2011-11-01 17:22 Aaron Simmons 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
