Re: [CMake] Putting the git commit hash in a cmake variable
Sorry if this shows up oddly on the list; I was forwarded the original
in order to reply. As such, please keep me in Cc.
> I'd like to set a CMake variable to the current git commit short hash.
> This variable will be used as part of the version string for my
> project (ex: "1.0.1+git.${SHORT_HASH}"). I can get at this short hash
> by using execute_process and setting the resulting output to a
> variable.
>
> ```cmake
> execute_process(
> COMMAND
> git rev-parse --short HEAD
> RESULT_VARIABLE
> SHORT_HASH_RESULT
> OUTPUT_VARIABLE
> SHORT_HASH)
> ```
>
> My issue is that cmake will only run execute_process once, during the
> configure step. I need cmake to run this execute_process on every
> build and, if the output has changed, reconfigure to make sure
> SHORT_HASH is up to date.
>
> I came up with one solution to this issue: During the configure step,
> I can write the current short hash to a file named short_hash.txt. On
> every build, I'll re-compute the short hash and verify that the
> computed short hash is the same as what is in short_hash.txt. If its
> not, I'll write the new short hash to short_hash.txt. I then make
> short_hash.txt an input to configure_file. This will cause cmake to
> validate SHORT_HASH is properly set, and re-configure if its not.
I solved this a few years ago :) . Here are all the relevant files:
https://github.com/Kitware/sprokit/blob/master/src/sprokit/version.h.in
https://github.com/Kitware/sprokit/blob/master/src/sprokit/.gitattributes
https://github.com/Kitware/sprokit/blob/master/src/sprokit/CMakeLists.txt
https://github.com/Kitware/sprokit/blob/master/conf/sprokit-macro-configure.cmake
Basically the solution follows:
- If we're in an archive (.gitattributes' export-subst), use the
information from it. Detect this in CMake by checking if Git
replaced substitutions for us:
if ("$Format:$" STREQUAL "")
If we are, just use that information (gathered using other
`$Format:$` expansions).
- If not, we set up some code to run at build time to extract the
information.
- The variables (or code) from above is injected via
`sprokit_configure_file_always` which basically is just a
`configure_file` done at build time. The list of variables to export
to the script are listed as arguments. The `_always` bit just adds
an extra output file named `${output}.noexist` which causes tools to
always run the associated custom command (which is then attached to
a custom target via its output file).
The file is only updated if the contents change (via `configure_file`),
so rebuilding should be minimal.
--Ben
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] How to obtain a list of target dependencies
On Mon, Mar 12, 2018 at 15:11:28 -0500, Robert Dailey wrote: > I'm going to add the CMake Dev group as well, since I asked this same > question last year around May and I didn't get any response. Hoping > for some help this time around. I don't see anything documented, so > maybe the developers know the best approach here. There's an issue for this here: https://gitlab.kitware.com/cmake/cmake/issues/12435 There has been extensive discussion on the feature and previous mailing list threads about it. I'm not intimately familiar with that discussion myself, but it has more details at least. --Ben -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] cmake_format
On Wed, Feb 07, 2018 at 13:27:28 +0100, Cristian Adam wrote: > I don't remember seeing this tool advertised on the CMake mailing lists: > > https://github.com/cheshirekow/cmake_format/tree/master/cmake_format Cool! I have some feature requests, but I'll add them over there :) . --Ben -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 3.9 change to dependencies of object compilation
On Fri, Aug 04, 2017 at 17:35:53 +, Puetz Kevin A wrote: > Thanks for the reply, questions/clarifications below. > > requests that that be fixed as well (though that is backwards compatible > > since the solution will likely involve ). > > Sentence cut off? I assume you meant "will likely involve a new keyword"? Yep, sorry. > > > 2. MSVC's #import construct which needs the indirect dependencies > > > (dependencies of the #import-ed dependency) be registered, which is > > > handled as part of the target using add_custom_command(TARGET foo > > > POST_BUILD COMMAND ...) > > > > So there's an issue here that there's a dependency between your build rules > > which CMake doesn't know about (though I don't know #import well > > enough, the docs don't state where the information *goes*). > > #import will load a COM typelib during preprocessing, possibly > following registry keys to locate other typelibs which the specified > one refers to. It will have the byproduct of creating .tlh/.tli files > next to the other compiler outputs (e.g. .o file) Arguably the > .tlh/.tli files should be listed in OBJECT_OUTPUTS, but I can't > because I don't know their location; CMake doesn't have a > variable/property/generator expression that reveals where it's going > to place the object files (i.e. /Fo$out), so I don't know where they > will end up. Luckily the .tlh/.tli files aren't important to list for > dependency resolution anyway, because the #import also automatically > #includes the just-generated headers, (though this is not mentioned in > /showIncludes). So CMake is at least *consistently* unaware of these > files, and they get regenerated any time they would have been read so > it doesn't really need to know. OK, a genex for where object outputs may be useful anyways. I think there's something along those lines with Cuda's PTX file generation? > The important missing dependency is the one between > creating/regstering the typelib (we'll call this target COMServer) and > the #import that will read it in a source file in another target > (we'll call it COMClient). I have a call add_custom_command(TARGET > COMServer POST_BUILD COMMAND regsvr32 $), > which will create the registry keys under HKEY_CLASSES_ROOT. This > needs to happen before the source file in COMClient can preprocess the > #import successfully. Prior to CMake 3.9, I could inform CMake of this > by just using add_dependencies(COMClient COMServer) to tell CMake that > it couldn't build (any of) Client until Server had been built (and > thus its POST_BUILD had also run to register it). But in 3.9, > add_dependencies has changed in meaning; although the documentation > still says "to ensure that they build before does", in > practice this now only means "to ensure that they build before > *links*"; these edges do not apply to object compilation or > add_custom_command rules. > > add_custom_command is no problem; it already had a DEPENDS argument > that allows target-level dependencies, and arguably such dependencies > needed to be stated there anyway since an add_custom_command output > can get reused by multiple targets in the same subdir. But object > compilation is a problem because there's nowhere to add them > per-source, and add_dependencies doesn't work anymore to add them > per-target. It sounds like the logic may need fixing then. Do you have an example case where add_dependencies doesn't work anymore in Ninja? > > When adding > > this custom command, you may use the `BYPRODUCTS` argument > > (introduced in 3.2.0) to let CMake know what's going on here. It only > > affects > > Ninja, but the other generators do target-level dependencies anyways. That > > output can then be depended on via `OBJECT_DEPENDS` and the > > dependency should link up properly. > > There is not an explicit file output, though I could do the usual > workaround of a stamp/witness file listed in BYPRODUCTS to the > add_custom_command(TARGET ... POST_BUILD ...). But I don't think that > will work with most generators, since CMake doesn't generally allow > file-level depends to set the order in which targets are built. I > suppose it might work out in practice for ninja since that writes a > monolithic set of rules, but conditional code where I have to peek at > CMAKE_GENERATOR and use BYPRODUCTS/OBJECT_DEPENDS for ninja and > add_dependencies for other generators seems like the sort of thing > this list would tell me not to do :-) Well, other generators are generally target-ordered anyways. Ninja is the oddball here (which is why it's the only one to get the feature). I don't know the effect it'd have in other generators, but I feel like I'd be surprised if it *broke* them since excess dependencies (usually) only result in either slower builds or circular dependency loops and Ninja complains loudly about the latter. And since BYPRODUCTS only affects Ninja, if BYPRODUCTS is used, other generators shouldn't care anyways. > And even for ninja I think I'd have to
Re: [CMake] CMake 3.9 change to dependencies of object compilation
> . The Ninja generator has loosened the dependencies of object > compilation. Object compilation now depends only on custom targets and > custom commands associated with libraries on which the object's target > depends and no longer depends on the libraries themselves. Source > files in dependent targets may now compile without waiting for their > targets' dependencies to link. Correct. > We have a few cases where the object compilation really does depend on > the TARGET_FILE itself, e.g. > 1. An RC compiler embedding the resulting file of a custom target (I > think this one may still work, since custom targets appear to have > been exempted from the change) Correct, though this issue: https://gitlab.kitware.com/cmake/cmake/issues/17097 requests that that be fixed as well (though that is backwards compatible since the solution will likely involve ). > 2. MSVC's #import construct which needs the indirect dependencies > (dependencies of the #import-ed dependency) be registered, which is > handled as part of the target using add_custom_command(TARGET foo > POST_BUILD COMMAND ...) So there's an issue here that there's a dependency between your build rules which CMake doesn't know about (though I don't know #import well enough, the docs don't state where the information *goes*). When adding this custom command, you may use the `BYPRODUCTS` argument (introduced in 3.2.0) to let CMake know what's going on here. It only affects Ninja, but the other generators do target-level dependencies anyways. That output can then be depended on via `OBJECT_DEPENDS` and the dependency should link up properly. If it instead gets registered somewhere in the aether (as far as CMake is concerned), adding support for generator expressions to `OBJECT_DEPENDS` so that `$` may be used there would be the next solution. Making `POST_BUILD` write out a stamp file would also work and then using `OBJECT_DEPENDS` on that would also work. --Ben -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] Signing of DEB and RPM packages
On Tue, Jul 25, 2017 at 17:43:03 +0200, Roman Wüger wrote: > is the signing of DEB packages (debsigs) and RPM packages (rpmsign or > rpm --addsign) supported at the moment? It doesn't appear to be supported right now (no results from grep'ing for "debsig" or "addsign"). --Ben -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] Does JOB_POOL_[COMPILE|LINK] work with custom_target?
On Mon, May 15, 2017 at 11:46:37 +0200, Eric Noulard wrote: > No answer whatsoever on this? I don't think it is supported right now. > I'd like to be able assign some custom targets to a ninja job pool. > If I were to implement the feature would it be acceptable upstream ? I think it'd be fine. --Ben -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] Trouble with FindPNG module
On Mon, Apr 24, 2017 at 12:20:27 -0500, Robert Dailey wrote: > -- The C compiler identification is GNU 4.9.4 > -- The CXX compiler identification is GNU 4.9.4 > -- Check for working C compiler: /usr/bin/gcc-4.9 > -- Check for working C compiler: /usr/bin/gcc-4.9 -- works > -- Detecting C compiler ABI info > -- Detecting C compiler ABI info - done > -- Detecting C compile features > -- Detecting C compile features - done > -- Check for working CXX compiler: /usr/bin/g++-4.9 > -- Check for working CXX compiler: /usr/bin/g++-4.9 -- works > -- Detecting CXX compiler ABI info > -- Detecting CXX compiler ABI info - done > -- Detecting CXX compile features > -- Detecting CXX compile features - done Does the information in the CMakeFiles/$cmake_version directory contain anything indicating that it's detecting the compiler as 64-bit? > I'm not sure how to use strace. I tried following instructions I found > on the [CMake Performance Tips][1] page, but this isn't working. My > generate command has a lot of options, so I use a helper shell script > to generate. strace seems to not work well when using a shell script. > Trace also doesn't show much useful. Could you give exact command line > I can run to get the info you need? Sorry, it's such a common tool I use, I forget others are new to it :) . Here's how I'd use it to debug this: strace -s 1 -e file -o cmake.strace.log $cmake_command If your cmake command is a script that later launches CMake, you can give strace `-f` to have it also trace any child processes made by the command. In the resulting log file, you'll see syscalls CMake is making. searching for the png header/library searching area shouldn't be too hard. Is it looking in anything resembling the right paths? --Ben -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] Trouble with FindPNG module
On Mon, Apr 24, 2017 at 09:54:18 -0500, Robert Dailey wrote: > On Fri, Apr 21, 2017 at 4:48 PM, Robert Dailey > wrote: > > I'm running CMake 3.8.0 on Ubuntu 14. I invoke the following: > > > > find_package(PNG REQUIRED) > > > > Which gives me the output in CMake: > > > > Could NOT find PNG (missing: PNG_LIBRARY) (found version "1.2.50") > > > > The CMakeCache.txt file has these variables set: > > > > PNG_LIBRARY_DEBUG:FILEPATH=PNG_LIBRARY_DEBUG-NOTFOUND > > PNG_LIBRARY_RELEASE:FILEPATH=PNG_LIBRARY_RELEASE-NOTFOUND > > PNG_PNG_INCLUDE_DIR:PATH=/usr/include > > > > So it found the headers, but not the libs. Why did it not find the > > libs? Note that my version of Ubuntu is 64-bit, and I've installed the > > 32-bit libs like so: > > > > $ sudo apt-get install libpng12-dev:i386 What compiler are you using (what does CMake say it is?)? Does an `strace` of CMake configuring the project show anything interesting? `cmake --trace-expand`? --Ben -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Ninja + parallel linking
On Fri, Jul 08, 2016 at 11:40:38 -0400, Brad King wrote: > This happens because CMake generates order-only dependencies on the > compilation rules of each exe/lib's objects to make sure the do not > compile until linking of dependencies is done. This makes the build > semantics match that of other generators where each logical target is > treated as its own isolated build that is evaluated only when its > logical target dependencies have been finished. > > This is unfortunately necessary to get correct builds for CMake projects > in general because we support cases where add_custom_command is used > in library "foo" to generate a header file that is included during > compilation in library "bar" that links to "foo", but we have no good > way to express this dependency besides the ordering dependency of bar > on foo. > > It is likely possible to detect causes automatically when this is > not necessary, such as when the transitive closure of a target's > dependencies contains no custom commands. A dedicated effort will be > needed to investigate this further and implement such optimizations > on the build graph generation. There's an issue for this already: https://gitlab.kitware.com/cmake/cmake/issues/1 I've brainstormed how to detect when the dependencies can be dropped (it's on some paper around here somewhere...), but haven't implemented it yet. --Ben -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] [iOS] What is the correct way to add resources to an XCode project
On Wed, Jun 29, 2016 at 16:48:10 +0200, Roman Wüger wrote: > I know because I wrote this ticket. Ah. I didn't check the Mantis side. > I thought this was "closed/want fixed" because of the implementation > for RESOURCE a few days ago. Hmm. I don't see that. Do you have a link? --Ben -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] [iOS] What is the correct way to add resources to an XCode project
On Tue, Jun 28, 2016 at 23:01:56 +0200, Roman Wüger wrote: > The target property RESOURCE does only allow files but no directories. There's an open issue for this: https://gitlab.kitware.com/cmake/cmake/issues/14743 --Ben -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] ninja command line options not propagated to ninja invocation for superbuild projects
On Thu, Jan 28, 2016 at 15:15:58 -0500, Taylor Braun-Jones wrote: > That's too bad. I understand the perspective of the Ninja developers, > but it's not clear to me what the proposed alternative should be. > Should CMake be using the subninja[1] keyword to include the > build.ninja of External Projects? That would be possible with the work that's been done here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15364 --Ben -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] Why does INTERFACE type targets only support whitelisted properties?
On Mon, Jan 11, 2016 at 16:47:03 -0500, Taylor Braun-Jones wrote: > I have another INTERFACE property use case that is not whitelisted, but > should be: VERSION VERSION is a special property for libraries. Particularly the name for the file with the actual content of the library (the SOVERSION and name of the library being symlinks to it): https://cmake.org/cmake/help/latest/prop_tgt/VERSION.html INTERFACE targets have no need for this property. > Consider library project Foo that uses a header-only project Bar. In > FooConfig.cmake, it is a important to ensure any projects using Foo also > use the exact same version of Bar that Foo was originally built with > (Failure to do so can lead to subtle, hard-to-find bugs like violation of > the one definition rule). Assuming project Bar creates an imported target > "Bar" with a VERSION property set like: > > set_property(TARGET Bar APPEND PROPERTY VERSION 1.2.3) Also, this property is not a list (probably?), so APPEND isn't really correct. It indicates that the value here should be (list-)appended to the existing value. > Then project Foo should be able to have something like: > > == CMakeLists.txt == > ... > get_property(FOO_BAR_VERSION TARGET BAR PROPERTY VERSION) > configure_file(FooConfig.cmake.in FooConfig.cmake @ONLY) > > == FooConfig.cmake.in == > ... > find_package(Bar "@FOO_BAR_VERSION@" EXACT REQUIRED) find_package(Foo) should set a Foo_VERSION variable (if known): https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html#package-version-file > But, alas, this is not currently possible. I'm ambivalent about whether > INTERFACE properties should be whitelisted vs blacklisted vs unrestricted, > but at least this VERSION property seems valid to allow. Currently, they are whitelisted, but I think any property not understood by CMake directly (i.e., user-set properties) would probably be fine. --Ben -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] FindMPI.cmake and MS-MPI
On Mon, Mar 02, 2015 at 09:19:00 -0800, Todd Gamblin wrote: > Thanks for letting me know. Let me know if you have any more issues. > > Ben: at some point I was the maintainer for FindMPI. Are you the official > maintainer now? Do you want to be? I have very limited ability to test on > Windows, and that seems to be where most of the problems are. I'm not the official maintainer and am not *that* familiar with MPI, so I'm probably not the best choice. If you have issues with MPI on Windows, you can push them my way to test if you'd like. --Ben -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Problem with CMake-3.0.0-rc4 + Ninja + Intel C++
On Fri, May 09, 2014 at 15:19:51 -0400, Brad King wrote: > Ninja: Fix deptype for Intel compiler on Linux > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=54535f47 Would this be cleaner: https://github.com/mathstuf/CMake/commit/9523d2a55c99fb0910531ae7160b099faeab6638 It would allow for changing CMake's deptype logic without a CMake update (in the future). --Ben -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] FindBoost.cmake not (fully) honoring BOOST_ROOT
Hi,
Using the 'release' branch of CMake, it seems that FindBoost.cmake got
broken such that when BOOST_ROOT is set, the system copy of boost is
still found, effectively ignoring whatever BOOST_ROOT sets. This doesn't
work at all for projects where a newer boost than the system version is
needed.
The first commit I found that has this behavior is
commit 566647d34f70510815cbdb6b00a170a8aef3
Author: Douglas Gregor
Date: Thu Jul 3 15:49:41 2008 -0400
ENH: Cleanup FindBoost module, fixing several small bugs and
providing better diagnostic information when things go wrong
which has been in since v2.8.0 and seems odd since the noticed breakage
is more recent. Testing every commit that has changed FindBoost.cmake
since then also has the bug. From this, I gather that pretty much
everyone uses system Boost versions on Linux. Another possibility is
that since I'm on Fedora, looking for /usr/lib64 may be confusing
FindBoost.cmake since the locally installed versions use
${BOOST_ROOT}/lib instead which would cause it to not be found. However,
adding a symlink from ${BOOST_ROOT}/lib64 to ${BOOST_ROOT}/lib does not
resolve the issue.
The bisect.sh script is attached as well as the t/CMakeLists.txt I used.
It is intended to be run from the CMake source tree. Editing
t/CMakeLists.txt to point to a different Boost will likely be needed.
The bisect.sh script expects the tree to look like:
.../ <- a common root
build/ <- the build tree, will be deleted and
re-bootstrapped on each run
src/ <- the source tree, run from here
t/ <- the test tree
Here is a snapshot of the related cache variables from the above test:
BOOST_ROOT /home/boeckb/misc/root/boost
Boost_INCLUDE_DIR/home/boeckb/misc/root/boost/include
Boost_LIBRARY_DIRS /usr/lib64
Boost_SYSTEM_LIBRARY /usr/lib64/libboost_system-mt.so
Boost_SYSTEM_LIBRARY_DEBUG /usr/lib64/libboost_system-mt.so
Boost_SYSTEM_LIBRARY_RELEASE /usr/lib64/libboost_system-mt.so
There is Boost_NO_SYSTEM_PATHS, but even without this, the above should
not happen. Getting mixed include and library paths is silent and an
easy way to get confusing errors.
Because of this, I propose that FindBoost.cmake have tests added which
should be run on specific dashboards with a set of local Boost copies to
help prevent regressions. The tests should ensure that if BOOST_ROOT is
set, Boost_INCLUDE_DIR, Boost_LIBRARY_DIRS, and Boost_*_LIBRARY* are
under BOOST_ROOT. A dashboard for at least a Red Hat-based distro and a
Debian-based distro should be made due to /usr/lib${LIB_SUFFIX}
differences.
- Finding a local Boost instead of the system version.
- As above, but searching for components.
- As above, but searching for a component that is in the system and
*not* in the local Boost. This test should either fail (which is
easier) or use the system version for everything. It should
definitely *not* find some components in the system and some in
the local version.
- Error when a local Boost does not meet the minimum version
requirement and the system version does. A message about unsetting
BOOST_ROOT would be nice here.
- Tests for ensuring the following are honored similar to the
component searches above:
Boost_USE_STATIC_LIBS
Boost_USE_MULTITHREADED
Any others tests that would be good to have?
--Ben
set(BOOST_ROOT
"/home/boeckb/misc/root/boost"
CACHE PATH "")
find_package(Boost REQUIRED
COMPONENTS
system)
if (Boost_SYSTEM_LIBRARY MATCHES "^/usr/lib")
message(FATAL_ERROR "FAIL")
else (Boost_SYSTEM_LIBRARY MATCHES "^/usr/lib")
message(STATUS "PASS")
endif (Boost_SYSTEM_LIBRARY MATCHES "^/usr/lib")
bisect.sh
Description: Bourne shell script
--
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] Using gcov/lcov and valgrind with cmake
Gerhard Gappmeier wrote: > Hi all, > > I'm trying to figure out how to use gcov and maybe also lcov with cmake. > I know it works using ctest, I've seen that in several wiki entries, > but I could not find one single example on how to use it. > The wiki only shows the commandline args for GCC, but no cmake examples. > > I attached a simple hello world project with two tests (ADD_TEST) which work. > I tried to add the "ctest_coverage" and "ctest_memcheck" commands but I can't > get them working. > > Maybe somebody can complete this example. > > IMO a new section about gcov and valgrind should be added to > http://www.cmake.org/cmake/help/cmake_tutorial.html > This would help a lot of people. Hi, I have a setup for doing something that you might be looking for. In the top-level CMakeLists.txt[1], I add some options to build with coverage. I also have a couple of macros[2] which make generating testing targets much nicer[3]. These macros do not assume CTest is enabled nor conflict with it. AFAIK they are gcov-specific, but another option could be added to use lcov instead. Similar with valgrind. If you have any questions or suggestions, feel free to ask. --Ben [1]http://git.benboeckel.net/?p=chasmd.git;a=blob;f=CMakeLists.txt [2]http://git.benboeckel.net/?p=chasmd.git;a=blob;f=cmake/test.cmake [3]http://git.benboeckel.net/?p=chasmd.git;a=blob;f=test/libchasm/CMakeLists.txt ___ 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] Is there a tool pretty much like cmake for Java?
On Fri, Oct 22, 2010 at 04:45:42PM -0400, Ben Boeckel forgot to attach
files
Actually attaching things now.
--Ben
#
# This file provides functions for Java support.
#
# Available Functions:
#
# add_jar(TARGET_NAME SRC1 SRC2 .. SRCN RCS1 RCS2 .. RCSN)
#
# This command create a .jar. It compiles the given source
# files (SRC) and adds the given resource files (RCS) to the jar file.
# If only resource files are given then just a jar file is created.
#
# Additional instructions:
# To add compile flags to the target you can set these flags with
# the following variable:
#
# set(CMAKE_JAVA_COMPILE_FLAGS -nowarn)
#
# To add a path or a jar file to the class path you can do this
# with the CMAKE_JAVA_INCLUDE_PATH variable.
#
# set(CMAKE_JAVA_INCLUDE_PATH /usr/share/java/shibboleet.jar)
#
# To use a different output name for the target you can set it with:
#
# set(CMAKE_JAVA_TARGET_OUTPUT_NAME shibboleet.jar)
# add_jar(foobar foobar.java)
#
# To add a VERSION to the target output name you can set it using
# CMAKE_JAVA_TARGET_NAME. This will create a jar file with the name
# shibboleet-1.0.0.jar and will create a symlink shibboleet.jar pointing
# to the jar with the version information.
#
# set(CMAKE_JAVA_TARGET_VERSION 1.2.0)
# add_jar(shibboleet shibbotleet.java)
#
# Variables set:
# The add_jar() functions sets some variables which can be used in the
# same scope where add_jar() is called.
#
# _INSTALL_FILES The files which should be installed. This
# is used by install_jar().
# _JAR_FILE The location of the jar file so that you
# can include it.
# _CLASS_DIR The directory where the class files can be
# found. For example to use them with javah.
#
#
#install_jar(TARGET_NAME DESTINATION)
#
#This command installs the TARGET_NAME files to the given DESTINATION. It
#should be called in the same scope as add_jar() or it will fail.
#
#=
# Copyright 2010 Andreas schneider
#
# Distributed under the OSI-approved BSD License (the "License");
# see accompanying file Copyright.txt for details.
#
# This software is distributed WITHOUT ANY WARRANTY; without even the
# implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
# See the License for more information.
#=
# (To distributed this file outside of CMake, substitute the full
# License text for the above reference.)
function (__java_copy_file src dest comment)
add_custom_command(
OUTPUT ${dest}
COMMAND cmake -E copy
ARGS${src}
${dest}
DEPENDS ${src}
COMMENT ${comment})
endfunction (__java_copy_file src dest comment)
function (add_jar _TARGET_NAME)
set(_JAVA_SOURCE_FILES ${ARGN})
if (LIBRARY_OUTPUT_PATH)
set(CMAKE_JAVA_LIBRARY_OUTPUT_PATH ${LIBRARY_OUTPUT_PATH})
else (LIBRARY_OUTPUT_PATH)
set(CMAKE_JAVA_LIBRARY_OUTPUT_PATH ${CMAKE_CURRENT_BINARY_DIR})
endif (LIBRARY_OUTPUT_PATH)
set(CMAKE_JAVA_INCLUDE_PATH
${CMAKE_JAVA_INCLUDE_PATH}
${CMAKE_CURRENT_SOURCE_DIR}
${CMAKE_JAVA_OBJECT_OUTPUT_PATH}
${CMAKE_JAVA_LIBRARY_OUTPUT_PATH})
if (WIN32 AND NOT CYGWIN)
set(CMAKE_JAVA_INCLUDE_FLAG_SEP ";")
else (WIN32 AND NOT CYGWIN)
set(CMAKE_JAVA_INCLUDE_FLAG_SEP ":")
endif(WIN32 AND NOT CYGWIN)
set(CMAKE_JAVA_CLASS_OUTPUT_PATH
"${CMAKE_CURRENT_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/${_TARGET_NAME}.dir")
set(_JAVA_TARGET_OUTPUT_NAME "${_TARGET_NAME}.jar")
if (CMAKE_JAVA_TARGET_OUTPUT_NAME AND CMAKE_JAVA_TARGET_VERSION)
set(_JAVA_TARGET_OUTPUT_NAME
"${CMAKE_JAVA_TARGET_OUTPUT_NAME}-${CMAKE_JAVA_TARGET_VERSION}.jar")
set(_JAVA_TARGET_OUTPUT_LINK "${CMAKE_JAVA_TARGET_OUTPUT_NAME}.jar")
elseif (CMAKE_JAVA_TARGET_VERSION)
set(_JAVA_TARGET_OUTPUT_NAME
"${_TARGET_NAME}-${CMAKE_JAVA_TARGET_VERSION}.jar")
set(_JAVA_TARGET_OUTPUT_LINK "${_TARGET_NAME}.jar")
elseif (CMAKE_JAVA_TARGET_OUTPUT_NAME)
set(_JAVA_TARGET_OUTPUT_NAME "${CMAKE_JAVA_TARGET_OUTPUT_NAME}.jar")
endif (CMAKE_JAVA_TARGET_OUTPUT_NAME AND CMAKE_JAVA_TARGET_VERSION)
set(CMAKE_JAVA_TARGET_OUTPUT_NAME)
set(_JAVA_CLASS_FILES)
set(_JAVA_COMPILE_FILES)
set(_JAVA_DEPENDS)
set(_JAVA_RESOURCE_FILES)
foreach (_JAVA_SOURCE_FILE ${_JAVA_SOURCE_FILES})
get_filename_component(_JAVA_EXT ${_JAVA_SOURCE_FILE} EXT)
get_filename_component(_JAVA_FULL ${_JAVA_SOURCE_FILE} ABSOLUTE)
get_filename_component(_JAVA_FI
Re: [CMake] Is there a tool pretty much like cmake for Java?
On Sat, Oct 16, 2010 at 01:35:27PM +0200, Andreas Schneider wrote:
> http://git.cynapses.org/users/asn/pki.git/tree/cmake/Modules/UseJava.cmake?h=cmake
> http://git.cynapses.org/users/asn/pki.git/tree/cmake/Modules/JavaClassFilelist.cmake?h=cmake
Hi,
These work great, however I did find a few issues with them for a
project I'm working on moving to CMake. I fixed these issues here and
the new UseJava.cmake is attached:
- Resources changing doesn't trigger a rebuild
Solution:
add_custom_command to copy each resource file.
- Allow .jar files to be specified in the sources list
Solution:
Search the source paths for a .jar extension and add them to the
include path if found.
- Allow target names to be given in the sources list
Solution:
When there is no extension (this introduces some corner cases;
not sure if they're acceptable), link to the .jar output for
that target.
- Allow dependencies on generated .java files
Solution:
Use add_custom_command(OUTPUT ...) to allow for dependencies for
that output file to be listed. This requires a list of output
.class files to be made and listed as what the javac command
generates and then as a dependency for the jar command.
- The local UseJava{ClassFilelist,Symlinks} should probably be baked
into UseJava.cmake; I haven't done this work yet. The related
commands are just commented out. Symlinks seems to be all that's
needed.
- Allow output jar files to be dependencies of other commands ()
- Some variable usage was wrong (CMAKE_JAVA_LIBRARY_OUTPUT_PATH was
set above, but then not used below)
- Add function to search for .jar files. I'm not sure if the list of
default paths is good enough.
- Some style changes (no dangling parentheses).
There's one hack in determining the relative path (search for _BIN_LEN)
to create the final classpath for each file. It works here, but I'm not
really a Java guy and other use cases may have been broken by this.
--Ben
___
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 use Purify with CMake.
william.croc...@analog.com wrote:
> Hello:
>
> I needed to build a purified version of my test program.
> A search of the mailing list archives produced a number of
> options, but they all had drawbacks.
>
> I came upon the solution below which seems to work well.
> I introduce a new language "PURIFY" for the purposes
> of linking the purified executable.
>
> Any comments?
>
> Bill
Something like this is probably better (crudely adapted from something
like this for test executables from here[1]):
macro (purify exename)
add_custom_target(purify-${exename})
add_custom_command(
TARGET purify-${exename}
COMMAND purify
${purify_arguments}
${EXECUTABLE_OUTPUT_PATH}/${exename}
${ARGN}
WORKING_DIRECTORY
${CMAKE_BINARY_DIR}
COMMENT "Running purify on \"${exename}\"")
add_dependencies(purify-${exename}
${exename})
endmacro (purify)
[1]http://git.benboeckel.net/?p=chasmd.git;a=blob;f=cmake/test.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] visual studio 2010 warning message
David Cole wrote: > [-- multipart/alternative, encoding 7bit, 1 lines --] > >[-- text/plain, encoding 7bit, charset: ISO-8859-1, 58 lines --] > > Thanks for the info. This is dues to changes in 'next' from the > "dev/strict-mode" topic branch on the stage. Ben is still working out the > remaining kinks in that feature... one of which are these warnings you're > observing. Should be fixed "soon-ish"... :-) > > Thanks! I just merged it into next[1]. The problem was that try_compile needs to pass arguments to the internal cmake run, but the argument parser was not run. My first attempt caused a lot of tests to fail since the argument parser sets the directories itself even if they were fine before. There's now an extra argument to the argument parser which overrides setting the directories in there. --Ben [1]commit fe239577314c09323e52c68f6c4bddbd19af915e ___ 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] Using Valgrind on all tests
Clark Gaebel wrote: > Hello, > > I've currently set up CMake and CTest for my building and testing needs, > but CDash just isn't for me. How do I set up CTest to run all the tests > in Valgrind? Again, I don't want to use CDash - just CTest. > > Also, it'd be great if I get output on leaks, and silence when > everything's alright. I also wanted this, and I ended up writing my own targets for it (it includes other stuff such as callgrind and actual handling of the tests themselves). The most recent iteration of it is available at: git clone git://chasmd.org/chasmd.git The cmake/test.cmake file is the one with the macros to create the targets and example usage is in the test/ directory. The output is dumped to files for easier reference rather than to the terminal, but I'm sure a target that greps the logs for important strings and errors on that wouldn't be hard to make. Hope this helps. --Ben ___ 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] Any recent guides to adding support for doxygen
EXTERNAL_GROUPS= NO
PERL_PATH = /usr/bin/perl
#---
# Configuration options related to the dot tool
#---
CLASS_DIAGRAMS = YES
MSCGEN_PATH=
HIDE_UNDOC_RELATIONS = YES
HAVE_DOT = YES
DOT_FONTNAME = DejaVu Sans
DOT_FONTSIZE = 10
DOT_FONTPATH =
CLASS_GRAPH= YES
COLLABORATION_GRAPH= YES
GROUP_GRAPHS = YES
UML_LOOK = NO
TEMPLATE_RELATIONS = NO
INCLUDE_GRAPH = YES
INCLUDED_BY_GRAPH = NO
CALL_GRAPH = NO
CALLER_GRAPH = NO
GRAPHICAL_HIERARCHY= YES
DIRECTORY_GRAPH= YES
DOT_IMAGE_FORMAT = png
DOT_PATH =
DOTFILE_DIRS =
DOT_GRAPH_MAX_NODES= 50
MAX_DOT_GRAPH_DEPTH= 1000
DOT_TRANSPARENT= YES
DOT_MULTI_TARGETS = NO
GENERATE_LEGEND= YES
DOT_CLEANUP= YES
#---
# Configuration::additions related to the search engine
#---
SEARCHENGINE = YES
# Macro for creating Doxygen output for a project
# Usage:
#create_doxygen(
#${DOCUMENTATION_OUTPUT_PATH}
#${CMAKE_SOURCE_DIR}/mydocs
#mydocs
#${DOCUMENTATION_OUTPUT_PATH}/other.tag=../relative/path/to/other
#${DOCUMENTATION_OUTPUT_PATH}/other2.tag=../relative/path/to/other2
#)
# Copyright 2008-2009 Ben Boeckel
# Redistribution and use is allowed according to the terms of the BSD license.
find_package(Doxygen)
macro (create_doxygen outputdir inputdir name)
foreach (tag ${ARGN})
string(REGEX REPLACE "=.*" "" tagfile ${tag})
set(tagdeps
${tagdeps}
${tagfile}
)
endforeach (tag)
add_custom_command(
OUTPUT
${outputdir}/${name}
COMMAND
cmake -E make_directory ${outputdir}/${name}
COMMENT
"Creating documentation directory for ${name}"
)
add_custom_command(
OUTPUT
${outputdir}/${name}/Doxyfile
COMMAND
sed ${CMAKE_SOURCE_DIR}/Doxyfile
-e 's!PROJECT_SOURCE_DIR!${inputdir}!g'
-e 's!DOCUMENTATION_OUTPUT_PATH!${outputdir}!g'
-e 's!_PROJECT_NAME!${name}!g'
-e 's!TAG_FILES!${ARGN}!g'
> Doxyfile
DEPENDS
${CMAKE_SOURCE_DIR}/Doxyfile
${outputdir}/${name}
WORKING_DIRECTORY
${outputdir}/${name}
COMMENT
"Generating Doxyfile for ${name}"
)
add_custom_command(
OUTPUT
${outputdir}/${name}.tag
COMMAND
${DOXYGEN_EXECUTABLE}
DEPENDS
${outputdir}/${name}/Doxyfile
WORKING_DIRECTORY
${outputdir}/${name}
COMMENT
"Creating tag for ${name}"
)
add_custom_command(
OUTPUT
${outputdir}/${name}/index.html
COMMAND
${DOXYGEN_EXECUTABLE}
DEPENDS
${outputdir}/${name}.tag
${tagdeps}
WORKING_DIRECTORY
${outputdir}/${name}
COMMENT
"Creating HTML documentation for ${name}"
)
add_custom_target(doxygen-${name}
DEPENDS
${outputdir}/${name}/index.html
)
# FIXME
# install(
# DIRECTORY
# ${outputdir}/${name}
# DESTINATION
# ${CMAKE_INSTALL_PREFIX}/share/doc/${CMAKE_PROJECT_NAME}-${SIGEN_VERSION}/${name}
# COMPONENT
# documentation
# )
endmacro (create_doxygen)
___
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 and CxxTest
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wojciech Migda wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi all, > > I was wondering about an improvement for the way CxxTest unit tests > are coupled with CTest. Right now when CTest submits results to CDash > the tests are counted by binaries executed. In my unit tests each > binary corresponds to an entire suite (approx. 150 testcases grouped > within single CxxTest class). I'd see it very useful to have CTest > operate with CxxTest based unit tests on a testcase level. Has anyone > stumbled upon similar problem and got ideas / solutions ? > > Thanks for assistance, > > - -Wojciech I use QTest for my unit tests. These have multiple tests within each one. When one fails, I run ctest -V to get the details. It helps keep output down when tests are working great and only expands when I need it (though automating the ctest -V run is something I haven't looked into yet). - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQIcBAEBAgAGBQJKtkckAAoJEKaxavVX4C1X+4cQALpfG+c5YaVaOspLE7b/ILxA +3KIyWG34rrqpMoXzS72l+j5psDwW3GUpqkLPZdOMCLh6Z4x7Ql+OS7V6y+UuKjv wT+2AY4tk4O4wEV4j4ISQYd1bkGDbBOzAxcbTZnrEx+3dRvvB7Dz8q6sZS875St9 rnPuPPLwCAH4IXQJ+dwdsRg/rJb2vvHGyNRY1rhQ5a/7rca0PqBi38uQQ8zZw840 KYdoi4p+i/Wvv/wX57avrDLVnXMPdFdoT7n7QMM4vk15n0eyoXk19aaTSrRvsiQP ZbXYdgvgOlFBE2Lk9tktR/lzSXX3bGGymqFqYvfX00c06Mtofju0ZHbtEGwp8tad 2m0lSINtg/c+JdFsqp8RQaCv5xC/i285v/B6piQljnWkjBXkXP5bXncOR12qd3F1 Vgvnf71X72l93C6zeVqV0g5+e7ITSvPEWWe0ok40dP4ZAbo9lQ8/UbjTCD7J7XHJ P8YWEG2OCiBaYp+IfTgRyt+EBYW18ig5O8HjZANgxWAG9UNbB00HSw6eEy8q/O5g /OJOsMhMTsQIRSw0Y+5mSIkcMIGclcUDdX3Jpkq+BshOoOqEn+oAEnpkYlPi9TiF KlewIi1QWyW8eMEu8ZJoMy8WH+N4wQPtyPlVllxmlX5MON+s82LLiWMN1aaZf/VH //j+hhkExoZmwhtZbhPR =kQDr -END PGP SIGNATURE- ___ 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
