Re: [cmake-developers] What to do with the RESOLVED issues ?
On Tuesday 28 September 2010, David Cole wrote: When I fix a bug, I mark it as resolved. I expect that somebody else who cares about the bug will come along behind me and double-check me on it. So... I leave it to the reporter or some other interested party to close it. If there is consensus that this approach is undesirable, I'd be happy to just close them instead of resolving them. Why does it matter, as long as they are not open anymore? For instance they still appear in the Reported by me and Monitored by me sections, so they don't feel like really done. Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Creating cdash subprojects: create_cdash_subprojects()
On Tuesday 28 September 2010, David Cole wrote: Ambitious. I like it. I would prefer seeing this implemented as a CMake-language function. And You mean to implement this as a cmake script, and not as a built-in function ? adding anything necessary to CMake in order to support implementing it in the CMake language. (Because I think that adding such support would also enable a slew of other unthought-of-as-yet functionality that will prove extremely useful...) However, if that's not possible, or not your cup of tea, I would not fight against including a native command to implement this functionality. One problem I foresee with this right from the get-go is that it is very complex and will be difficult to test well. And possibly difficult to figure out what's gone wrong when something does go wrong. You have time to prototype this in the CMake language and tell us what new functionality we'd need to support it there? (I can tell we'll need commands to iterate projects and targets... any others needed?) I think just a way to get a list of projects and of targets in a project wouldn't be enough. I would need * get the list of projects (easy) * I must be able to check whether project A is contained in project B * I need the targets per project (easy) * I need to figure out the dependencies between the projects/the contained targets. I'm not sure I want to do that in cmake script. or I need a way to get the projects a project depends on (or the targets a project depends on and then figure out in cmake-script to which projects these targets belong :-/) My feeling is that figuring out the dependencies should be done in C++. Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake] CMake 2.8.3-rc1 ready for testing!
On 09/28/2010 02:38 PM, Alexander Neundorf wrote: But it will always fail when a new version of cmake comes with a new version of Foo.cmake which it uses itself, and relies on the new features. If cmake then gets the older tweaked version from the project we have the problem. Okay, so modules must always include their dependencies from known locations. If an outside project wants to override a Find module it should also copy the dependencies too. hammer:~/src/CMake/CMake-git/Modules$ grep FindPackageHandleSt *cmake |wc -l 86 IMO this would justify that new variable. (actually I wondered quite a few times since using cmake why such a CURRENT_LIST_FILE_DIR variable is missing, using GFC() always feels like using a clever trick instead of doing the straightforward thing). Okay. Your patch looks good. -Brad ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] What to do with the RESOLVED issues ?
On Tue, Sep 28, 2010 at 12:26 PM, Bill Hoffman bill.hoff...@kitware.comwrote: On 9/28/2010 2:18 PM, Alexander Neundorf wrote: On Tuesday 28 September 2010, David Cole wrote: When I fix a bug, I mark it as resolved. I expect that somebody else who cares about the bug will come along behind me and double-check me on it. So... I leave it to the reporter or some other interested party to close it. If there is consensus that this approach is undesirable, I'd be happy to just close them instead of resolving them. Why does it matter, as long as they are not open anymore? For instance they still appear in the Reported by me and Monitored by me sections, so they don't feel like really done. I would say close them as soon as you can. If people want to reopen them, they can. But, I don't think we should wait for someone to close them. So, anyone wants to move the resolved issues to closed, I am all for it. :) -Bill I feel a bug shouldn't be closed until the fix can be found in a CMake release. The bug should also make it clear which release the fix should be found in. Pushing the fix to next doesn't qualify as being closed, because I can't expect my customers to grab a nightly. James ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake] CMake 2.8.3-rc1 ready for testing!
On Tuesday 28 September 2010, Brad King wrote:
On 09/28/2010 03:24 PM, Alexander Neundorf wrote:
Currently there are CMAKE_CURRENT_LIST_FILE and CMAKE_CURRENT_LIST_LINE.
Should it be CMAKE_CURRENT_LIST_FILE_DIR or CMAKE_CURRENT_LIST_DIR ?
Let's use the latter, CMAKE_CURRENT_LIST_DIR.
-Brad
There should be a AddCMAKE_CURRENT_LIST_DIR branch now on the stage.
Works, but still it doesn't feel good.
This means that whenever doing a
include(FPHSA)
in one of cmakes find-modules it must actually be a
include(${CMAKE_CURRENT_LIST_DIR}/FPHSA.cmake)
Similar issues can come up with other files and in other projects.
In the end this would mean that in cmake basically all include()s would have
to use the full path :-/
Another thing is, a few days ago I added an include guard to KDE's version of
FPHSA.cmake, since it is included several times and it's quite long, so it
should save some time:
--- trunk/KDE/kdelibs/cmake/modules/FindPackageHandleStandardArgs.cmake
#1179966:1179967
@@ -67,6 +67,12 @@
# (To distribute this file outside of CMake, substitute the full
# License text for the above reference.)
+# Include guard, it's not necessary to parse this fail again and again:
+IF(_FPHSA_ALREADY_INCLUDED)
+ RETURN()
+ENDIF(_FPHSA_ALREADY_INCLUDED)
+SET(_FPHSA_ALREADY_INCLUDED TRUE)
+
INCLUDE(FindPackageMessage)
INCLUDE(CMakeParseArguments)
(this is not yet in any release).
Thinking a bit about this, this has currently the following effect:
find_package(SomeKDEModule) - loads KDE/FPHSA.cmake
find_package(SomeCMakeModule) - loads CMake/FPHSA.cmake
find_package(SomeOtherModule) - doesn't reload KDE/FPHSA.cmake due to
the include guard - ok here, but might
potentially also cause issues
So, avoid include guards completely ?
Or make them more intelligent ?
Like
IF(${_FPHSA_ALREADY_INCLUDED} STREQUAL ${CMAKE_CURRENT_LIST_FILE})
RETURN()
ENDIF()
SET(_FPHSA_ALREADY_INCLUDED ${CMAKE_CURRENT_LIST_FILE} )
?
Still this requires that both versions would have to follow this include-guard
style.
Another option would be that I check in KDE/FPHSA.cmake CMAKE_PARENT_LIST_FILE
to see whether KDE/FPHSA.cmake is included from a module in cmake or in KDE,
and if it's in CMake, forward that explicitely to CMake/FPHSA.cmake.
Unfortunately this doesn't seem work.
I just added the following to the top of my local FPHSA.cmake:
message(STATUS parent: ${CMAKE_PARENT_LIST_FILE})
message(STATUS current: ${CMAKE_CURRENT_LIST_FILE})
with the following in my CMakeLists.txt:
set(CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR})
find_package(DBusMenuQt)
find_package(ZLIB)
and hoped to see that I'm once include from
${CMAKE_SOURCE_DIR}/FindDBusMenuQt.cmake, and in the 2nd case from
${CMAKE_ROOT}/Modules/FindZLIB.cmake.
But instead CMAKE_PARENT_LIST_FILE was always the CMakeLists.txt:
-- parent: /home/alex/src/tests/cmake-fphsa/CMakeLists.txt
--
current: /home/alex/src/tests/cmake-fphsa/FindPackageHandleStandardArgs.cmake
-- parent: /home/alex/src/tests/cmake-fphsa/CMakeLists.txt
--
current: /home/alex/src/tests/cmake-fphsa/FindPackageHandleStandardArgs.cmake
Is this intended this way ?
Checking CMAKE_PARENT_LIST_FILE from inside the macro works OTOH, then I
get /home/alex/src/tests/cmake-fphsa/FindDBusMenuQt.cmake
and /opt/cmake-HEAD/share/cmake-2.9/Modules/FindZLIB.cmake respectively for
CMAKE_CURRENT_LIST_FILE.
Alex
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake] CMake 2.8.3-rc1 ready for testing!
On Tuesday 28 September 2010, Alexander Neundorf wrote:
...
Another option would be that I check in KDE/FPHSA.cmake
CMAKE_PARENT_LIST_FILE to see whether KDE/FPHSA.cmake is included from a
module in cmake or in KDE, and if it's in CMake, forward that explicitely
to CMake/FPHSA.cmake. Unfortunately this doesn't seem work.
I just added the following to the top of my local FPHSA.cmake:
message(STATUS parent: ${CMAKE_PARENT_LIST_FILE})
message(STATUS current: ${CMAKE_CURRENT_LIST_FILE})
with the following in my CMakeLists.txt:
set(CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR})
find_package(DBusMenuQt)
find_package(ZLIB)
and hoped to see that I'm once include from
${CMAKE_SOURCE_DIR}/FindDBusMenuQt.cmake, and in the 2nd case from
${CMAKE_ROOT}/Modules/FindZLIB.cmake.
But instead CMAKE_PARENT_LIST_FILE was always the CMakeLists.txt:
-- parent: /home/alex/src/tests/cmake-fphsa/CMakeLists.txt
--
current:
/home/alex/src/tests/cmake-fphsa/FindPackageHandleStandardArgs.cmake --
parent: /home/alex/src/tests/cmake-fphsa/CMakeLists.txt
Is this intended this way ?
The attached tiny patch seems to make CMAKE_PARENT_LIST_FILE work more like I
expected.
Alex
diff --git a/Source/cmMakefile.cxx b/Source/cmMakefile.cxx
index e32619a..e7138b1 100644
--- a/Source/cmMakefile.cxx
+++ b/Source/cmMakefile.cxx
@@ -569,7 +569,7 @@ bool cmMakefile::ReadListFile(const char* filename_in,
= this-GetSafeDefinition(CMAKE_PARENT_LIST_FILE);
std::string currentFile
= this-GetSafeDefinition(CMAKE_CURRENT_LIST_FILE);
- this-AddDefinition(CMAKE_PARENT_LIST_FILE, filename_in);
+ this-AddDefinition(CMAKE_PARENT_LIST_FILE, currentFile.c_str());
const char* external = 0;
std::string external_abs;
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake] CMake 2.8.3-rc1 ready for testing!
On 09/28/2010 05:03 PM, Alexander Neundorf wrote:
Works, but still it doesn't feel good.
This means that whenever doing a
include(FPHSA)
in one of cmakes find-modules it must actually be a
include(${CMAKE_CURRENT_LIST_DIR}/FPHSA.cmake)
Similar issues can come up with other files and in other projects.
In the end this would mean that in cmake basically all include()s would have
to use the full path :-/
Yes, and overriding any one module in CMake would mean copying it
out and everything that depends on it. Still, this particular
case is a very short dependency chain.
Another thing is, a few days ago I added an include guard to KDE's version of
FPHSA.cmake, since it is included several times and it's quite long, so it
should save some time:
...but as you discovered doesn't work unless there is exactly one
version of the file. Just leave out the guards. Correctness is
more important than speed. We need each module that loads the
macro to get the one it wants.
-Brad
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake] CMake 2.8.3-rc1 ready for testing!
On 09/28/2010 05:20 PM, Alexander Neundorf wrote: On Tuesday 28 September 2010, Alexander Neundorf wrote: Is this intended this way ? The attached tiny patch seems to make CMAKE_PARENT_LIST_FILE work more like I expected. Yes, but who knows what it will break. I'm not prepared to do this during a release candidate series. -Brad ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] What to do with the RESOLVED issues ?
On 9/28/2010 4:53 PM, James Bigler wrote: I feel a bug shouldn't be closed until the fix can be found in a CMake release. The bug should also make it clear which release the fix should be found in. Pushing the fix to next doesn't qualify as being closed, because I can't expect my customers to grab a nightly. I just don't think we have the bandwidth or follow up capability to do that. If it makes it into next, then it will make it into a release, and show up in the release notes from the commit log. BTW, please make your commit messages look like the line that goes in the release notes. :) The bug tracker is so full of stuff, we need to get that stuff out as soon as possible. -Bill ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] User vs CMake include mismatch handling [was CMake 2.8.3-rc1 ready for testing!]
Changing subject in order to re-classify the discussion. 2010/9/28 Brad King brad.k...@kitware.com: On 09/28/2010 05:20 PM, Alexander Neundorf wrote: On Tuesday 28 September 2010, Alexander Neundorf wrote: Is this intended this way ? The attached tiny patch seems to make CMAKE_PARENT_LIST_FILE work more like I expected. Yes, but who knows what it will break. I'm not prepared to do this during a release candidate series. Totally agree with that. Moreover I currently lack time for doing fine comments but I think that WE MUST not enforce compatibilities between include cmake files in order to ensure/enforce consistency between CMake provided files and user provided files. I personally thinks that the current behavior which is to let CMake pick-up the first matching file from CMAKE_MODULE_PATH is the best one. Now if ever a project is forking one or several may-become-incompatible version of CMake provided file(s) then the solution shouldn't be to burry some absolute path inside CMake provided files. Being able to patch a particular CMake provided include file is a feature I want to keep: - because user may not be able to wait a new CMake release to get his problem solved - because it's perfectly fine to tune/tweak CMake provided behavior from within a project My point of view is that this is the project responsible of this kind of breakage that should find a fix. For example if the KDE FPHSA was introduced by KDE then KDE project should refer (if needed) to the KDE provided FPHSA using full path (and not require CMake to do so). As Alex saif before: I don't think it's a good idea. People may purposely want to override CMake provided module in order to implement specific behavior and/or to patch locally. This is what we do in KDE, and I think it would be good for us. Using include(FPHSA CURRENT_DIR) in the files in cmake would mean that the find-modules in cmake also get the FPHSA they expect to get, and if we would use that in KDE too, we would be sure we would get our modified version. Again, my opinion is: KDE may ask to explicitely load its own FPHSA but shall not require the CMake provided modules to explicitely load the CMake provided one. May be an ORIGIN property may be automatically added to a MACRO in order to be able to check whether the macros comes from CMake or from a User provided file. Then you may implement your guard using: if (COMMAND FIND_PACKAGE_HANDLE_STANDARD_ARGS) get_property(FPHSA_ORIGIN COMMAND PROPERTY ORIGIN) if (FPHSA_ORIGIN STREQUAL CMake) include(/absolute/path/to/my/FPHSA) endif(FPHSA_ORIGIN STREQUAL CMake) endif(COMMAND FIND_PACKAGE_HANDLE_STANDARD_ARGS) the ORIGIN property may be set automatically by CMake (to User or CMake) when loading a cmake file. using this kind of trick the guard may be more intelligent and check what to do depending on CMAKE_xxx_VERSION. I know that this is NOT solving the current KDE problem but as stated before may be if we fix the KDE problem by enforcing absolute path include within CMake some other projects will break in another way? -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] What to do with the RESOLVED issues ?
On Tue, Sep 28, 2010 at 4:04 PM, Bill Hoffman bill.hoff...@kitware.comwrote: On 9/28/2010 4:53 PM, James Bigler wrote: I feel a bug shouldn't be closed until the fix can be found in a CMake release. The bug should also make it clear which release the fix should be found in. Pushing the fix to next doesn't qualify as being closed, because I can't expect my customers to grab a nightly. I just don't think we have the bandwidth or follow up capability to do that. If it makes it into next, then it will make it into a release, and show up in the release notes from the commit log. BTW, please make your commit messages look like the line that goes in the release notes. :) The bug tracker is so full of stuff, we need to get that stuff out as soon as possible. -Bill Fair enough. ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
