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
[CMake] How to list user-definable CMake variables
Hi all, I was wondering how I could generate a list of user-definable CMake variables. This list, with a brief help per variable, would be *very* useful for the end-user. It's a bit like the well-known configure --help which gives you a overview of all variables that can be set. Best regards, Marcel Loose. ___ 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] How to list user-definable CMake variables
On 28. Sep, 2010, at 9:33 , Marcel Loose wrote: Hi all, I was wondering how I could generate a list of user-definable CMake variables. This list, with a brief help per variable, would be *very* useful for the end-user. It's a bit like the well-known configure --help which gives you a overview of all variables that can be set. Best regards, Marcel Loose. Is cmake -LAH what you want? Michael -- There is always a well-known solution to every human problem -- neat, plausible, and wrong. H. L. Mencken PGP.sig 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] How to list user-definable CMake variables
On 28. Sep, 2010, at 9:33 , Marcel Loose wrote: Hi all, I was wondering how I could generate a list of user-definable CMake variables. This list, with a brief help per variable, would be *very* useful for the end-user. It's a bit like the well-known configure --help which gives you a overview of all variables that can be set. Best regards, Marcel Loose. Is cmake -LAH what you want? Michael Hi Michael, Well this is sort of what I was looking for, though I was hoping that it would be possible to list any useful variable *before* running CMake. Is there some kind of hook, e.g. 'cmake --custom-help', that can be used to display project-specific help. The help text should be provided by the developer, of course. Best regards, Marcel Loose. ___ 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] How to list user-definable CMake variables
2010/9/28 Marcel Loose lo...@astron.nl:
On 28. Sep, 2010, at 9:33 , Marcel Loose wrote:
Hi all,
I was wondering how I could generate a list of user-definable CMake
variables. This list, with a brief help per variable, would be
*very*
useful for the end-user. It's a bit like the well-known configure
--help which gives you a overview of all variables that can be set.
Best regards,
Marcel Loose.
Is cmake -LAH what you want?
Michael
Hi Michael,
Well this is sort of what I was looking for, though I was hoping that it
would be possible to list any useful variable *before* running CMake.
Before running cmake... I don't know but keep reading.
Is there some kind of hook, e.g. 'cmake --custom-help', that can be used
to display project-specific help. The help text should be provided by
the developer, of course.
You may do the following:
Write an HelpMe.cmake file which contains CMake comments
just like plain CMake do (see e.g. CPackRPM.cmake which contains many
variable descriptions)
then add the following custom target to your project:
add_custom_target(HelpMe
COMMAND ${CMAKE_COMMAND}
-DCMAKE_MODULE_PATH=${CMAKE_CURRENT_SOURCE_DIR} --help-module HelpMe
COMMENT Display User defined help)
this will use the --help-module option of cmake to display your custom help.
user can call the target
make HelpMe
and the help will be display.
You may want to call your target help but it would conflict/override
the cmake builtin help target
(at least for makefile generator) which display the list of available target.
This work AFTER cmake has been run. It could be run before as well using:
cmake -DCMAKE_MODULE_PATH=/path/to/source --help-module HelpMe
but this is awkward :-(
--
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to list user-definable CMake variables
On 28. Sep, 2010, at 10:12 , Marcel Loose wrote: On 28. Sep, 2010, at 9:33 , Marcel Loose wrote: Hi all, I was wondering how I could generate a list of user-definable CMake variables. This list, with a brief help per variable, would be *very* useful for the end-user. It's a bit like the well-known configure --help which gives you a overview of all variables that can be set. Best regards, Marcel Loose. Is cmake -LAH what you want? Michael Hi Michael, Well this is sort of what I was looking for, though I was hoping that it would be possible to list any useful variable *before* running CMake. Is there some kind of hook, e.g. 'cmake --custom-help', that can be used to display project-specific help. The help text should be provided by the developer, of course. Best regards, Marcel Loose. Not that I'd know of. I also think that this would be quite difficult to implement. You're far better off writing an extensive README or INSTALL document. Michael -- There is always a well-known solution to every human problem -- neat, plausible, and wrong. H. L. Mencken PGP.sig 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] How to list user-definable CMake variables
On Tue, 2010-09-28 at 10:43 +0200, Michael Wild wrote: On 28. Sep, 2010, at 10:12 , Marcel Loose wrote: On 28. Sep, 2010, at 9:33 , Marcel Loose wrote: Hi all, I was wondering how I could generate a list of user-definable CMake variables. This list, with a brief help per variable, would be *very* useful for the end-user. It's a bit like the well-known configure --help which gives you a overview of all variables that can be set. Best regards, Marcel Loose. Is cmake -LAH what you want? Michael Hi Michael, Well this is sort of what I was looking for, though I was hoping that it would be possible to list any useful variable *before* running CMake. Is there some kind of hook, e.g. 'cmake --custom-help', that can be used to display project-specific help. The help text should be provided by the developer, of course. Best regards, Marcel Loose. Not that I'd know of. I also think that this would be quite difficult to implement. You're far better off writing an extensive README or INSTALL document. Michael -- There is always a well-known solution to every human problem -- neat, plausible, and wrong. H. L. Mencken That's a pity. Of course there's nothing against having a good, useful README and/or INSTALL file. But I also like to keep the documentation close to the code. The more documentation and code get separated, the higher the risk that the two diverge. Anyway, thanks for thinking with me. Best regards, Marcel Loose. ___ 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] How to list user-definable CMake variables
On Tue, 2010-09-28 at 10:42 +0200, Eric Noulard wrote:
2010/9/28 Marcel Loose lo...@astron.nl:
On 28. Sep, 2010, at 9:33 , Marcel Loose wrote:
Hi all,
I was wondering how I could generate a list of user-definable
CMake
variables. This list, with a brief help per variable, would be
*very*
useful for the end-user. It's a bit like the well-known
configure
--help which gives you a overview of all variables that can be
set.
Best regards,
Marcel Loose.
Is cmake -LAH what you want?
Michael
Hi Michael,
Well this is sort of what I was looking for, though I was hoping
that it
would be possible to list any useful variable *before* running
CMake.
Before running cmake... I don't know but keep reading.
Is there some kind of hook, e.g. 'cmake --custom-help', that can be
used
to display project-specific help. The help text should be provided
by
the developer, of course.
You may do the following:
Write an HelpMe.cmake file which contains CMake comments
just like plain CMake do (see e.g. CPackRPM.cmake which contains many
variable descriptions)
then add the following custom target to your project:
add_custom_target(HelpMe
COMMAND ${CMAKE_COMMAND}
-DCMAKE_MODULE_PATH=${CMAKE_CURRENT_SOURCE_DIR} --help-module HelpMe
COMMENT Display User defined help)
this will use the --help-module option of cmake to display your
custom help.
user can call the target
make HelpMe
and the help will be display.
You may want to call your target help but it would conflict/override
the cmake builtin help target
(at least for makefile generator) which display the list of available
target.
This work AFTER cmake has been run. It could be run before as well
using:
cmake -DCMAKE_MODULE_PATH=/path/to/source --help-module HelpMe
but this is awkward :-(
Thanks Erk,
I'll give it a thought. Your solution uses some nice CMake features, but
I find it a bit awkward. It suffers from separation of code and
documentation, though. That's always risky, since the two are likely to
diverge.
Best regards,
Marcel Loose.
___
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] How to list user-definable CMake variables
On 28. Sep, 2010, at 11:03 , Marcel Loose wrote: On Tue, 2010-09-28 at 10:43 +0200, Michael Wild wrote: On 28. Sep, 2010, at 10:12 , Marcel Loose wrote: On 28. Sep, 2010, at 9:33 , Marcel Loose wrote: Hi all, I was wondering how I could generate a list of user-definable CMake variables. This list, with a brief help per variable, would be *very* useful for the end-user. It's a bit like the well-known configure --help which gives you a overview of all variables that can be set. Best regards, Marcel Loose. Is cmake -LAH what you want? Michael Hi Michael, Well this is sort of what I was looking for, though I was hoping that it would be possible to list any useful variable *before* running CMake. Is there some kind of hook, e.g. 'cmake --custom-help', that can be used to display project-specific help. The help text should be provided by the developer, of course. Best regards, Marcel Loose. Not that I'd know of. I also think that this would be quite difficult to implement. You're far better off writing an extensive README or INSTALL document. Michael -- There is always a well-known solution to every human problem -- neat, plausible, and wrong. H. L. Mencken That's a pity. Of course there's nothing against having a good, useful README and/or INSTALL file. But I also like to keep the documentation close to the code. The more documentation and code get separated, the higher the risk that the two diverge. Anyway, thanks for thinking with me. Best regards, Marcel Loose. Of course, it would be ideal if CMake had a way of spewing out all the documentation strings of all the cache variables, but IMHO this is nigh impossible, e.g. what do you do with conditionally set cache variables? If you treat them as being unconditional, you might accidentally offer too many options which don't have any effect (perhaps it's a conditional on WIN32 or similar), or you might have conflicts (e.g. different doc strings and default values for WIN32 and UNIX). Michael -- There is always a well-known solution to every human problem -- neat, plausible, and wrong. H. L. Mencken PGP.sig 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] How to list user-definable CMake variables
2010/9/28 Marcel Loose lo...@astron.nl: You may want to call your target help but it would conflict/override the cmake builtin help target (at least for makefile generator) which display the list of available target. This work AFTER cmake has been run. It could be run before as well using: cmake -DCMAKE_MODULE_PATH=/path/to/source --help-module HelpMe but this is awkward :-( Thanks Erk, I'll give it a thought. Your solution uses some nice CMake features, but I find it a bit awkward. It suffers from separation of code and documentation, though. That's always risky, since the two are likely to diverge. It is a little bit, but you can put in this custom cmake file (you may rename it to CustomizableOptions.cmake) any CMake *code* you want including the definition of OPTION or vars (using SET) etc... then in you CMakeLists.txt you can include(CustomizableOptions.cmake) and the header of the file contains the useful doc. for the concerned option/vars. then the code and it's doc stay together. -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Visual Studio 2010 generator broke? Yes, but not how I thought
Why do you think this is incorrect?
Either $(Configuration) or $(IntDir) should be acceptable locations for obj
files...
On Sun, Sep 26, 2010 at 11:40 AM, J Decker d3c...@gmail.com wrote:
this is the sample cmakelists that causes bad output...
--
cmake_minimum_required(VERSION 2.8)
project( launchpad )
set(BASE_SOURCES launchpad.c launchpad.rc )
add_executable(${PROJECT_NAME} WIN32 ${BASE_SOURCES} )
-
the 'Output File Name' property in visual studio is ...
ObjectFileName$(Configuration)/launchpad.c.obj/ObjectFileName
Normally this is just $(IntDir)
but some reason because I have a resource and a source file the same
name the output file is different?
and even if it was... it should still be $(IntDir)/launchpad.c.obj (
I guess so I can have launchpad.c.obj and launchpad.cpp.obj and
launchpad.rc.obj ?)
Also if I have another project like...
-
project( launchpad2 )
set(BASE_SOURCES launchpad.c ) # no resources
add_executable(${PROJECT_NAME} WIN32 ${BASE_SOURCES} )
-
the output file of this also becomes $((Configuration)/launchpad.c.obj
___
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] Environment Variable - /var
Hi, Is there such an environment variable, like in case autoconf: --localstatedir=DIR modifiable single-machine data [PREFIX/var] There are options like CMAKE_INSTALL_PREFIX, SYSCONF_INSTALL_DIR, but not this one. I can make an own one, I am just out of the curiosity whether there is an internal solution. Best Regards, Laszlo Papp ___ 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] Problem with Intel Fortran and the Visual Studio 2008 generator
Hello, for the PLplot project (http://plplot.sf.net) I have tried to use the Visual Studio 2008 generator in combination with Intel Fortran (version 11.1). Generating the solution and the project files works fine, but when I try to build it all, I get error messages about various symbols being doubly defined (in libcmt.lib - __aenvptr, __wenvptr, ___error_mode and ___app_type) and also a missing symbol in libifcoremt.lib (_MAIN__). These are system libraries that get included automatically during the link step. If I use the NMake Makefiles generator, however, all goes well. In both cases I use CMake 2.8 and I use only default options. I always generate the solution/project files/makefiles in an empty directory. Any suggestions as to a solution? Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. ___ 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] Visual Studio 2010 generator broke? Yes, but not how I thought
On 9/28/2010 5:43 AM, David Cole wrote: Why do you think this is incorrect? Either $(Configuration) or $(IntDir) should be acceptable locations for obj files... This was a bug, Brad checked in the fix into next. -Bill ___ 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] Build library with specific compil flags for a few files
Hello everybody, I have a library for which almost all the files should be compiled (e.g. g95) with the same compilation flags (that I will call later flag_debug, flag_release ...) excepted a few ones for which I have to use slightly different compilation flags (called later flag1_debug, flag1_release ...). As in both cases the flags are different from the default ones, I was told on the cmake list to create a personal Compiler/G95-Fortran.cmake file that was placed in my Src directory and that contains the following lines: set(CMAKE_Fortran_FLAGS_INIT ) set(CMAKE_Fortran_FLAGS_DEBUG_INIT flag_debug) set(CMAKE_Fortran_FLAGS_RELEASE_INIT flag_release) set(CMAKE_Fortran_MODDIR_FLAG -fmod=) set(CMAKE_Fortran_VERBOSE_FLAG -v) This file allowing to avoid the declaration of the flags in the CMakeLists.txt file. But, how to proceed for the few files for which I have to use different compiler flags ? In that case, I do not see any way to escape from writing specifically the flags in the CMakeLists.txt file with command such as: if(CMAKE_BUILD_TYPE STREQUAL RELEASE) set_source_files_properties(File1 PROPERTIES COMPILE_FLAGS flag1_release) set_source_files_properties(File2 PROPERTIES COMPILE_FLAGS flag1_release) ... elseif(CMAKE_BUILD_TYPE STREQUAL DEBUG) set_source_files_properties(File1 PROPERTIES COMPILE_FLAGS flag1_debug) set_source_files_properties(File2 PROPERTIES COMPILE_FLAGS flag1_debug) ... ... endif() would you have any idea about how to esacpe from this kind of implementation ? is that so ugly ? thanks Eric -- Eric Pellegrini Calcul Scientifique Insitut Laue-Langevin Grenoble, France ___ 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] Problem with Intel Fortran and the Visual Studio 2008 generator
On 9/28/2010 6:35 AM, Arjen Markus wrote: for the PLplot project (http://plplot.sf.net) I have tried to use the Visual Studio 2008 generator in combination with Intel Fortran (version 11.1). Generating the solution and the project files works fine, but when I try to build it all, I get error messages about various symbols being doubly defined (in libcmt.lib - __aenvptr, __wenvptr, ___error_mode and ___app_type) and also a missing symbol in libifcoremt.lib (_MAIN__). These are system libraries that get included automatically during the link step. If I use the NMake Makefiles generator, however, all goes well. I can reproduce this with VS 2008 and Intel 11.1 in 32-bit mode: LIBCMT.lib(dllcrt0.obj) : error LNK2005: __aenvptr already defined in LIBCMT.lib(crt0.obj) LIBCMT.lib(dllcrt0.obj) : error LNK2005: __wenvptr already defined in LIBCMT.lib(crt0.obj) LIBCMT.lib(dllcrt0.obj) : error LNK2005: ___error_mode already defined in LIBCMT.lib(crt0.obj) LIBCMT.lib(dllcrt0.obj) : error LNK2005: ___app_type already defined in LIBCMT.lib(crt0.obj) Note that one comes from dllcrt0.obj and the other from crt0.obj. The build is mixing static and shared runtime libraries. It looks like the Platform/Windows-ifort.cmake module is not getting loaded for this generator. This is due to a dumb bug in the language information files. I've pushed out a fix: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=20f49730 -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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Build library with specific compil flags for a few files
On 28. Sep, 2010, at 16:08 , pellegrini wrote: Hello everybody, I have a library for which almost all the files should be compiled (e.g. g95) with the same compilation flags (that I will call later flag_debug, flag_release ...) excepted a few ones for which I have to use slightly different compilation flags (called later flag1_debug, flag1_release ...). As in both cases the flags are different from the default ones, I was told on the cmake list to create a personal Compiler/G95-Fortran.cmake file that was placed in my Src directory and that contains the following lines: set(CMAKE_Fortran_FLAGS_INIT ) set(CMAKE_Fortran_FLAGS_DEBUG_INIT flag_debug) set(CMAKE_Fortran_FLAGS_RELEASE_INIT flag_release) set(CMAKE_Fortran_MODDIR_FLAG -fmod=) set(CMAKE_Fortran_VERBOSE_FLAG -v) This file allowing to avoid the declaration of the flags in the CMakeLists.txt file. But, how to proceed for the few files for which I have to use different compiler flags ? In that case, I do not see any way to escape from writing specifically the flags in the CMakeLists.txt file with command such as: if(CMAKE_BUILD_TYPE STREQUAL RELEASE) set_source_files_properties(File1 PROPERTIES COMPILE_FLAGS flag1_release) set_source_files_properties(File2 PROPERTIES COMPILE_FLAGS flag1_release) ... elseif(CMAKE_BUILD_TYPE STREQUAL DEBUG) set_source_files_properties(File1 PROPERTIES COMPILE_FLAGS flag1_debug) set_source_files_properties(File2 PROPERTIES COMPILE_FLAGS flag1_debug) ... ... endif() would you have any idea about how to esacpe from this kind of implementation ? is that so ugly ? thanks Eric Well, for one you don't need separate set_source_files_properties commands for every single file (that is, if the flags are the same): if(CMAKE_BUILD_TYPE STREQUAL Release) # notice the capitalization! set_source_files_properties(File1 File2 File3 PROPERTIES COMPILE_FLAGS ...) elseif(CMAKE_BUILD_TYPE STREQUAL Debug) # notice the capitalization! set_source_files_properties(File1 File2 File3 PROPERTIES COMPILE_FLAGS ...) endif() However: such a scheme will break with multi-configuration IDEs since CMAKE_BUILD_TYPE is not known when CMake runs because the user can choose the configuration in the IDE afterwards. Unfortunately there are no COMPILE_FLAGS_CONFIG properties... I think that currently the only reliable way of doing this is to split the special sources out into a separate directory and compile them there as a static library. Michael -- There is always a well-known solution to every human problem -- neat, plausible, and wrong. H. L. Mencken PGP.sig 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] How to list user-definable CMake variables
Marcel,
We use a 'bootstrap' CMakeCache.txt file that has README-like full
documentation for each user settable variable. This way a new developer can
copy the bootstrap CMakeCache.txt file to his/her build directory and edit
the file variable-by-variable before running cmake.
Something like:
# CMakeCache.txt - bootstrap file for new builds.
# Instructions.
# 1. Copy this file to your build directory as CMakeCache.txt.
# 2. Review and update all values in this file.
# 3. Environment must have $FC set to one of { ifort, gfortran or pathf90 }
# 4. From the build directory run 'cmake /full/path/to/source'
# Location where 'make install' will copy files to.
CMAKE_INSTALL_PREFIX:PATH=/full/path/to/target/directory
# CMAKE_BUILD_TYPE == { Release, Debug, RelWithDebInfo, MinSizeRel }
CMAKE_BUILD_TYPE:STRING=Release
# CMAKE_GENERATOR == { NMake Makefiles, Unix Makefiles, Visual Studio 9
2008, Visual Studio 9 2008 Win64 }
CMAKE_GENERATOR:STRING=Unix Makefiles
etc.
Maybe that is too clunky for you -- but has worked well for us.
-kt
-Original Message-
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf
Of
Eric Noulard
Sent: Tuesday, September 28, 2010 3:12 AM
To: Marcel Loose
Cc: cmake@cmake.org; them...@gmail.com
Subject: Re: [CMake] How to list user-definable CMake variables
2010/9/28 Marcel Loose lo...@astron.nl:
You may want to call your target help but it would conflict/override
the cmake builtin help target
(at least for makefile generator) which display the list of available
target.
This work AFTER cmake has been run. It could be run before as well
using:
cmake -DCMAKE_MODULE_PATH=/path/to/source --help-module HelpMe
but this is awkward :-(
Thanks Erk,
I'll give it a thought. Your solution uses some nice CMake features, but
I find it a bit awkward. It suffers from separation of code and
documentation, though. That's always risky, since the two are likely to
diverge.
It is a little bit, but you can put in this custom cmake file
(you may rename it to CustomizableOptions.cmake)
any CMake *code* you want including the definition of OPTION or vars
(using SET) etc...
then in you CMakeLists.txt you can
include(CustomizableOptions.cmake)
and the header of the file contains the useful doc. for the
concerned option/vars.
then the code and it's doc stay together.
--
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://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] How to set compiler flags?
Hi I am writing CMakeLists.txt files for my C++ application. Initially I set the C++ compiler flags by setting CMAKE_CXX_FLAGS: set( CMAKE_CXX_FLAGS -Wall -m64 -O3 ) Then I realised that those flags get passed to the linker as well, which seemed a bit untidy. So I now use add_definitions instead: add_definitions( -Wall -m64 -O3 ) Is there a better way of doing this? My CMakeLists.txt files only handle a release build currently. If you could give me a hint for how to go on to add a debug build option, I would be grateful. Best regards David ___ 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] Running tests using [C++/Python] modules from the build tree
Hi, I am seeking for advise. I would like to run some CTest tests from the build tree, which require C++ or Python modules created in other project directories (packages). For this I need to build correctly the LD_LIBRARY_PATH and PYTHONPATH and use the command set_property(TEST xxx PROPERTY ENVIRONMENT LD_LIBRARY_PATH=yyy PYTHONPATH=xxx). The question is how to make this the most easy and transparent way as possible, since the modules I would need in the tests are not easily known a priori. If I could set a global variable in each package that creates a module, something like PACKAGE_MODULE_DIRS and I could collect these in the package that I want to run the test and build the ENVIRONMENT property accordingly. The problem is that it is not so easy in CMake to set global variables. Another alternative would be to define a function called module_directories(), which behaves like the command link_dicrectories(), that I could call every time I create/define a module. I would then recover the list of directories using a specific directory property, as it is done in the case of LINK_DIRECTORIES. Does anybody has a similar problem and has found an elegant solution? Many thanks in advance. - Pere Mato CERN, PH Department, CH 1211 Geneva 23, Switzerland e-mail: pere.m...@cern.ch tel: +41 22 76 78696 fax: +41 22 76 68792gsm: +41 76 48 70855 ___ 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] Howto compile static executable?
Hi All, I have project which (cross-)compile some simple C applications with some bare CMake statement like this: add_executable(myapp myapp.c) no target_link_libraries, no dep, etc... I want to build fully static executable (even for libc etc...) Currently I do: set_target_properties(myapp PROPERTIES LINK_FLAGS_DEBUG -static) is there a better and portable way to require static executable? I am aware of the BUILD_SHARED_LIBS var for globally controlling static vs dynamic libs but how can I do for executable? -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Build library with specific compil flags for a few files
Hi Michael, so if I get you right I should organize my library as follow: src/ Compiler/G95_Fortran.cmake CMakeLists.txt my_general_f90_src_files special_flag_src/ Compiler/G95_Fortran.cmake CMakeLists.txt my_special_f90_src_files where the nested CMakeLists.txt will call add_library(my_special_f90_files.a my_special_f90_src_files ...) and where the main CMakeLists.txt file will call add_library(my_general_f90_files.a my_general_f90_src_files ...) not forgotting in the latter case to specify the dependancy on the special_f90_files.a library. In doing so, both static libraries will be compiled according to the compilation flags stored in their respective Compiler/G95_Fortran.cmake files. sorry for the naive questions but I just started with CMake two weeks ago and I am quite in hurry to provide a first example to convince my boss that using CMake is the right solution ... thanks again Eric On 28. Sep, 2010, at 16:08 , pellegrini wrote: Hello everybody, I have a library for which almost all the files should be compiled (e.g. g95) with the same compilation flags (that I will call later flag_debug, flag_release ...) excepted a few ones for which I have to use slightly different compilation flags (called later flag1_debug, flag1_release ...). As in both cases the flags are different from the default ones, I was told on the cmake list to create a personal Compiler/G95-Fortran.cmake file that was placed in my Src directory and that contains the following lines: set(CMAKE_Fortran_FLAGS_INIT ) set(CMAKE_Fortran_FLAGS_DEBUG_INIT flag_debug) set(CMAKE_Fortran_FLAGS_RELEASE_INIT flag_release) set(CMAKE_Fortran_MODDIR_FLAG -fmod=) set(CMAKE_Fortran_VERBOSE_FLAG -v) This file allowing to avoid the declaration of the flags in the CMakeLists.txt file. But, how to proceed for the few files for which I have to use different compiler flags ? In that case, I do not see any way to escape from writing specifically the flags in the CMakeLists.txt file with command such as: if(CMAKE_BUILD_TYPE STREQUAL RELEASE) set_source_files_properties(File1 PROPERTIES COMPILE_FLAGS flag1_release) set_source_files_properties(File2 PROPERTIES COMPILE_FLAGS flag1_release) ... elseif(CMAKE_BUILD_TYPE STREQUAL DEBUG) set_source_files_properties(File1 PROPERTIES COMPILE_FLAGS flag1_debug) set_source_files_properties(File2 PROPERTIES COMPILE_FLAGS flag1_debug) ... ... endif() would you have any idea about how to esacpe from this kind of implementation ? is that so ugly ? thanks Eric Well, for one you don't need separate set_source_files_properties commands for every single file (that is, if the flags are the same): if(CMAKE_BUILD_TYPE STREQUAL Release) # notice the capitalization! set_source_files_properties(File1 File2 File3 PROPERTIES COMPILE_FLAGS ...) elseif(CMAKE_BUILD_TYPE STREQUAL Debug) # notice the capitalization! set_source_files_properties(File1 File2 File3 PROPERTIES COMPILE_FLAGS ...) endif() However: such a scheme will break with multi-configuration IDEs since CMAKE_BUILD_TYPE is not known when CMake runs because the user can choose the configuration in the IDE afterwards. Unfortunately there are no COMPILE_FLAGS_CONFIG properties... I think that currently the only reliable way of doing this is to split the special sources out into a separate directory and compile them there as a static library. Michael -- There is always a well-known solution to every human problem -- neat, plausible, and wrong. H. L. Mencken ___ 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] How to list user-definable CMake variables
On Tuesday 28 September 2010, Marcel Loose wrote: Hi all, I was wondering how I could generate a list of user-definable CMake variables. This list, with a brief help per variable, would be *very* useful for the end-user. It's a bit like the well-known configure --help which gives you a overview of all variables that can be set. Run cmake-gui, and check which variables appear after the first configure run in the non-advanced section. This should be the variables intended to be changed by the user (the one who compiles) 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Environment Variable - /var
On Tuesday 28 September 2010, Laszlo Papp wrote: Hi, Is there such an environment variable, like in case autoconf: --localstatedir=DIR modifiable single-machine data [PREFIX/var] There are options like CMAKE_INSTALL_PREFIX, SYSCONF_INSTALL_DIR, but not this one. I can make an own one, I am just out of the curiosity whether there is an internal solution. SYSCONF_INSTALL_DIR is also not provided by cmake. In KDE we define a whole bunch of installation directories: http://api.kde.org/cmake/modules.html#module_FindKDE4Internal (the ones without KDE4_ prefix) 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Environment Variable - /var
It is not a KDE project ... Best Regards, Laszlo Papp On Tue, Sep 28, 2010 at 11:29 AM, Alexander Neundorf a.neundorf-w...@gmx.net wrote: On Tuesday 28 September 2010, Laszlo Papp wrote: Hi, Is there such an environment variable, like in case autoconf: --localstatedir=DIR modifiable single-machine data [PREFIX/var] There are options like CMAKE_INSTALL_PREFIX, SYSCONF_INSTALL_DIR, but not this one. I can make an own one, I am just out of the curiosity whether there is an internal solution. SYSCONF_INSTALL_DIR is also not provided by cmake. In KDE we define a whole bunch of installation directories: http://api.kde.org/cmake/modules.html#module_FindKDE4Internal (the ones without KDE4_ prefix) 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Environment Variable - /var
On Tuesday 28 September 2010, Laszlo Papp wrote: It is not a KDE project ... It was just meant as inspiration. And if you want you can of course use the code for the install dirs from FindKDE4Internal.cmake, it's BSD licensed. 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Environment Variable - /var
The short answer is then: there is no such an option. Oki doki, thank you. Best Regards, Laszlo Papp On Tue, Sep 28, 2010 at 12:25 PM, Alexander Neundorf a.neundorf-w...@gmx.net wrote: On Tuesday 28 September 2010, Laszlo Papp wrote: It is not a KDE project ... It was just meant as inspiration. And if you want you can of course use the code for the install dirs from FindKDE4Internal.cmake, it's BSD licensed. 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://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] setting Visual Studio solution name
Is there a way to specify what the name of the solution file should be? Currently it's named from the last PROJECT in a CMakeLists.txt. I would prefer that it be the first name... I see methods of setting output files for particular projects, but not the solution ___ 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] Visual Studio Incremental linking
Is there a reason that incremental linking is enabled by default with generated output from cmake? Hmm and it's not disabled in release mode... I went to check to see what the option actually does for (or to) me.. -- from http://msdn.microsoft.com/en-us/library/4khtbfyf(v=vs.80).aspx -- An incrementally linked program is functionally equivalent to a program that is nonincrementally linked. However, because it is prepared for subsequent incremental links, an incrementally linked executable (.exe) file or dynamic-link library (DLL): Is larger than a nonincrementally linked program because of padding of code and data. (Padding allows the linker to increase the size of functions and data without recreating the .exe file.) May contain jump thunks to handle relocation of functions to new addresses. Note To ensure that your final release build does not contain padding or thunks, link your program nonincrementally. Does make sense for debug modes, if edit and continue is enabled... I see that's not enabled though... I wouldn't have even stumbled across this other than I have two projects (video_link_server) and (video_link_server.isp) (the first is a program, and gets an implied .exe extension sorta) which both try to reference $(OutDir)/video_link_server[.ilk] for incremental linking. Since that file isn't explicitly defined by cmake output, can't directly blame cmake; however, if incremental linking isn't a feature, disabling it will fix this ___ 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] How to set compiler flags?
On 09/28/2010 05:35 PM, David Aldrich wrote: Hi I am writing CMakeLists.txt files for my C++ application. Initially I set the C++ compiler flags by setting CMAKE_CXX_FLAGS: set( CMAKE_CXX_FLAGS -Wall -m64 -O3 ) Then I realised that those flags get passed to the linker as well, which seemed a bit untidy. [...] But possibly necessary: http://www.cmake.org/pipermail/cmake/2010-July/038083.html et seq. [...] So I now use add_definitions instead: add_definitions( -Wall -m64 -O3 ) Is there a better way of doing this? Don't do this at all, and adhere to the flags. My CMakeLists.txt files only handle a release build currently. If you could give me a hint for how to go on to add a debug build option, I would be grateful. Doesn't the DEBUG variant of the flags, e.g. CMAKE_CXX_FLAGS_DEBUG, and other related variables - perhaps in connection with CMAKE_BUILD_TYPE - work for you? 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
Re: [CMake] setting Visual Studio solution name
On Tue, Sep 28, 2010 at 6:23 PM, Ryan Pavlik rpav...@iastate.edu wrote:
In most cases, you won't need more than one project call - each target
(add_executable, etc) creates a visual studio project, so the only
reason I can think of that you'd necessarily have multiple project
calls is if you have a subdirectory that can also stand alone as a
separate build.
Really? I guess that's what they meant about me using
${PROJECT_NAME}... I could have chosen a custom variable to start the
beginning of a new section of code... and can probably mass
find-replace specific projects that are being issues
but if I wanted to apply options to sources specifically for a target,
I for some reason thought that the PROJECT would serve as that
container (like a new source list per project).
There are several places where I want to compile exactly the same
source for another target but with different options (console or
windowed mode for instance). Hmm I guess I end up specifying those
options on the target instead of per source (the same source is
indistinguishable to set_source_files_properties if it's used in two
targets...)
so really PROJECT is the name of the solution, and that's about it?
Well I guess it's just an alias for each directory in the project
workspace... and only the last name really counts. Hmm well maybe
the other names are also as good for directory to the same
directory...
What would project do for codeblocks that's not the same as say
'FOLDER' in visual studio?
You might consider filing an issue about this in the bug tracker.
Ryan
On Tue, Sep 28, 2010 at 6:28 PM, J Decker d3c...@gmail.com wrote:
Is there a way to specify what the name of the solution file should
be? Currently it's named from the last PROJECT in a CMakeLists.txt.
I would prefer that it be the first name... I see methods of setting
output files for particular projects, but not the solution
___
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
--
Ryan Pavlik
HCI Graduate Student
Virtual Reality Applications Center
Iowa State University
rpav...@iastate.edu
http://academic.cleardefinition.com
Internal VRAC/HCI Site: http://tinyurl.com/rpavlik
___
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-commits] CMake branch, master, updated. v2.8.2-507-g126158f
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 126158f0461589a7d27901be3f8e8d2eaade4fa8 (commit) via 225abc555de7499f4847e91de22523766541ce61 (commit) from c0665ca79572215a6f00804ec5c75f598682d465 (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=126158f0461589a7d27901be3f8e8d2eaade4fa8 commit 126158f0461589a7d27901be3f8e8d2eaade4fa8 Merge: c0665ca 225abc5 Author: Brad King brad.k...@kitware.com AuthorDate: Tue Sep 28 14:02:44 2010 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Sep 28 14:02:44 2010 -0400 Merge topic 'fixAbsoluteDestHandlingRegression' 225abc5 InstallGen/CPack fix handling absolute installed file regression --- Summary of changes: Source/cmInstallGenerator.cxx |7 +-- 1 files changed, 5 insertions(+), 2 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.2-509-gc86d677
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 c86d677fe0456bebfe8e361038f3b1e37c9c285d (commit) via 25931ae10ed6b3bddc242ace16bed82dd2683596 (commit) from 126158f0461589a7d27901be3f8e8d2eaade4fa8 (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=c86d677fe0456bebfe8e361038f3b1e37c9c285d commit c86d677fe0456bebfe8e361038f3b1e37c9c285d Merge: 126158f 25931ae Author: Brad King brad.k...@kitware.com AuthorDate: Tue Sep 28 14:03:37 2010 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Sep 28 14:03:37 2010 -0400 Merge topic 'findqt4-cross-compile' 25931ae Fix regression in cross-compile patches with finding Qt libs. --- Summary of changes: Modules/FindQt4.cmake |4 +++- 1 files changed, 3 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
[Cmake-commits] CMake branch, master, updated. v2.8.2-513-g3398ec7
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 3398ec7d6f5bb6d25edbbd079df7058819c8d60e (commit) via 7ef659fcc3db3d11190526101f123992728794e0 (commit) from e66c12a2659df4fe74a199fb805969581676b36a (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=3398ec7d6f5bb6d25edbbd079df7058819c8d60e commit 3398ec7d6f5bb6d25edbbd079df7058819c8d60e Merge: e66c12a 7ef659f Author: Brad King brad.k...@kitware.com AuthorDate: Tue Sep 28 14:04:48 2010 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Sep 28 14:04:48 2010 -0400 Merge topic 'vs10-object-intdir' 7ef659f VS10: Use $(IntDir) for per-source output directory (#11270) --- Summary of changes: Source/cmVisualStudio10TargetGenerator.cxx |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
[Cmake-commits] CMake branch, master, updated. v2.8.2-515-gdbf7664
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 dbf7664c996037367119754e277f66ab84e52e84 (commit) via 567ac0bb1f1b89cd7c8b28435979a0ce023dca8a (commit) from 3398ec7d6f5bb6d25edbbd079df7058819c8d60e (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=dbf7664c996037367119754e277f66ab84e52e84 commit dbf7664c996037367119754e277f66ab84e52e84 Merge: 3398ec7 567ac0b Author: Brad King brad.k...@kitware.com AuthorDate: Tue Sep 28 14:05:15 2010 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Sep 28 14:05:15 2010 -0400 Merge topic 'PutRequiredVersionInDetailMessageInFPHSA' 567ac0b Also store the required version number in the details message. --- Summary of changes: Modules/FindPackageHandleStandardArgs.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
[Cmake-commits] CMake branch, next, updated. v2.8.2-949-g6dc009c
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 6dc009c46581435241af70ed54ab17c658ceddf4 (commit)
via 1c2e17f2afe4dfcb2dac543af4a21121722b38f9 (commit)
from ca68ba9354e7f9809b7cdc8c7a93898ab157775d (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=6dc009c46581435241af70ed54ab17c658ceddf4
commit 6dc009c46581435241af70ed54ab17c658ceddf4
Merge: ca68ba9 1c2e17f
Author: Bill Hoffman bill.hoff...@kitware.com
AuthorDate: Tue Sep 28 14:38:12 2010 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Sep 28 14:38:12 2010 -0400
Merge topic 'xcode_source_group_fix_7932' into next
1c2e17f XCode Source Grouping now allows for multiple levels of source
groups (7932).
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1c2e17f2afe4dfcb2dac543af4a21121722b38f9
commit 1c2e17f2afe4dfcb2dac543af4a21121722b38f9
Author: Bill Hoffman bill.hoff...@kitware.com
AuthorDate: Mon Sep 27 14:41:47 2010 -0400
Commit: Bill Hoffman bill.hoff...@kitware.com
CommitDate: Tue Sep 28 14:36:56 2010 -0400
XCode Source Grouping now allows for multiple levels of source groups
(7932).
patch given by goatboy160, and updated by Claus Hofele.
diff --git a/Source/cmGlobalXCodeGenerator.cxx
b/Source/cmGlobalXCodeGenerator.cxx
index 4e9969d..3603ddf 100644
--- a/Source/cmGlobalXCodeGenerator.cxx
+++ b/Source/cmGlobalXCodeGenerator.cxx
@@ -2435,26 +2435,68 @@ void
cmGlobalXCodeGenerator::CreateGroups(cmLocalGenerator* root,
std::vectorcmSourceFile* classes = cmtarget.GetSourceFiles();
- for(std::vectorcmSourceFile*::const_iterator s = classes.begin();
+ for(std::vectorcmSourceFile*::const_iterator s = classes.begin();
s != classes.end(); s++)
{
cmSourceFile* sf = *s;
// Add the file to the list of sources.
std::string const source = sf-GetFullPath();
-cmSourceGroup sourceGroup =
+cmSourceGroup sourceGroup =
mf-FindSourceGroup(source.c_str(), sourceGroups);
-cmXCodeObject* pbxgroup =
- this-CreateOrGetPBXGroup(cmtarget, sourceGroup);
-cmStdString key = GetGroupMapKey(cmtarget, sf);
-this-GroupMap[key] = pbxgroup;
+sourceGroup.AssignSource( sf );
+}
+
+ // Create all of the groups that should be created for this target.
+ // Loop through every source group.
+ for(unsigned int i = 0; i sourceGroups.size(); ++i)
+{
+this-CreateSourceGroup( sourceGroups[i], cmtarget, false );
+}
+ }
+}
+}
+
+//
+cmXCodeObject* cmGlobalXCodeGenerator
+::CreateSourceGroup( cmSourceGroup sg, cmTarget cmtarget, bool child_group )
+{
+ // Only do something with the group if there are files or child groups
+ if( !sg.GetSourceFiles().empty() || !sg.GetGroupChildren().empty() )
+{
+cmXCodeObject* pbxgroup =
+ this-CreateOrGetPBXGroup(cmtarget, sg, !child_group);
+
+std::vectorconst cmSourceFile* sources = sg.GetSourceFiles();
+// Get all the source files and add them to the GroupMap
+for(std::vectorconst cmSourceFile*::const_iterator s = sources.begin();
+s != sources.end(); s++)
+ {
+ cmStdString key = GetGroupMapKey(cmtarget, (cmSourceFile*)*s);
+ this-GroupMap[key] = pbxgroup;
+ }
+
+// Do the child groups
+std::vectorcmSourceGroup children = sg.GetGroupChildren();
+cmXCodeObject* groupChildren = pbxgroup-GetObject(children);
+
+for(unsigned int i=0;ichildren.size();++i)
+ {
+ cmXCodeObject* group =
+this-CreateSourceGroup( children[i], cmtarget, true );
+ if (group)
+{
+groupChildren-AddObject(group);
}
}
-}
+return pbxgroup;
+}
+ return NULL;
}
+
//
cmXCodeObject* cmGlobalXCodeGenerator
-::CreateOrGetPBXGroup(cmTarget cmtarget, cmSourceGroup* sg)
+::CreateOrGetPBXGroup(cmTarget cmtarget, cmSourceGroup* sg, bool child_group)
{
cmStdString s = cmtarget.GetName();
s += /;
@@ -2496,9 +2538,8 @@ cmXCodeObject* cmGlobalXCodeGenerator
return tgroup;
}
- cmXCodeObject* tgroupChildren = tgroup-GetObject(children);
cmXCodeObject* group = this-CreateObject(cmXCodeObject::PBXGroup);
- cmXCodeObject* groupChildren =
+ cmXCodeObject* groupChildren =
this-CreateObject(cmXCodeObject::OBJECT_LIST);
group-AddAttribute(name, this-CreateString(sg-GetName()));
group-AddAttribute(children,
[Cmake-commits] CMake branch, next, updated. v2.8.2-953-g97ec9c3
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 97ec9c3b2fad7be5686b40c6484528441b4cd190 (commit)
via 19a9a1d57c84352461ce127fa2200e94ee308a52 (commit)
from 7075b00828e015cfb587d1a9141a2fd0ff671fee (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=97ec9c3b2fad7be5686b40c6484528441b4cd190
commit 97ec9c3b2fad7be5686b40c6484528441b4cd190
Merge: 7075b00 19a9a1d
Author: Bill Hoffman bill.hoff...@kitware.com
AuthorDate: Tue Sep 28 18:06:34 2010 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Sep 28 18:06:34 2010 -0400
Merge topic 'xcode_source_group_fix_7932' into next
19a9a1d Fix compile problem from previous commit.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=19a9a1d57c84352461ce127fa2200e94ee308a52
commit 19a9a1d57c84352461ce127fa2200e94ee308a52
Author: Bill Hoffman bill.hoff...@kitware.com
AuthorDate: Tue Sep 28 18:05:54 2010 -0400
Commit: Bill Hoffman bill.hoff...@kitware.com
CommitDate: Tue Sep 28 18:05:54 2010 -0400
Fix compile problem from previous commit.
diff --git a/Source/cmGlobalXCodeGenerator.cxx
b/Source/cmGlobalXCodeGenerator.cxx
index 78df0e4..57f2f3a 100644
--- a/Source/cmGlobalXCodeGenerator.cxx
+++ b/Source/cmGlobalXCodeGenerator.cxx
@@ -2450,7 +2450,7 @@ void
cmGlobalXCodeGenerator::CreateGroups(cmLocalGenerator* root,
// Loop through every source group.
for(unsigned int idx = 0; idx sourceGroups.size(); ++idx)
{
-this-CreateSourceGroup( sourceGroups[i], cmtarget, false );
+this-CreateSourceGroup( sourceGroups[idx], cmtarget, false );
}
}
}
---
Summary of changes:
Source/cmGlobalXCodeGenerator.cxx |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
[Cmake-commits] CMake branch, next, updated. v2.8.2-957-g1b0e592
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 1b0e5925cbfe295bbf1e3f8226fdb708ea9efb87 (commit)
via 1a92548ca29387d65472f63f8401532ae48f293a (commit)
via 4ebc277a7a64ff9ea93a1b67959c39c6d7bc892f (commit)
via 68fd37c39938635e992ec47bad2afa13150b9b3d (commit)
from 97ec9c3b2fad7be5686b40c6484528441b4cd190 (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=1b0e5925cbfe295bbf1e3f8226fdb708ea9efb87
commit 1b0e5925cbfe295bbf1e3f8226fdb708ea9efb87
Merge: 97ec9c3 1a92548
Author: Marcus D. Hanwell marcus.hanw...@kitware.com
AuthorDate: Tue Sep 28 18:52:41 2010 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Sep 28 18:52:41 2010 -0400
Merge topic 'xcode_source_group_fix_7932' into next
1a92548 Revert previous commit in topic.
4ebc277 Revert Fix shadow warning in groups code.
68fd37c Revert Fix compile problem from previous commit.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1a92548ca29387d65472f63f8401532ae48f293a
commit 1a92548ca29387d65472f63f8401532ae48f293a
Author: Marcus D. Hanwell marcus.hanw...@kitware.com
AuthorDate: Tue Sep 28 18:39:38 2010 -0400
Commit: Marcus D. Hanwell marcus.hanw...@kitware.com
CommitDate: Tue Sep 28 18:47:21 2010 -0400
Revert previous commit in topic.
Revert XCode Source Grouping now allows for multiple levels of source
groups (7932).
This reverts commit 1c2e17f2afe4dfcb2dac543af4a21121722b38f9.
diff --git a/Source/cmGlobalXCodeGenerator.cxx
b/Source/cmGlobalXCodeGenerator.cxx
index 3603ddf..e238c2b 100644
--- a/Source/cmGlobalXCodeGenerator.cxx
+++ b/Source/cmGlobalXCodeGenerator.cxx
@@ -1073,7 +1073,7 @@ void
cmGlobalXCodeGenerator::CreateCustomCommands(cmXCodeObject* buildPhases,
std::vectorcmSourceFile*const classes = cmtarget.GetSourceFiles();
// add all the sources
std::vectorcmCustomCommand commands;
- for(std::vectorcmSourceFile*::const_iterator i = classes.begin();
+ for(std::vectorcmSourceFile*::const_iterator i = classes.begin();
i != classes.end(); ++i)
{
if((*i)-GetCustomCommand())
@@ -2443,14 +2443,10 @@ void
cmGlobalXCodeGenerator::CreateGroups(cmLocalGenerator* root,
std::string const source = sf-GetFullPath();
cmSourceGroup sourceGroup =
mf-FindSourceGroup(source.c_str(), sourceGroups);
-sourceGroup.AssignSource( sf );
-}
-
- // Create all of the groups that should be created for this target.
- // Loop through every source group.
- for(unsigned int i = 0; i sourceGroups.size(); ++i)
-{
-this-CreateSourceGroup( sourceGroups[i], cmtarget, false );
+cmXCodeObject* pbxgroup =
+ this-CreateOrGetPBXGroup(cmtarget, sourceGroup);
+cmStdString key = GetGroupMapKey(cmtarget, sf);
+this-GroupMap[key] = pbxgroup;
}
}
}
@@ -2458,45 +2454,7 @@ void
cmGlobalXCodeGenerator::CreateGroups(cmLocalGenerator* root,
//
cmXCodeObject* cmGlobalXCodeGenerator
-::CreateSourceGroup( cmSourceGroup sg, cmTarget cmtarget, bool child_group )
-{
- // Only do something with the group if there are files or child groups
- if( !sg.GetSourceFiles().empty() || !sg.GetGroupChildren().empty() )
-{
-cmXCodeObject* pbxgroup =
- this-CreateOrGetPBXGroup(cmtarget, sg, !child_group);
-
-std::vectorconst cmSourceFile* sources = sg.GetSourceFiles();
-// Get all the source files and add them to the GroupMap
-for(std::vectorconst cmSourceFile*::const_iterator s = sources.begin();
-s != sources.end(); s++)
- {
- cmStdString key = GetGroupMapKey(cmtarget, (cmSourceFile*)*s);
- this-GroupMap[key] = pbxgroup;
- }
-
-// Do the child groups
-std::vectorcmSourceGroup children = sg.GetGroupChildren();
-cmXCodeObject* groupChildren = pbxgroup-GetObject(children);
-
-for(unsigned int i=0;ichildren.size();++i)
- {
- cmXCodeObject* group =
-this-CreateSourceGroup( children[i], cmtarget, true );
- if (group)
-{
-groupChildren-AddObject(group);
-}
- }
-return pbxgroup;
-}
- return NULL;
-}
-
-
-//
-cmXCodeObject* cmGlobalXCodeGenerator
-::CreateOrGetPBXGroup(cmTarget cmtarget, cmSourceGroup* sg, bool child_group)
+::CreateOrGetPBXGroup(cmTarget cmtarget, cmSourceGroup* sg)
{
cmStdString s = cmtarget.GetName();
s += /;
@@ -2517,7 +2475,7 @@ cmXCodeObject*
[Cmake-commits] CMake branch, master, updated. v2.8.2-519-g0f6b3a0
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 0f6b3a0059c2b9d10cb24af0203be2abb8c1 (commit) from d24b8acc1a0df5bae8294a55cba105f707416b1b (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=0f6b3a0059c2b9d10cb24af0203be2abb8c1 commit 0f6b3a0059c2b9d10cb24af0203be2abb8c1 Author: KWSys Robot kwro...@kitware.com AuthorDate: Wed Sep 29 00:01:05 2010 -0400 Commit: KWSys Robot kwro...@kitware.com CommitDate: Wed Sep 29 00:10:08 2010 -0400 KWSys Nightly Date Stamp diff --git a/Source/kwsys/kwsysDateStamp.cmake b/Source/kwsys/kwsysDateStamp.cmake index 98fc895..2863f87 100644 --- a/Source/kwsys/kwsysDateStamp.cmake +++ b/Source/kwsys/kwsysDateStamp.cmake @@ -18,4 +18,4 @@ SET(KWSYS_DATE_STAMP_YEAR 2010) SET(KWSYS_DATE_STAMP_MONTH 09) # KWSys version date day component. Format is DD. -SET(KWSYS_DATE_STAMP_DAY 28) +SET(KWSYS_DATE_STAMP_DAY 29) --- 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
