Re: [cmake-developers] Improving OpenSSL version support
On 1/12/2012 5:47 PM, Rolf Eike Beer wrote: But I'm not going to add support for things older than 0.9.6, this stuff is ancient. Okay, thanks. Also, the examples given in the header are confusing because they leave out the patch level from the string. I think the patch level can be included as a fourth component in our OPENSSL_VERSION var. Hm? * 0.9.3a 0x0090301f * 0.9.4 0x0090400f * 1.2.3z 0x102031af The format is specified as MNNFFPPS where M = Major NN = Minor FF = Fix PP = Patch S = Status The example 0x0090301f matches up to that as M = 0 NN = 09 FF = 03 PP = 01 S = f which should be 0.9.3.1f The example with z in it makes no sense at all given the explanation right above it: * The status nibble has one of the values 0 for development, 1 to e for betas * 1 to 14, and f for release. The patch level is exactly that. The explanation you give in your new commit on the topic is more coherent. Where did you get it that information? Thanks, -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Improving OpenSSL version support
On 1/12/2012 6:12 PM, Rolf Eike Beer wrote: the patch level can be included as a fourth component in our OPENSSL_VERSION var. Or just put the normal OpenSSL version string in there? It works for VERSION_LESS and friends. And since FIND_PACKAGE() handles version selection anyway I don't see what a user should have to do with it anyway. Yes, I think that is reasonable. It avoids adding the extra _STRING version variable, right? Another approach is to convert the patch level to a fourth integer version component, which is not good for printing but is good for VERSION_LESS. Then we would still need the _STRING version for printing though. I've pushed 2 more changes to that branch. The first one add documentation, the second one parses the version number only once and puts the result in a list and uses that elements later on. And it get's rid of some really long lines. Nice, thanks. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Improving OpenSSL version support
On 1/13/2012 9:47 AM, Rolf Eike Beer wrote: On 1/13/2012 9:41 AM, Rolf Eike Beer wrote: Status = f - this is a released version PP = 0x1 - a That doesn't appear in my version. I guess they added it later. No, indeed exactly the lines you quoted before. It's just that the patch level is encoded as number in the C constant, but written as letter in the string. Look again: I meant that the exact lines you quoted with the explanation do not appear in my version above the examples where they do in your version. Given those lines it is clear how 0x1a becomes z. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Improving OpenSSL version support
On 1/13/2012 9:47 AM, Rolf Eike Beer wrote: On 1/13/2012 9:41 AM, Rolf Eike Beer wrote: Status = f - this is a released version PP = 0x1 - a That doesn't appear in my version. I guess they added it later. No, indeed exactly the lines you quoted before. It's just that the patch level is encoded as number in the C constant, but written as letter in the string. Look again: I meant that the exact lines you quoted with the explanation do not appear in my version above the examples where they do in your version. Given those lines it is clear how 0x1a becomes z. Ok, sorry. For reference, here is the whole comment from OpenSSL 1.0.0f: /* Numeric release version identifier: * MNNFFPPS: major minor fix patch status * The status nibble has one of the values 0 for development, 1 to e for betas * 1 to 14, and f for release. The patch level is exactly that. * For example: * 0.9.3-dev 0x00903000 * 0.9.3-beta10x00903001 * 0.9.3-beta2-dev 0x00903002 * 0.9.3-beta20x00903002 (same as ...beta2-dev) * 0.9.3 0x0090300f * 0.9.3a 0x0090301f * 0.9.4 0x0090400f * 1.2.3z 0x102031af * * For continuity reasons (because 0.9.5 is already out, and is coded * 0x00905100), between 0.9.5 and 0.9.6 the coding of the patch level * part is slightly different, by setting the highest bit. This means * that 0.9.5a looks like this: 0x0090581f. At 0.9.6, we can start * with 0x0090600S... * * (Prior to 0.9.3-dev a different scheme was used: 0.9.2b is 0x0922.) * (Prior to 0.9.5a beta1, a different scheme was used: MMNNFFRBB for * major minor fix final patch/beta) */ So what do we do now? Completely drop the OPENSSL_VERSION_STRING variable and just throw it's contents into OPENSSL_VERSION? Makes things easier, cool ;) I'll go and squash those things together tonight and push into next. Eike -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] code coverage with clang
Hi, We're trying to configure our nightly builds of CMake, ITK, and VTK to submit coverage reports to the official dashboard (in addition to the compilation and unit test reports that we already do). We are building on Mac OS X and use the clang compiler. While compilation and unit testing work as expected, there are some problems with the code coverage. [problem 1] When running the CMake code coverage tests, some of the .gcda files are created in the source directory instead the binary directory. Here is the git status report: # On branch master # Untracked files: # (use git add file... to include in what will be committed) # # Tests/CommandLineTest/CMakeFiles/ # Tests/CustomCommandWorkingDirectory/CMakeFiles/ # Tests/Java/CMakeFiles/ Because of this the CMake.CheckSourceTree unit test fails. Do people on other platform experience similar problems, or it happens on Mac OS only? [problem 2] While test logs show what looks like valid coverage information, when the dashboard report is created, all the numbers are zero (tested lines, covered lines, etc.). Example here: http://www.cdash.org/CDash/viewCoverage.php?buildid=1912205 Again, does anyone experience similar problems on other platforms? sincerely, Alex Ciobanu-- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[CMake] Progress report strange behaviour with mixed file permissions
Hi, A friend of mine has asked me to confirm if there may be a bug in CMake related to file permissions on Unix. Here is the story: There are some files under CMakeFiles/ directory owned by root and not overridable by strk (non-root user). Having such setup results in a pretty funny behaviour: you do can run make but the progress widget always reports the same percentage. I was at 83% from start to finish. Pretty puzzling :) The above was with cmake version 2.8.1. Could any one point where is the problem? CMake misuse or bug indeed? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net -- 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] Progress report strange behaviour with mixed file permissions
On Fri, Jan 13, 2012 at 5:48 AM, Mateusz Loskot mate...@loskot.net wrote: Hi, A friend of mine has asked me to confirm if there may be a bug in CMake related to file permissions on Unix. Here is the story: There are some files under CMakeFiles/ directory owned by root and not overridable by strk (non-root user). Having such setup results in a pretty funny behaviour: you do can run make but the progress widget always reports the same percentage. I was at 83% from start to finish. Pretty puzzling :) The above was with cmake version 2.8.1. Could any one point where is the problem? CMake misuse or bug indeed? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net -- 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 Sounds to me like somebody ran cmake as root, and then ran it again as non-root... Choose non-root and be consistent. There's absolutely no reason to run cmake as root, ever. I don't think there's a CMake bug here, but if you can come up with steps to reproduce the problem without running CMake as root, then we'll investigate further. HTH, 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
Re: [CMake] Progress report strange behaviour with mixed file permissions
On 13 January 2012 11:30, David Cole david.c...@kitware.com wrote: On Fri, Jan 13, 2012 at 5:48 AM, Mateusz Loskot mate...@loskot.net wrote: A friend of mine has asked me to confirm if there may be a bug in CMake related to file permissions on Unix. Here is the story: There are some files under CMakeFiles/ directory owned by root and not overridable by strk (non-root user). Having such setup results in a pretty funny behaviour: you do can run make but the progress widget always reports the same percentage. I was at 83% from start to finish. Pretty puzzling :) The above was with cmake version 2.8.1. Could any one point where is the problem? CMake misuse or bug indeed? Sounds to me like somebody ran cmake as root, and then ran it again as non-root... Choose non-root and be consistent. There's absolutely no reason to run cmake as root, ever. I don't think there's a CMake bug here, but if you can come up with steps to reproduce the problem without running CMake as root, then we'll investigate further. David Daniel, thanks! I'll confirm with my friend and follow-up if needed. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net -- 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] MSBuild and automatic project file regenation
On 01/10/2012 07:09 PM, Óscar Fuentes wrote: Michael Hertling mhertl...@online.de writes: But aren't the issues related at least? Dunno. If I understand correctly, cmake --build invokes MSBuild which - loads the solution file and the project files, - reinvokes CMake via the ZERO_CHECK project/target to regenerate them if CMakeLists.txt has been modified, - does *not* use the regenerated ones for building, so the affected projects/targets are left inherently out-of-date. Yep. Moreover, even an additional subsequent cmake --build command doesn't rebuild; in fact, it does nothing, as though there is no dependency of a project/target on its own project file. That doesn't happen here. The next cmake --build works fine (cmake 2.8.4, VS 10) With CMake 2.8.7 and VS 2008, I can report the following findings: (1) Starting out from within an empty build directory: cmake .. followed by cmake --build . configures/builds as expected. (2) Tweaking CMakeLists.txt file only and leaving sources alone. (3) cmake --build . rebuilds the ZERO_CHECK target and, thus, updates the project file to reflect the changes from (2). However, the corresponding target is not rebuilt and, thus, does not reflect the changes from (2). (4) A further cmake --build . does *nothing* - definitely. (5) To get the concerned target rebuilt, I need to apply David's hint, i.e. cmake . cmake --build ., or clean first, i.e. cmake --build . --clean-first. As I've already said previously, this seems as if there's no dependency of the target on its own project file. Moreover, I don't understand why rebuilding the ZERO_CHECK project and reconfiguring with cmake . do obviously have different results - the latter makes cmake --build . rebuild, the former doesn't. If I understand correctly, the purpose of ZERO_CHECK is to rerun CMake in order to update the project files, so the cmake --build . from (4) - at the lastest - should rebuild the affected targets. AFAICS for now, it's solely David's hint, i.e. cmake . cmake --build ., that results in the project being actually rebuilt after CMakeLists.txt has changed, unless one uses the --clean-first option. If so, I would strongly support a feature request in this respect since, IMO, it's actually quite confusing that CMake's --build command does anything but rebuilding. I agree. Do you file a feature request / bug report? Nope. Personally, I'd like to be sure that after a cmake --build command, everything is up-to-date as it is with Makefiles, provided it can be realized with MSBuild at all. Obviously, how MSBuild works when the project files are regenerated on the fly is a bug. I have no idea about how hard is to fix it, though. Try http://www.cmake.org/pipermail/cmake/2011-November/047802.html. Hmmm... After reading your example, I can't say for sure that when `cmake --build' worked the second time here it didn't cointain changes on the source files too. CMake with VS 10 and/or MSBuild is pesky, apart from the problems MSBuild has on its own. I'm looking at using other generators that support parallel builds. JOM is not truly parallel (it only builds a toplevel target at once). Ninja looks like the right thing, but doesn't work on MS Windows. Perhaps, David Cole can give us some enlightenment; since he used to work for MS, he certainly has some intimate insights into the Visual World. ;-) Anyway, this issue is no catastrophe, provided one knows the trick with cmake . cmake --build ., but it is annoying and error-prone; usually, I'd expect that after cmake --build, every- thing is up-to-date. BTW, does cmake --build work correctly in this regard with other non-Makefile generators, notably XCode? 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] MSBuild and automatic project file regenation
On 1/13/2012 9:10 AM, Michael Hertling wrote: With CMake 2.8.7 and VS 2008, I can report the following findings: (1) Starting out from within an empty build directory: cmake .. followed by cmake --build . configures/builds as expected. (2) Tweaking CMakeLists.txt file only and leaving sources alone. (3) cmake --build . rebuilds the ZERO_CHECK target and, thus, updates the project file to reflect the changes from (2). However, the corresponding target is not rebuilt and, thus, does not reflect the changes from (2). (4) A further cmake --build . does *nothing* - definitely. (5) To get the concerned target rebuilt, I need to apply David's hint, i.e. cmake . cmake --build ., or clean first, i.e. cmake --build . --clean-first. Can you provide an example and how to reproduce this? I find it hard to believe that cmake --build . cmake --build . will not build everything. I get that the ZERO_TARGET does not get things to reload, but I don't see how the second build would not get things up to date. It has nothing to do with the project files depending on the targets. I assume something really changed and there really needs to be a rebuild? What type of thing are you changing in the CMakeLists.txt? -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
Re: [CMake] Progress report strange behaviour with mixed file permissions
On 1/13/2012 6:41 AM, Mateusz Loskot wrote: David Daniel, thanks! I'll confirm with my friend and follow-up if needed. Best regards, My guess would be that someone did a sudo make install. That would be a reason why you might run make a root. But, you have to be consistent and always use the same user for the same build tree. -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
Re: [CMake] Custom configuration types in Visual Studio
On 01/12/2012 10:23 PM, Robert Dailey wrote:
I see there is documentation for this but it doesn't have an implementation
for VS generators:
http://www.cmake.org/Bug/view.php?id=5811
Any status updates on this bug? I'd like to be able to create my own debug
configuration called DebugStatic that uses the /MTd flag in all projects to
link statically against the Microsoft libraries such as CRT.
Any help?
Look at the following exemplary project:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(P C)
SET(CMAKE_CONFIGURATION_TYPES ${CMAKE_CONFIGURATION_TYPES} DebugStatic
CACHE STRING FORCE)
SET(CMAKE_C_FLAGS_DEBUGSTATIC /MTd
CACHE STRING FORCE)
SET(CMAKE_EXE_LINKER_FLAGS_DEBUGSTATIC
CACHE STRING FORCE)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return 0;}\n)
ADD_EXECUTABLE(main main.c)
After cmake srcdir and a subsequent cmake . from within the build
directory, I can see the DebugStatic configuration appear in the VS IDE
when the generated solution is opened. Is this what you intend?
However, I do not see DebugStatic when I open the solution right after
the initial configuration, i.e. without the reconfiguration step. Can
you confirm this behavior? Does anybody know why the reconfiguration
is necessary to make the custom configuration appear? This is with
CMake 2.8.7 and VS 2008.
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] Cmake coloring gcc output on errror
Thanks.
regards
Vivek Goel
On Wed, Jan 11, 2012 at 6:26 PM, Michael Wild them...@gmail.com wrote:
On 01/11/2012 01:44 PM, Michael Hertling wrote:
On 01/10/2012 07:17 PM, vivek goel wrote:
Is there a way to color warning/error of gcc with cmake ?
AFAIK, no, but you might remember the power of *nix, feed the output
of make VERBOSE=1 21 into sed/awk/perl/your-favorite-here and
use ANSI Control Sequence Initiators:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(P C)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){Return 0;}\n)
SET_SOURCE_FILES_PROPERTIES(main.c PROPERTIES COMPILE_FLAGS -Wall)
ADD_EXECUTABLE(main main.c)
% cmake srcdir
...
% make VERBOSE=1 21 | sed \
-e 's%^.*: error: .*$%\x1b[37;41m\x1b[m%' \
-e 's%^.*: warning: .*$%\x1b[30;43m\x1b[m%'
Regards,
Michael
Does colorgcc work with CMake? That would be a *lot* easier...
--
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
Re: [CMake] Custom configuration types in Visual Studio
On Fri, Jan 13, 2012 at 10:22 AM, Michael Hertling mhertl...@online.de wrote:
On 01/12/2012 10:23 PM, Robert Dailey wrote:
I see there is documentation for this but it doesn't have an implementation
for VS generators:
http://www.cmake.org/Bug/view.php?id=5811
Any status updates on this bug? I'd like to be able to create my own debug
configuration called DebugStatic that uses the /MTd flag in all projects to
link statically against the Microsoft libraries such as CRT.
Any help?
Look at the following exemplary project:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(P C)
SET(CMAKE_CONFIGURATION_TYPES ${CMAKE_CONFIGURATION_TYPES} DebugStatic
CACHE STRING FORCE)
SET(CMAKE_C_FLAGS_DEBUGSTATIC /MTd
CACHE STRING FORCE)
SET(CMAKE_EXE_LINKER_FLAGS_DEBUGSTATIC
CACHE STRING FORCE)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return 0;}\n)
ADD_EXECUTABLE(main main.c)
After cmake srcdir and a subsequent cmake . from within the build
directory, I can see the DebugStatic configuration appear in the VS IDE
when the generated solution is opened. Is this what you intend?
However, I do not see DebugStatic when I open the solution right after
the initial configuration, i.e. without the reconfiguration step. Can
you confirm this behavior? Does anybody know why the reconfiguration
is necessary to make the custom configuration appear? This is with
CMake 2.8.7 and VS 2008.
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
I don't know why it doesn't appear straight away, (although I suspect
it's because the variable is set after the project command)
But you should never do this unconditionally:
SET(CMAKE_CONFIGURATION_TYPES ${CMAKE_CONFIGURATION_TYPES} DebugStatic
CACHE STRING FORCE)
That will simply continuously append to the variable in the cache, and
it will grow on each subsequent configure in the same build tree...
Real code should check whether DebugStatic is in there already, and
avoiding appending if already present.
HTH,
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] CHECK_C_COMPILER_FLAG (very) broken with icc!
Hi, I'm using the Intel Compiler v12 and to have a robust build generator, before adding flags to CFLAGS I test them. The following buggy behavior exists in CMake up to v2.8.7: - As Intel issues icc: command line warning #10006: ignoring unknown option '-asdf' type warnings which are not handled in CHECK_C_COMPILER_FLAG, checking CFLAGS is completely broken (also reported in bugreport #12576). - However, checking for -openmp still returns false! Any idea why does this happen? I can write a custom CHECK_C_COMPILER_FLAG which includes a check for the icc, but I've no clue why the -openmp check doesn't work. Additionally, IMHO it's quite unfortunate that such a widely used compiler as the Intel Compiler has such flaky support in CMake. I would rather like to see a more limited feature set, but a well tested and robust one. Cheers, -- Szilárd -- 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] CHECK_C_COMPILER_FLAG (very) broken with icc!
On Fri, 13 Jan 2012 17:54:23 +0100, Szilárd Páll said: Additionally, IMHO it's quite unfortunate that such a widely used compiler as the Intel Compiler has such flaky support in CMake. Searching today's dashboard for icc, I see only 1 entry: http://www.cdash.org/CDash/index.php?project=CMake I'm sure the community would benefit from additional submissions. icc costs money, making it harder... -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada -- 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] CHECK_C_COMPILER_FLAG (very) broken with icc!
On Fri, Jan 13, 2012 at 12:23 PM, Sean McBride s...@rogue-research.com wrote: On Fri, 13 Jan 2012 17:54:23 +0100, Szilárd Páll said: Additionally, IMHO it's quite unfortunate that such a widely used compiler as the Intel Compiler has such flaky support in CMake. Searching today's dashboard for icc, I see only 1 entry: http://www.cdash.org/CDash/index.php?project=CMake I'm sure the community would benefit from additional submissions. icc costs money, making it harder... -- Sean McBride, B. Eng s...@rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montréal, Québec, Canada -- 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 The Intel 11.1 compiler is used (search for icl) for two of our dash2win64 dashboards as well... -- 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] MSBuild and automatic project file regenation
On 01/13/2012 03:42 PM, Bill Hoffman wrote:
On 1/13/2012 9:10 AM, Michael Hertling wrote:
With CMake 2.8.7 and VS 2008, I can report the following findings:
(1) Starting out from within an empty build directory: cmake ..
followed by cmake --build . configures/builds as expected.
(2) Tweaking CMakeLists.txt file only and leaving sources alone.
(3) cmake --build . rebuilds the ZERO_CHECK target and, thus,
updates the project file to reflect the changes from (2).
However, the corresponding target is not rebuilt and,
thus, does not reflect the changes from (2).
(4) A further cmake --build . does *nothing* - definitely.
(5) To get the concerned target rebuilt, I need to apply
David's hint, i.e. cmake . cmake --build ., or
clean first, i.e. cmake --build . --clean-first.
Can you provide an example and how to reproduce this?
I find it hard to believe that
cmake --build .
cmake --build .
will not build everything.
I get that the ZERO_TARGET does not get things to reload, but I don't
see how the second build would not get things up to date. It has
nothing to do with the project files depending on the targets. I assume
something really changed and there really needs to be a rebuild? What
type of thing are you changing in the CMakeLists.txt?
-Bill
Look at the following exemplary project:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(BUILD C)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c
#include stdio.h
int main(void)
{
printf(\%d\\n\,NUMBER); return 0;
}
)
ADD_EXECUTABLE(main main.c)
SET_TARGET_PROPERTIES(main PROPERTIES
COMPILE_DEFINITIONS NUMBER=0)
Steps to reproduce with CMake 2.8.7 and VS 2008:
(1) From within an empty build directory: cmake srcdir followed
by cmake --build . configures/builds correctly; Debug\main
yields 0 as expected.
(2) At the end of CMakeLists.txt, change NUMBER=0 to NUMBER=1.
(3) cmake --build . triggers the ZERO_CHECK target, regenerates
main.vcproj but doesn't use the latter for rebuilding main.
Accordingly, Debug\main still yields 0.
Assuming that MSBuild/devenv/whatever doesn't load the re-
generated project file into the currently running instance,
I can well understand this behavior, but:
(4) A further cmake --build . does nothing; in particular, it
does not rebuild main, and Debug\main still yields 0.
Here, I'd expect that the regenerated project file is
loaded and the associated target rebuilt.
(5) Rebuilding the main target can be achieved via David's hint
cmake . cmake --build . or by cleaning before, e.g. via
cmake --build . --clean-first. Afterwards, Debug\main
finally yields 1.
For additional information, if one modifies the main.vcproj file by
hand, a subsequent cmake --build . also does nothing, as well as
msbuild BUILD.sln /t:main or msbuild main.vcproj.
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
[CMake] CTest continuous testing
Hi,
We have a test case suite setup to run in continuous mode and submit to CDash.
I followed instructions on the wiki
(http://www.cmake.org/Wiki/CMake_Scripting_Of_CTest#Continuous_Builds_.28new_Style.29)
and have a script that's below the signature.
I was under the impression that continuous testing would run once when it
started each run, then sleep and check for changed files and if nothing
changed, go back to sleep and wait again, then check again, etc.. And if files
did change and ctest_update() pulled in new code, the tests would run again.
However, the behavior I am getting is that the entire test suite is run every 5
minutes for the entire continuous run time, even though no files are being
updated. Some of the tests are failing, if that makes a difference.
Was I mistaken on how it works? Or did I miss a step somewhere? Thanks,
Tim
---
while(${CTEST_ELAPSED_TIME} LESS 43200)
set(START_TIME ${CTEST_ELAPSED_TIME})
ctest_start(Continuous)
ctest_update()
# Copy over the files we need
configure_file(${CTEST_REPO_DIRECTORY}/CTest/CTestCustom.cmake
${CTEST_REPO_DIRECTORY}/CTestCustom.cmake @ONLY)
configure_file(${CTEST_REPO_DIRECTORY}/CTest/CTestTestfile.cmake
${CTEST_REPO_DIRECTORY}/CTestTestfile.cmake @ONLY)
configure_file(${CTEST_REPO_DIRECTORY}/CTest/CTestAvailableTests.cmake
${CTEST_REPO_DIRECTORY}/CTestAvailableTests.cmake @ONLY)
configure_file(${CTEST_REPO_DIRECTORY}/CTest/runPythonTest.sh.in
${CTEST_REPO_DIRECTORY}/runPythonTest.sh @ONLY)
include(${CTEST_REPO_DIRECTORY}/CTestAvailableTests.cmake)
foreach(TESTCASE ${LESLIE_AVAILABLE_TESTCASES})
set(CTEST_CONFIGURE_COMMAND ./setup.py -t ${TESTCASE}
'{${LESLIE_CONFIGURE_DICT_BASE}}')
ctest_configure(BUILD ${CTEST_REPO_DIRECTORY} APPEND)
set(CTEST_BUILD_COMMAND ./setup.py -t ${TESTCASE}
'{${LESLIE_BUILD_DICT_BASE}}')
ctest_build(BUILD ${CTEST_REPO_DIRECTORY} APPEND)
endforeach()
list(LENGTH LESLIE_CUSTOM_TESTCASE_BASE len1)
math(EXPR len2 ${len1} - 1)
foreach(value RANGE ${len2})
list(GET LESLIE_CUSTOM_TESTCASE_BASE ${value} TESTCASE_BASE)
list(GET LESLIE_CUSTOM_TESTCASE_CONFIG_DICT ${value} TESTCASE_CONFIG)
list(GET LESLIE_CUSTOM_TESTCASE_BUILD_DICT ${value} TESTCASE_BUILD)
set(CTEST_CONFIGURE_COMMAND ./setup.py -t ${TESTCASE_BASE}
${TESTCASE_CONFIG})
ctest_configure(BUILD ${CTEST_REPO_DIRECTORY} APPEND)
set(CTEST_BUILD_COMMAND ./setup.py -t ${TESTCASE_BASE} ${TESTCASE_BUILD})
ctest_build(BUILD ${CTEST_REPO_DIRECTORY} APPEND)
endforeach()
ctest_test(BUILD ${CTEST_REPO_DIRECTORY})
ctest_submit()
ctest_sleep(${START_TIME} 300 ${CTEST_ELAPSED_TIME})
endwhile()
--
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] CHECK_C_COMPILER_FLAG (very) broken with icc!
On Fri, Jan 13, 2012 at 6:23 PM, Sean McBride s...@rogue-research.com wrote: On Fri, 13 Jan 2012 17:54:23 +0100, Szilárd Páll said: Additionally, IMHO it's quite unfortunate that such a widely used compiler as the Intel Compiler has such flaky support in CMake. Searching today's dashboard for icc, I see only 1 entry: http://www.cdash.org/CDash/index.php?project=CMake I'm sure the community would benefit from additional submissions. icc costs money, making it harder... Sure, I understand that -- although Kitware isn't really a group of free-time OSS coders... Also, I wouldn't have even considered the poor Intel Compiler support unfortunate if I didn't think that CMake tends to compromise when it comes to robustness of implementations. It is no fun to have to test across all *patch versions* of CMake with dozens of configurations :) I could pitch in with running a few Dashboard submissions using Intel Compiler on Linux if that helps, but I doubt I can dedicate a machine for long-term contribution. Cheers, -- Szilárd -- Sean McBride, B. Eng s...@rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montréal, Québec, Canada -- 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
Re: [CMake] CTest continuous testing
See the cmake_common.cmake script (as seen here on a CMake Continuous
dashboard, and in other places):
http://cdash.org/CDash/viewNotes.php?buildid=1911520
Notice that it does:
ctest_update(RETURN_VALUE count)
and then checks whether count is 0 or not. It only does stuff if
count 0 or it's the first time, or it's not a continuous
dashboard...
You need logic like that, and do not execute the configure/build/test
steps when nothing came back from the update...
HTH,
David
On Fri, Jan 13, 2012 at 2:11 PM, Tim Gallagher tim.gallag...@gatech.edu wrote:
Hi,
We have a test case suite setup to run in continuous mode and submit to
CDash. I followed instructions on the wiki
(http://www.cmake.org/Wiki/CMake_Scripting_Of_CTest#Continuous_Builds_.28new_Style.29)
and have a script that's below the signature.
I was under the impression that continuous testing would run once when it
started each run, then sleep and check for changed files and if nothing
changed, go back to sleep and wait again, then check again, etc.. And if
files did change and ctest_update() pulled in new code, the tests would run
again.
However, the behavior I am getting is that the entire test suite is run every
5 minutes for the entire continuous run time, even though no files are being
updated. Some of the tests are failing, if that makes a difference.
Was I mistaken on how it works? Or did I miss a step somewhere? Thanks,
Tim
---
while(${CTEST_ELAPSED_TIME} LESS 43200)
set(START_TIME ${CTEST_ELAPSED_TIME})
ctest_start(Continuous)
ctest_update()
# Copy over the files we need
configure_file(${CTEST_REPO_DIRECTORY}/CTest/CTestCustom.cmake
${CTEST_REPO_DIRECTORY}/CTestCustom.cmake @ONLY)
configure_file(${CTEST_REPO_DIRECTORY}/CTest/CTestTestfile.cmake
${CTEST_REPO_DIRECTORY}/CTestTestfile.cmake @ONLY)
configure_file(${CTEST_REPO_DIRECTORY}/CTest/CTestAvailableTests.cmake
${CTEST_REPO_DIRECTORY}/CTestAvailableTests.cmake @ONLY)
configure_file(${CTEST_REPO_DIRECTORY}/CTest/runPythonTest.sh.in
${CTEST_REPO_DIRECTORY}/runPythonTest.sh @ONLY)
include(${CTEST_REPO_DIRECTORY}/CTestAvailableTests.cmake)
foreach(TESTCASE ${LESLIE_AVAILABLE_TESTCASES})
set(CTEST_CONFIGURE_COMMAND ./setup.py -t ${TESTCASE}
'{${LESLIE_CONFIGURE_DICT_BASE}}')
ctest_configure(BUILD ${CTEST_REPO_DIRECTORY} APPEND)
set(CTEST_BUILD_COMMAND ./setup.py -t ${TESTCASE}
'{${LESLIE_BUILD_DICT_BASE}}')
ctest_build(BUILD ${CTEST_REPO_DIRECTORY} APPEND)
endforeach()
list(LENGTH LESLIE_CUSTOM_TESTCASE_BASE len1)
math(EXPR len2 ${len1} - 1)
foreach(value RANGE ${len2})
list(GET LESLIE_CUSTOM_TESTCASE_BASE ${value} TESTCASE_BASE)
list(GET LESLIE_CUSTOM_TESTCASE_CONFIG_DICT ${value} TESTCASE_CONFIG)
list(GET LESLIE_CUSTOM_TESTCASE_BUILD_DICT ${value} TESTCASE_BUILD)
set(CTEST_CONFIGURE_COMMAND ./setup.py -t ${TESTCASE_BASE}
${TESTCASE_CONFIG})
ctest_configure(BUILD ${CTEST_REPO_DIRECTORY} APPEND)
set(CTEST_BUILD_COMMAND ./setup.py -t ${TESTCASE_BASE} ${TESTCASE_BUILD})
ctest_build(BUILD ${CTEST_REPO_DIRECTORY} APPEND)
endforeach()
ctest_test(BUILD ${CTEST_REPO_DIRECTORY})
ctest_submit()
ctest_sleep(${START_TIME} 300 ${CTEST_ELAPSED_TIME})
endwhile()
--
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
Re: [CMake] CTest continuous testing
The devil is always in the little details. That does the trick nicely, thanks!
Tim
- Original Message -
From: David Cole david.c...@kitware.com
To: gtg0...@mail.gatech.edu
Cc: cmake@cmake.org
Sent: Friday, January 13, 2012 2:37:29 PM
Subject: Re: [CMake] CTest continuous testing
See the cmake_common.cmake script (as seen here on a CMake Continuous
dashboard, and in other places):
http://cdash.org/CDash/viewNotes.php?buildid=1911520
Notice that it does:
ctest_update(RETURN_VALUE count)
and then checks whether count is 0 or not. It only does stuff if
count 0 or it's the first time, or it's not a continuous
dashboard...
You need logic like that, and do not execute the configure/build/test
steps when nothing came back from the update...
HTH,
David
On Fri, Jan 13, 2012 at 2:11 PM, Tim Gallagher tim.gallag...@gatech.edu wrote:
Hi,
We have a test case suite setup to run in continuous mode and submit to
CDash. I followed instructions on the wiki
(http://www.cmake.org/Wiki/CMake_Scripting_Of_CTest#Continuous_Builds_.28new_Style.29)
and have a script that's below the signature.
I was under the impression that continuous testing would run once when it
started each run, then sleep and check for changed files and if nothing
changed, go back to sleep and wait again, then check again, etc.. And if
files did change and ctest_update() pulled in new code, the tests would run
again.
However, the behavior I am getting is that the entire test suite is run every
5 minutes for the entire continuous run time, even though no files are being
updated. Some of the tests are failing, if that makes a difference.
Was I mistaken on how it works? Or did I miss a step somewhere? Thanks,
Tim
---
while(${CTEST_ELAPSED_TIME} LESS 43200)
set(START_TIME ${CTEST_ELAPSED_TIME})
ctest_start(Continuous)
ctest_update()
# Copy over the files we need
configure_file(${CTEST_REPO_DIRECTORY}/CTest/CTestCustom.cmake
${CTEST_REPO_DIRECTORY}/CTestCustom.cmake @ONLY)
configure_file(${CTEST_REPO_DIRECTORY}/CTest/CTestTestfile.cmake
${CTEST_REPO_DIRECTORY}/CTestTestfile.cmake @ONLY)
configure_file(${CTEST_REPO_DIRECTORY}/CTest/CTestAvailableTests.cmake
${CTEST_REPO_DIRECTORY}/CTestAvailableTests.cmake @ONLY)
configure_file(${CTEST_REPO_DIRECTORY}/CTest/runPythonTest.sh.in
${CTEST_REPO_DIRECTORY}/runPythonTest.sh @ONLY)
include(${CTEST_REPO_DIRECTORY}/CTestAvailableTests.cmake)
foreach(TESTCASE ${LESLIE_AVAILABLE_TESTCASES})
set(CTEST_CONFIGURE_COMMAND ./setup.py -t ${TESTCASE}
'{${LESLIE_CONFIGURE_DICT_BASE}}')
ctest_configure(BUILD ${CTEST_REPO_DIRECTORY} APPEND)
set(CTEST_BUILD_COMMAND ./setup.py -t ${TESTCASE}
'{${LESLIE_BUILD_DICT_BASE}}')
ctest_build(BUILD ${CTEST_REPO_DIRECTORY} APPEND)
endforeach()
list(LENGTH LESLIE_CUSTOM_TESTCASE_BASE len1)
math(EXPR len2 ${len1} - 1)
foreach(value RANGE ${len2})
list(GET LESLIE_CUSTOM_TESTCASE_BASE ${value} TESTCASE_BASE)
list(GET LESLIE_CUSTOM_TESTCASE_CONFIG_DICT ${value} TESTCASE_CONFIG)
list(GET LESLIE_CUSTOM_TESTCASE_BUILD_DICT ${value} TESTCASE_BUILD)
set(CTEST_CONFIGURE_COMMAND ./setup.py -t ${TESTCASE_BASE}
${TESTCASE_CONFIG})
ctest_configure(BUILD ${CTEST_REPO_DIRECTORY} APPEND)
set(CTEST_BUILD_COMMAND ./setup.py -t ${TESTCASE_BASE} ${TESTCASE_BUILD})
ctest_build(BUILD ${CTEST_REPO_DIRECTORY} APPEND)
endforeach()
ctest_test(BUILD ${CTEST_REPO_DIRECTORY})
ctest_submit()
ctest_sleep(${START_TIME} 300 ${CTEST_ELAPSED_TIME})
endwhile()
--
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
Re: [CMake] Top level directory with component install
2011/4/27 Eric Noulard eric.noul...@gmail.com: 2011/4/27 Daniel Nelson tor...@connect2.com: On Wed, Apr 27, 2011 at 08:49:56PM +0200, Eric Noulard wrote: 2011/4/27 Daniel Nelson tor...@connect2.com: I am using CPACK_ARCHIVE_COMPONENT_INSTALL to create separate tar files for each component, but when I enable it I no longer have a top level directory in the tar. For example, if archive component install is off then the tar files contains files with paths like foobar-1.2.3-Linux-x86_64/bin/foobar, but with component install on the paths are just bin/foobar. I tried turning CPACK_INCLUDE_TOPLEVEL_DIRECTORY on but it doesn't seem to help. Is this behavior on purpose and if so is it possible to change? This was not intentional, this is not really a bug because the component splitting wasn't available before but you can file a bug and we'll discuss what to do. Which version of CMake are you using? I'm using 2.8.4 from debian. Added an issue: http://public.kitware.com/Bug/view.php?id=12129 If it will help I could probably prepare a patch this weekend. Off course, yes it will. Please attach it to the bug report I'll review it. Thanks. Hi everybody I just reviewed the patch from Daniel and it seems fine to me BUT including this would change the default cpack behavior for all Archive Generators (ZIP, TGZ, STGZ, TBZ2) when doing component install. The new behavior is more consistent with the non-component behavior but the two has been different since 2.8.4 so I'd like to know whether if people are relying on it or if we may change such default behavior which may be viewed as flawed... Please have a look at: http://public.kitware.com/Bug/view.php?id=12129 and comment here. I'd like to have feedback before pushing this to next. Currently it is in stage/AddTopLevelForComponent. -- 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
[CMake] GCC compiler version
Is there a CMake variable for the GCC compiler version if using GCC? I thought I remember seeing email traffic about something along these lines a while back, but I can't find the email or documentation describing it (if it exists). Thanks, James -- 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] GCC compiler version
Brad's recently committed and merged to next a topic that does just that. See the commits in this view: gitk e0bc42aa4ff086e9c6976ab91ba924530df0bf72..0df1942a72f1e67c88f0d02dc405fbd76793347a If you are using next, you can inspect the variables CMAKE_C_COMPILER_VERSION and CMAKE_CXX_COMPILER_VERSION, after a project or enable_language command. It will likely first appear in the upcoming CMake 2.8.8... HTH, David On Fri, Jan 13, 2012 at 4:39 PM, James Bigler jamesbig...@gmail.com wrote: Is there a CMake variable for the GCC compiler version if using GCC? I thought I remember seeing email traffic about something along these lines a while back, but I can't find the email or documentation describing it (if it exists). Thanks, James -- 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] CPack-NSIS component-based installer lacking components page...might I be forgetting something?
Hi, I'm using CMake 2.8.6 to generate an NSIS installer. We have two separate projects; an application and a set of plugins to be used by the application. The plugins are composed of four separate components that can be selected during the installation (Filters, NonBSDPlugins, Readers, Writers). When built on its own, the plugins installer includes the 'Select Components' page as expected. When building the application, which also includes the plugins project, no components page appears. My CPackConfig.cmake file has the following: SET(CPACK_COMPONENTS_ALL BrandedRuntime;Development;Filters;NonBSDPlugins;Readers;Writers;Runtime;RuntimeLibraries;Unspecified) SET(CPACK_COMPONENT_UNSPECIFIED_HIDDEN TRUE) SET(CPACK_COMPONENT_UNSPECIFIED_REQUIRED TRUE) Am I missing anything blatantly obvious? I'm quite stuck and haven't been able to find anyone who's had a similar problem. I can provide more details if necessary...apologies if I haven't included enough. -- Patrick -- 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] CPack-NSIS component-based installer lacking components page...might I be forgetting something?
2012/1/13 Patrick Ryan pr...@objectivity.ca: Hi, I'm using CMake 2.8.6 to generate an NSIS installer. We have two separate projects; an application and a set of plugins to be used by the application. The plugins are composed of four separate components that can be selected during the installation (Filters, NonBSDPlugins, Readers, Writers). When built on its own, the plugins installer includes the 'Select Components' page as expected. When building the application, which also includes the plugins project, no components page appears. How does the application includes the plugins project? My CPackConfig.cmake file has the following: SET(CPACK_COMPONENTS_ALL BrandedRuntime;Development;Filters;NonBSDPlugins;Readers;Writers;Runtime;RuntimeLibraries;Unspecified) SET(CPACK_COMPONENT_UNSPECIFIED_HIDDEN TRUE) SET(CPACK_COMPONENT_UNSPECIFIED_REQUIRED TRUE) Am I missing anything blatantly obvious? I'm quite stuck and haven't been able to find anyone who's had a similar problem. CPack does not work that well for multiple project in one package installer. see discussion here http://public.kitware.com/Bug/view.php?id=11808 I can provide more details if necessary...apologies if I haven't included enough. Was your CPackConfig.cmake written by hand or generated with include(CPack) ? Did you include(CPack) twice? Like one time in the application project and one time in the plugins project? If yes tries to include it only once. see related bugs with multiple CPack inclusion: http://public.kitware.com/Bug/view.php?id=10751 -- 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] Custom configuration types in Visual Studio
On 01/13/2012 05:06 PM, David Cole wrote:
On Fri, Jan 13, 2012 at 10:22 AM, Michael Hertling mhertl...@online.de
wrote:
On 01/12/2012 10:23 PM, Robert Dailey wrote:
I see there is documentation for this but it doesn't have an implementation
for VS generators:
http://www.cmake.org/Bug/view.php?id=5811
Any status updates on this bug? I'd like to be able to create my own debug
configuration called DebugStatic that uses the /MTd flag in all projects to
link statically against the Microsoft libraries such as CRT.
Any help?
Look at the following exemplary project:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(P C)
SET(CMAKE_CONFIGURATION_TYPES ${CMAKE_CONFIGURATION_TYPES} DebugStatic
CACHE STRING FORCE)
SET(CMAKE_C_FLAGS_DEBUGSTATIC /MTd
CACHE STRING FORCE)
SET(CMAKE_EXE_LINKER_FLAGS_DEBUGSTATIC
CACHE STRING FORCE)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return 0;}\n)
ADD_EXECUTABLE(main main.c)
After cmake srcdir and a subsequent cmake . from within the build
directory, I can see the DebugStatic configuration appear in the VS IDE
when the generated solution is opened. Is this what you intend?
However, I do not see DebugStatic when I open the solution right after
the initial configuration, i.e. without the reconfiguration step. Can
you confirm this behavior? Does anybody know why the reconfiguration
is necessary to make the custom configuration appear? This is with
CMake 2.8.7 and VS 2008.
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
I don't know why it doesn't appear straight away, (although I suspect
it's because the variable is set after the project command)
Yes, that's it; placing the SET() command for CMAKE_CONFIGURATION_TYPES
before PROJECT() makes the new configuration appear at once, but it is
*solely* the new one. Apparently, CMake's standard configurations are
defined by PROJECT() only if there aren't already any configurations
in the cache. A working alternative is to drop the language(s) from
PROJECT(), augment the list of configurations thereafter and use
ENABLE_LANGUAGE() finally, i.e.:
PROJECT(XYZ) # -- No language(s) here!
LIST(APPEND CMAKE_CONFIGURATION_TYPES ...)
LIST(REMOVE_DUPLICATES CMAKE_CONFIGURATION_TYPES)
SET(CMAKE_CONFIGURATION_TYPES ${CMAKE_CONFIGURATION_TYPES}
CACHE STRING CMake configuration types FORCE)
ENABLE_LANGUAGE(C)
But you should never do this unconditionally:
SET(CMAKE_CONFIGURATION_TYPES ${CMAKE_CONFIGURATION_TYPES} DebugStatic
CACHE STRING FORCE)
That will simply continuously append to the variable in the cache, and
it will grow on each subsequent configure in the same build tree...
Real code should check whether DebugStatic is in there already, and
avoiding appending if already present.
Uhhh... absolutely, bad mistake! Thanks for pointing this out.
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
[Cmake-commits] CMake branch, next, updated. v2.8.7-2082-g4992dfa
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 4992dfa97dadfba618992a4c57270fb6b5d501e9 (commit)
via 8e8672ccdbd6ddc9e0847cbab5b6d1dc6e95c5f7 (commit)
via 50edbf0f224e81cb85a0588d2495676efc3101f2 (commit)
via c89ee4a10f4de32bdffaa1f08f5455f0fc454731 (commit)
from 317fc87718745b28c78df1852b2b04c7b0800544 (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=4992dfa97dadfba618992a4c57270fb6b5d501e9
commit 4992dfa97dadfba618992a4c57270fb6b5d501e9
Merge: 317fc87 8e8672c
Author: Rolf Eike Beer e...@sf-mail.de
AuthorDate: Fri Jan 13 11:25:32 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Jan 13 11:25:32 2012 -0500
Merge topic 'openssl-version' into next
8e8672c FindOpenSSL: improve version number handling
50edbf0 KWSys Nightly Date Stamp
c89ee4a KWSys Nightly Date Stamp
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8e8672ccdbd6ddc9e0847cbab5b6d1dc6e95c5f7
commit 8e8672ccdbd6ddc9e0847cbab5b6d1dc6e95c5f7
Author: Rolf Eike Beer e...@sf-mail.de
AuthorDate: Thu Jan 12 19:29:39 2012 +0100
Commit: Rolf Eike Beer e...@sf-mail.de
CommitDate: Fri Jan 13 17:24:50 2012 +0100
FindOpenSSL: improve version number handling
First this fixes the bug that e.g. version 1.0.0 was shown as 1... When
pkg-config was used to find OpenSSL the header file was parsed for the
version
number even if pkg-config returned it already. Finally we also include the
patch level (i.e. the letter after the version number) in OPENSSL_VERSION.
diff --git a/Modules/FindOpenSSL.cmake b/Modules/FindOpenSSL.cmake
index af799d6..bff5af6 100644
--- a/Modules/FindOpenSSL.cmake
+++ b/Modules/FindOpenSSL.cmake
@@ -7,7 +7,7 @@
# OPENSSL_FOUND - system has the OpenSSL library
# OPENSSL_INCLUDE_DIR - the OpenSSL include directory
# OPENSSL_LIBRARIES - The libraries needed to use OpenSSL
-# OPENSSL_VERSION - This is set to $major.$minor.$revision (eg. 0.9.8)
+# OPENSSL_VERSION - This is set to $major.$minor.$revision$path (eg. 0.9.8s)
#=
# Copyright 2006-2009 Kitware, Inc.
@@ -216,16 +216,40 @@ ELSE(WIN32 AND NOT CYGWIN)
ENDIF(WIN32 AND NOT CYGWIN)
if (OPENSSL_INCLUDE_DIR)
- file(STRINGS ${OPENSSL_INCLUDE_DIR}/openssl/opensslv.h openssl_version_str
REGEX ^#define[\t ]+OPENSSL_VERSION_NUMBER[\t
]+0x[0-9][0-9][0-9][0-9][0-9][0-9].*)
+ if (_OPENSSL_VERSION)
+set(OPENSSL_VERSION ${_OPENSSL_VERSION})
+ else (_OPENSSL_VERSION)
+file(STRINGS ${OPENSSL_INCLUDE_DIR}/openssl/opensslv.h
openssl_version_str
+ REGEX ^#define[\t ]+OPENSSL_VERSION_NUMBER[\t
]+0x[0-9][0-9][0-9][0-9][0-9][0-9].*)
- string(REGEX REPLACE ^.*OPENSSL_VERSION_NUMBER[\t ]+0x([0-9]).*$ \\1
OPENSSL_VERSION_MAJOR ${openssl_version_str})
- string(REGEX REPLACE ^.*OPENSSL_VERSION_NUMBER[\t ]+0x[0-9]([0-9][0-9]).*$
\\1 OPENSSL_VERSION_MINOR ${openssl_version_str})
- string(REGEX REPLACE ^.*OPENSSL_VERSION_NUMBER[\t
]+0x[0-9][0-9][0-9]([0-9][0-9]).*$ \\1 OPENSSL_VERSION_PATCH
${openssl_version_str})
+# The version number is encoded as 0xMNNFFPPS: major minor fix patch status
+# The status gives if this is a developer or prerelease and is ignored
here.
+# Major, minor, and fix directly translate into the version numbers shown
in
+# the string. The patch field translates to the single character suffix
that
+# indicates the bug fix state, which 00 - nothing, 01 - a, 02 - b and so
+# on.
- string(REGEX REPLACE ^0 OPENSSL_VERSION_MINOR
${OPENSSL_VERSION_MINOR})
- string(REGEX REPLACE ^0 OPENSSL_VERSION_PATCH
${OPENSSL_VERSION_PATCH})
+string(REGEX REPLACE ^.*OPENSSL_VERSION_NUMBER[\t
]+0x([0-9a-f])([0-9a-f][0-9a-f])([0-9a-f][0-9a-f])([0-9a-f][0-9a-f])([0-9a-f]).*$
+ \\1;\\2;\\3;\\4;\\5 OPENSSL_VERSION_LIST ${openssl_version_str})
+list(GET OPENSSL_VERSION_LIST 0 OPENSSL_VERSION_MAJOR)
+list(GET OPENSSL_VERSION_LIST 1 OPENSSL_VERSION_MINOR)
+list(GET OPENSSL_VERSION_LIST 2 OPENSSL_VERSION_FIX)
+list(GET OPENSSL_VERSION_LIST 3 OPENSSL_VERSION_PATCH)
- set(OPENSSL_VERSION
${OPENSSL_VERSION_MAJOR}.${OPENSSL_VERSION_MINOR}.${OPENSSL_VERSION_PATCH})
+string(REGEX REPLACE ^0(.) \\1 OPENSSL_VERSION_MINOR
${OPENSSL_VERSION_MINOR})
+string(REGEX REPLACE ^0(.) \\1 OPENSSL_VERSION_FIX
${OPENSSL_VERSION_FIX})
+
+if (NOT OPENSSL_VERSION_PATCH STREQUAL 00)
+ # 96 is the ASCII code of 'a' minus 1
+ math(EXPR OPENSSL_VERSION_PATCH_ASCII ${OPENSSL_VERSION_PATCH} + 96)
+ # Once anyone knows how
[Cmake-commits] CMake branch, next, updated. v2.8.7-2088-g2ee866a
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 2ee866a2320722c485a1244163f9d7183b5e6d01 (commit) via d4a9e334d3d65b2d65097e7c202db52b4a9c0509 (commit) from 57a091d4475b63f5d8f3478c1f40d1b71a061d59 (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=2ee866a2320722c485a1244163f9d7183b5e6d01 commit 2ee866a2320722c485a1244163f9d7183b5e6d01 Merge: 57a091d d4a9e33 Author: Brad King brad.k...@kitware.com AuthorDate: Fri Jan 13 14:13:32 2012 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Fri Jan 13 14:13:32 2012 -0500 Merge topic 'cm-bzip2-header-issue-10950' into next d4a9e33 Include bzlib.h consistently across CMake build (#10950) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d4a9e334d3d65b2d65097e7c202db52b4a9c0509 commit d4a9e334d3d65b2d65097e7c202db52b4a9c0509 Author: Brad King brad.k...@kitware.com AuthorDate: Fri Jan 13 14:05:36 2012 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Fri Jan 13 14:05:36 2012 -0500 Include bzlib.h consistently across CMake build (#10950) Use the approach originally used in commit f91b3c1d (Add options to build with system utility libraries, 2006-10-19) for all other third-party libraries. Create a cm_bzlib.h header wrapper that robustly includes the header from the bzip2 library chosen for the CMake build (either builtin or system version). Include the header wrapper anywhere we need the API provided by bzlib.h. diff --git a/Utilities/cmThirdParty.h.in b/Utilities/cmThirdParty.h.in index daf8114..c824085 100644 --- a/Utilities/cmThirdParty.h.in +++ b/Utilities/cmThirdParty.h.in @@ -16,6 +16,7 @@ #cmakedefine CMAKE_USE_SYSTEM_CURL #cmakedefine CMAKE_USE_SYSTEM_EXPAT #cmakedefine CMAKE_USE_SYSTEM_ZLIB +#cmakedefine CMAKE_USE_SYSTEM_BZIP2 #cmakedefine CMAKE_USE_SYSTEM_LIBARCHIVE #cmakedefine CTEST_USE_XMLRPC diff --git a/Utilities/cmThirdParty.h.in b/Utilities/cm_bzlib.h similarity index 59% copy from Utilities/cmThirdParty.h.in copy to Utilities/cm_bzlib.h index daf8114..d1fffa1 100644 --- a/Utilities/cmThirdParty.h.in +++ b/Utilities/cm_bzlib.h @@ -1,6 +1,6 @@ /* CMake - Cross Platform Makefile Generator - Copyright 2000-2009 Kitware, Inc., Insight Software Consortium + Copyright 2000-2012 Kitware, Inc., Insight Software Consortium Distributed under the OSI-approved BSD License (the License); see accompanying file Copyright.txt for details. @@ -9,14 +9,15 @@ implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the License for more information. */ -#ifndef __cmThirdParty_h -#define __cmThirdParty_h +#ifndef __cm_bzlib_h +#define __cm_bzlib_h -/* Whether CMake is using its own utility libraries. */ -#cmakedefine CMAKE_USE_SYSTEM_CURL -#cmakedefine CMAKE_USE_SYSTEM_EXPAT -#cmakedefine CMAKE_USE_SYSTEM_ZLIB -#cmakedefine CMAKE_USE_SYSTEM_LIBARCHIVE -#cmakedefine CTEST_USE_XMLRPC +/* Use the bzip2 library configured for CMake. */ +#include cmThirdParty.h +#ifdef CMAKE_USE_SYSTEM_BZIP2 +# include bzlib.h +#else +# include cmbzip2/bzlib.h +#endif #endif diff --git a/Utilities/cmlibarchive/libarchive/archive_read_support_filter_bzip2.c b/Utilities/cmlibarchive/libarchive/archive_read_support_filter_bzip2.c index 8d5bd1c..af618b0 100644 --- a/Utilities/cmlibarchive/libarchive/archive_read_support_filter_bzip2.c +++ b/Utilities/cmlibarchive/libarchive/archive_read_support_filter_bzip2.c @@ -41,7 +41,7 @@ __FBSDID($FreeBSD$); #include unistd.h #endif #ifdef HAVE_BZLIB_H -#include bzlib.h +#include cm_bzlib.h #endif #include archive.h diff --git a/Utilities/cmlibarchive/libarchive/archive_read_support_format_7zip.c b/Utilities/cmlibarchive/libarchive/archive_read_support_format_7zip.c index 1580c92..2be2267 100644 --- a/Utilities/cmlibarchive/libarchive/archive_read_support_format_7zip.c +++ b/Utilities/cmlibarchive/libarchive/archive_read_support_format_7zip.c @@ -33,7 +33,7 @@ __FBSDID($FreeBSD$); #include stdlib.h #endif #ifdef HAVE_BZLIB_H -#include bzlib.h +#include cm_bzlib.h #endif #ifdef HAVE_LZMA_H #include lzma.h diff --git a/Utilities/cmlibarchive/libarchive/archive_read_support_format_xar.c b/Utilities/cmlibarchive/libarchive/archive_read_support_format_xar.c index 00f283d..0834e6f 100644 --- a/Utilities/cmlibarchive/libarchive/archive_read_support_format_xar.c +++ b/Utilities/cmlibarchive/libarchive/archive_read_support_format_xar.c @@ -39,7
[Cmake-commits] CMake branch, next, updated. v2.8.7-2090-g19c85b6
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 19c85b6c73f4274fd890b9c6f072010fb7c8c678 (commit)
via 57da498c3cbc6acdf47a8e3ea1d09e92b2fdf251 (commit)
from 2ee866a2320722c485a1244163f9d7183b5e6d01 (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=19c85b6c73f4274fd890b9c6f072010fb7c8c678
commit 19c85b6c73f4274fd890b9c6f072010fb7c8c678
Merge: 2ee866a 57da498
Author: Brad King brad.k...@kitware.com
AuthorDate: Fri Jan 13 14:24:08 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Jan 13 14:24:08 2012 -0500
Merge topic 'link-shared-depend-cycle-issue-12647' into next
57da498 Add macro to infrastructure for CMake-only tests
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=57da498c3cbc6acdf47a8e3ea1d09e92b2fdf251
commit 57da498c3cbc6acdf47a8e3ea1d09e92b2fdf251
Author: Brad King brad.k...@kitware.com
AuthorDate: Fri Jan 13 14:19:50 2012 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Fri Jan 13 14:19:50 2012 -0500
Add macro to infrastructure for CMake-only tests
All CMake-only tests will use the same basic form. Create an
add_CMakeOnly_test macro for it.
diff --git a/Tests/CMakeOnly/CMakeLists.txt b/Tests/CMakeOnly/CMakeLists.txt
index b3bdab8..e4ba53a 100644
--- a/Tests/CMakeOnly/CMakeLists.txt
+++ b/Tests/CMakeOnly/CMakeLists.txt
@@ -1,8 +1,12 @@
configure_file(${CMAKE_CURRENT_SOURCE_DIR}/Test.cmake.in
${CMAKE_CURRENT_BINARY_DIR}/Test.cmake @ONLY)
-add_test(CMakeOnly.LinkInterfaceLoop ${CMAKE_CMAKE_COMMAND}
- -DTEST=LinkInterfaceLoop
- -P ${CMAKE_CURRENT_BINARY_DIR}/Test.cmake
- )
+macro(add_CMakeOnly_test test)
+ add_test(CMakeOnly.${test} ${CMAKE_CMAKE_COMMAND}
+-DTEST=${test}
+-P ${CMAKE_CURRENT_BINARY_DIR}/Test.cmake
+)
+endmacro()
+
+add_CMakeOnly_test(LinkInterfaceLoop)
set_property(TEST CMakeOnly.LinkInterfaceLoop PROPERTY TIMEOUT 90)
---
Summary of changes:
Tests/CMakeOnly/CMakeLists.txt | 12
1 files changed, 8 insertions(+), 4 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.7-2093-g3eb4815
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 3eb481524b5c7e4fdbd668431576ff912756e226 (commit)
via 8e756d2b9bb84b182a8402e71fb62d7a28d0a9c6 (commit)
via 9a20abf04a7fc11b53beb545f1555fe9815ae09c (commit)
from 19c85b6c73f4274fd890b9c6f072010fb7c8c678 (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=3eb481524b5c7e4fdbd668431576ff912756e226
commit 3eb481524b5c7e4fdbd668431576ff912756e226
Merge: 19c85b6 8e756d2
Author: Brad King brad.k...@kitware.com
AuthorDate: Fri Jan 13 14:24:42 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Jan 13 14:24:42 2012 -0500
Merge topic 'link-shared-depend-cycle-issue-12647' into next
8e756d2 Tolerate cycles in shared library link interfaces (#12647)
9a20abf Add infrastructure for CMake-only tests
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8e756d2b9bb84b182a8402e71fb62d7a28d0a9c6
commit 8e756d2b9bb84b182a8402e71fb62d7a28d0a9c6
Author: Brad King brad.k...@kitware.com
AuthorDate: Thu Jan 12 10:22:00 2012 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Fri Jan 13 14:22:24 2012 -0500
Tolerate cycles in shared library link interfaces (#12647)
Since commit 183b9509 (Follow all dependencies of shared library private
dependencies, 2011-12-14) we honor LINK_INTERFACE_LIBRARIES when
following dependent shared libraries. The link interface properties may
form a cycle if set incorrectly by a project. Furthermore, the property
LINK_DEPENDENT_LIBRARIES may form a cycle if set incorrectly by hand
(though CMake should never generate one). In either case, do not follow
the cycle forever when following the dependent shared library closure.
We only need to add dependency edges to the constraint graph once.
Add LinkInterfaceLoop test to cover this case.
diff --git a/Source/cmComputeLinkDepends.cxx b/Source/cmComputeLinkDepends.cxx
index 802cfcf..9a075bd 100644
--- a/Source/cmComputeLinkDepends.cxx
+++ b/Source/cmComputeLinkDepends.cxx
@@ -358,7 +358,7 @@ void cmComputeLinkDepends::FollowLinkEntry(BFSEntry const
qe)
this-AddLinkEntries(depender_index, iface-Libraries);
// Handle dependent shared libraries.
- this-QueueSharedDependencies(depender_index, iface-SharedDeps);
+ this-FollowSharedDeps(depender_index, iface);
// Support for CMP0003.
for(std::vectorstd::string::const_iterator
@@ -379,6 +379,23 @@ void cmComputeLinkDepends::FollowLinkEntry(BFSEntry const
qe)
//
void
cmComputeLinkDepends
+::FollowSharedDeps(int depender_index, cmTarget::LinkInterface const* iface,
+ bool follow_interface)
+{
+ // Follow dependencies if we have not followed them already.
+ if(this-SharedDepFollowed.insert(depender_index).second)
+{
+if(follow_interface)
+ {
+ this-QueueSharedDependencies(depender_index, iface-Libraries);
+ }
+this-QueueSharedDependencies(depender_index, iface-SharedDeps);
+}
+}
+
+//
+void
+cmComputeLinkDepends
::QueueSharedDependencies(int depender_index,
std::vectorstd::string const deps)
{
@@ -430,8 +447,7 @@ void
cmComputeLinkDepends::HandleSharedDependency(SharedDepEntry const dep)
entry.Target-GetLinkInterface(this-Config))
{
// Follow public and private dependencies transitively.
- this-QueueSharedDependencies(index, iface-Libraries);
- this-QueueSharedDependencies(index, iface-SharedDeps);
+ this-FollowSharedDeps(index, iface, true);
}
}
}
diff --git a/Source/cmComputeLinkDepends.h b/Source/cmComputeLinkDepends.h
index e196e00..80a0454 100644
--- a/Source/cmComputeLinkDepends.h
+++ b/Source/cmComputeLinkDepends.h
@@ -105,6 +105,10 @@ private:
int DependerIndex;
};
std::queueSharedDepEntry SharedDepQueue;
+ std::setint SharedDepFollowed;
+ void FollowSharedDeps(int depender_index,
+cmTarget::LinkInterface const* iface,
+bool follow_interface = false);
void QueueSharedDependencies(int depender_index,
std::vectorstd::string const deps);
void HandleSharedDependency(SharedDepEntry const dep);
diff --git a/Tests/CMakeOnly/CMakeLists.txt b/Tests/CMakeOnly/CMakeLists.txt
index d32e7be..e4ba53a 100644
--- a/Tests/CMakeOnly/CMakeLists.txt
+++ b/Tests/CMakeOnly/CMakeLists.txt
@@ -7,3 +7,6 @@ macro(add_CMakeOnly_test test)
[Cmake-commits] CMake branch, next, updated. v2.8.7-2095-gec9d401
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 ec9d4011a86b18e807aaca65f9a1a93a92ef8c96 (commit)
via ae250d5cfa0daec74935e6aa484fa439f3a6dd23 (commit)
from 3eb481524b5c7e4fdbd668431576ff912756e226 (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=ec9d4011a86b18e807aaca65f9a1a93a92ef8c96
commit ec9d4011a86b18e807aaca65f9a1a93a92ef8c96
Merge: 3eb4815 ae250d5
Author: Eric Noulard eric.noul...@gmail.com
AuthorDate: Fri Jan 13 15:40:26 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Jan 13 15:40:26 2012 -0500
Merge topic 'CPackRPM-noFileListedTwice' into next
ae250d5 CPackRPM flag direcories with %dir in the generated spec file
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ae250d5cfa0daec74935e6aa484fa439f3a6dd23
commit ae250d5cfa0daec74935e6aa484fa439f3a6dd23
Author: Deborah Pickett deborah.pick...@autodesk.com
AuthorDate: Fri Jan 13 21:35:41 2012 +0100
Commit: Eric NOULARD eric.noul...@gmail.com
CommitDate: Fri Jan 13 21:35:41 2012 +0100
CPackRPM flag direcories with %dir in the generated spec file
This fix bug #12863 whose symptom was a lot of warning: File listed twice
printed out by rpmbuild when processing the spec file.
Signed-off-by: Eric NOULARD eric.noul...@gmail.com
diff --git a/Modules/CPackRPM.cmake b/Modules/CPackRPM.cmake
index bf476ad..e1e76ed 100644
--- a/Modules/CPackRPM.cmake
+++ b/Modules/CPackRPM.cmake
@@ -714,6 +714,25 @@ else()
set(CPACK_RPM_ABSOLUTE_INSTALL_FILES )
endif(CPACK_ABSOLUTE_DESTINATION_FILES_INTERNAL)
+# Prepend directories in ${CPACK_RPM_INSTALL_FILES} with %dir
+# This is necessary to avoid duplicate files since rpmbuild do
+# recursion on its own when encountering a pathname which is a directory
+# which is not flagged as %dir
+string(STRIP ${CPACK_RPM_INSTALL_FILES} CPACK_RPM_INSTALL_FILES_LIST)
+string(REPLACE \n ; CPACK_RPM_INSTALL_FILES_LIST
+${CPACK_RPM_INSTALL_FILES_LIST})
+string(REPLACE \ CPACK_RPM_INSTALL_FILES_LIST
+${CPACK_RPM_INSTALL_FILES_LIST})
+set(CPACK_RPM_INSTALL_FILES )
+foreach(F IN LISTS CPACK_RPM_INSTALL_FILES_LIST)
+ if(IS_DIRECTORY ${WDIR}/${F})
+set(CPACK_RPM_INSTALL_FILES ${CPACK_RPM_INSTALL_FILES}%dir \${F}\\n)
+ else()
+set(CPACK_RPM_INSTALL_FILES ${CPACK_RPM_INSTALL_FILES}\${F}\\n)
+ endif()
+endforeach(F)
+set(CPACK_RPM_INSTALL_FILES_LIST )
+
# The name of the final spec file to be used by rpmbuild
SET(CPACK_RPM_BINARY_SPECFILE
${CPACK_RPM_ROOTDIR}/SPECS/${CPACK_RPM_PACKAGE_NAME}${CPACK_RPM_PACKAGE_COMPONENT_PART_NAME}.spec)
---
Summary of changes:
Modules/CPackRPM.cmake | 19 +++
1 files changed, 19 insertions(+), 0 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.7-95-gc121f3f
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 c121f3f5c4b874910ab8e5b083827d9e393e1a96 (commit) from 50edbf0f224e81cb85a0588d2495676efc3101f2 (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=c121f3f5c4b874910ab8e5b083827d9e393e1a96 commit c121f3f5c4b874910ab8e5b083827d9e393e1a96 Author: KWSys Robot kwro...@kitware.com AuthorDate: Sat Jan 14 00:05:03 2012 -0500 Commit: KWSys Robot kwro...@kitware.com CommitDate: Sat Jan 14 00:05:03 2012 -0500 KWSys Nightly Date Stamp diff --git a/Source/kwsys/kwsysDateStamp.cmake b/Source/kwsys/kwsysDateStamp.cmake index 39d8a79..91bf5e7 100644 --- a/Source/kwsys/kwsysDateStamp.cmake +++ b/Source/kwsys/kwsysDateStamp.cmake @@ -18,4 +18,4 @@ SET(KWSYS_DATE_STAMP_YEAR 2012) SET(KWSYS_DATE_STAMP_MONTH 01) # KWSys version date day component. Format is DD. -SET(KWSYS_DATE_STAMP_DAY 13) +SET(KWSYS_DATE_STAMP_DAY 14) --- 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
