[cmake-developers] [CMake 0012986]: Portable directory symlinking with -E
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=12986 == Reported By:Dave Abrahams Assigned To: == Project:CMake Issue ID: 12986 Category: CMake Reproducibility:have not tried Severity: feature Priority: low Status: new == Date Submitted: 2012-02-21 03:16 EST Last Modified: 2012-02-21 03:16 EST == Summary:Portable directory symlinking with -E Description: It would be great if I could create an NTFS directory symlink with -E create_symlink == Issue History Date ModifiedUsername FieldChange == 2012-02-21 03:16 Dave Abrahams New Issue == -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Build faild on Darwin? Don't know why?
On Mon, Feb 20, 2012 at 1:53 PM, David Cole david.c...@kitware.com wrote: On Mon, Feb 20, 2012 at 1:47 PM, Clinton Stimpson clin...@elemtech.comwrote: On Feb 20, 2012, at 8:21 AM, David Cole wrote: On Mon, Feb 20, 2012 at 9:25 AM, Brad King brad.k...@kitware.com wrote: On 2/18/2012 5:47 PM, Eric Noulard wrote: My recent commit on CPack-dynamicDocSection http://cmake.org/gitweb?p=**cmake.git;a=shortlog;h=** e175af3e74006e6f3a4fdaead20522**b29034c45bhttp://cmake.org/gitweb?p=cmake.git;a=shortlog;h=e175af3e74006e6f3a4fdaead20522b29034c45b may have broken this build http://open.cdash.org/**testDetails.php?test=**135708291build=2018382http://open.cdash.org/testDetails.php?test=135708291build=2018382 the trouble is I cannot imagine why It seems okay today. It may have been an intermittent problem with the continuous build not being in a fresh tree. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/** opensource/opensource.htmlhttp://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/**CMake_FAQhttp://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-**bin/mailman/listinfo/cmake-**developershttp://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers The lesson here is: - ignore dashboard failures for the BundleGenerator test on Mac machines unless it is happening consistently build after build after build - also ignore any test failures that contain references to a failed run of hdiutil which fails sporadically -- only consider it a real problem with the CMake code if it happens consistently Is it just the Mac OS X 10.4 machines that do this? I remember having this problem on one of our Macs a few times a week, but haven't had that problem for a while. Its running 10.5 now. Clint -- 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 No -- it happens on the Nightly dashboards from dashmacmini5, which is Lion (10.7) and using a very recent (but not the very most recent) Xcode. Our one saving grace is that is is sporadic. Case in point, today's dashmacmini5 build, the X11 test failed with an hdiutil failure: http://open.cdash.org/testDetails.php?test=135942815build=2024241 :-( -- 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] find_package module-only policy
On 2/20/2012 5:43 PM, Brad King wrote: The new find_package option will be called CONFIG, please. Another possibility is to require the mode keywords to come as the first argument, before the package name, just like many other commands: find_package(CONFIG Foo) That will clearly distinguish it from other options that affect the settings within Config mode. I'm still not happy about warning without a CONFIG or NO_MODULE keyword. I think the message wording can be made good enough to solve this problem, especially when the new CONFIG and MODULE keywords can be used *optionally* to get even better messages. Let's focus first on the wording of the current message and see what we can get since it's needed either way and we can always take step (3) later. Here is another idea for the message wording for the default mode when no Find module is present. It explains exactly why CMake is looking for a package configuration file and who is expected to provide what: CMake Error at CMakeLists.txt:7 (find_package): By not providing Findecm.cmake in CMAKE_MODULE_PATH the caller has asked CMake to find a package configuration file provided by ecm, but CMake did not find one. Could not find a package configuration file provided by ecm with any of the names: ecmConfig.cmake ecm-config.cmake Add the installation prefix of ecm to CMAKE_PREFIX_PATH or set ecm_DIR to a directory containing one of the above files. If ecm provides separate development package or SDK be sure it has been installed. The first paragraph explains how CMake is interpreting the intention of the caller. This puts the blame or credit at the call site in the project code where it belongs both when it is a bug and when it is intentional. It can be dropped in explicit CONFIG mode: CMake Error at CMakeLists.txt:7 (find_package): Could not find a package configuration file provided by ecm with any of the names: ecmConfig.cmake ecm-config.cmake Add the installation prefix of ecm to CMAKE_PREFIX_PATH or set ecm_DIR to a directory containing one of the above files. If ecm provides separate development package or SDK be sure it has been installed. In explicit MODULE mode the message can leave out the package config file text altogether (we can add more detail too): CMake Error at CMakeLists.txt:7 (find_package): No Findecm.cmake module is present in CMAKE_MODULE_PATH. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0012987]: Multiple redefinitions with cross compilation for eCos
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=12987 == Reported By:Emmanuel Blot Assigned To: == Project:CMake Issue ID: 12987 Category: CMake Reproducibility:always Severity: minor Priority: low Status: new == Date Submitted: 2012-02-21 09:59 EST Last Modified: 2012-02-21 09:59 EST == Summary:Multiple redefinitions with cross compilation for eCos Description: Using the following sequence to enable eCos cross-compilation (from any host): INCLUDE (CMakeForceCompiler) SET (CMAKE_SYSTEM_NAME eCos) CMAKE_FORCE_C_COMPILER (arm-eabi-gcc GNU) CMAKE_FORCE_CXX_COMPILER (arm-eabi-gcc GNU) whenever the PROJECT() command is invoked, the file Modules/Platform/eCos.cmake is parsed and executed several times (3 times on my current configuration). The net result is that line 45 ADD_DEFINITIONS(-D__ECOS__=1 -D__ECOS=1) is executed 3 times, and the definitions are appended to each other. Running CMake with the VERBOSE flag enables shows that the command line is filled in with the same definitions: arm-eabi-gcc -D__ECOS__=1 -D__ECOS=1 -D__ECOS__=1 -D__ECOS=1 -D__ECOS__=1 -D__ECOS=1 == Issue History Date ModifiedUsername FieldChange == 2012-02-21 09:59 Emmanuel Blot New Issue == -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] New group on the CMake dashboard
I've created a group called Temporarily Problematic Nightly on the CMake dashboard today. It's for dashboards which chronically fail for reasons beyond our control. The two submissions that I sent to that group are using the Visual Studio 11 generator and the VS 11 Developer Preview from MSFT. At the moment, there are random crashes of MSBuild when running our dashboards. Usually on different tests each night, sometimes even on the build of CMake itself. I'm fairly certain these crashes are no fault of CMake's, and we are hoping that MSFT will fix them before they make VS11 a final release. If/when that happens, and the dashboard submissions from this machine are green again, I'll move them back to Nightly Expected. Let me know if you object to this in any way... I'm not attached to this particular group name, but I do want it to include Nightly in the name. Also, CDash should not send out any failure emails from this group. Please let me know if you have any thoughts here. Thx, 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0012991]: Parallel build output mess
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=12991 == Reported By:Christopher Sean Morrison Assigned To: == Project:CMake Issue ID: 12991 Category: CMake Reproducibility:always Severity: text Priority: normal Status: new == Date Submitted: 2012-02-21 14:38 EST Last Modified: 2012-02-21 14:38 EST == Summary:Parallel build output mess Description: Under Additional Information and attached as an image is an example of the interleaved mess currently being output with a parallel build. The percentages are apparently printed independently from the statements that follow causing interleaved output and wrong ansi-color coding (on the percentages). The percentage should be buffered with their statement so that they're printed/colored together. Also of note, the final make: *** [all] Error 2 has absolutely nothing to do with the 200+ lines being shown... The actual error was several hundred lines before. Additional Information: [...massive snip...] Building C object src/liboptical/CMakeFiles/liboptical-static.dir/sh_stxt.c.o Building C object src/liboptical/CMakeFiles/liboptical-static.dir/sh_tcl.c.o Building C object src/liboptical/CMakeFiles/liboptical-static.dir/sh_stack.c.o Building C object src/liboptical/CMakeFiles/liboptical.dir/sh_treetherm.c.o Building C object src/liboptical/CMakeFiles/liboptical-static.dir/sh_text.c.o /usr/bin/ld: warning: librt.so.1, needed by /usr/lib64/libdrm.so.2, may conflict with librt.so.19 [ 67%] [ 67%] [ 67%] [ 67%] [ 67%] [ 67%] [ 67%] [ 67%] [ 67%] Building C object src/liboptical/CMakeFiles/liboptical-static.dir/sh_toyota.c.o Building C object src/liboptical/CMakeFiles/liboptical.dir/sh_wood.c.o Building C object src/liboptical/CMakeFiles/liboptical-static.dir/sh_treetherm.c.o Linking C executable ../../bin/tabinterp Building C object src/liboptical/CMakeFiles/liboptical-static.dir/sh_wood.c.o Built target nirt Building C object src/liboptical/CMakeFiles/liboptical-static.dir/sh_toon.c.o Building C object src/liboptical/CMakeFiles/liboptical-static.dir/sh_xxx.c.o Building C object src/liboptical/CMakeFiles/liboptical-static.dir/shade.c.o Building C object src/liboptical/CMakeFiles/liboptical.dir/sh_xxx.c.o [ 67%] Building C object src/liboptical/CMakeFiles/liboptical-static.dir/turb.c.o [ 67%] Built target secpass [ 67%] Built target vdeck [ 67%] [ 67%] Building C object src/liboptical/CMakeFiles/liboptical-static.dir/vers.c.o Building C object src/liboptical/CMakeFiles/liboptical-static.dir/wray.c.o [ 67%] Building C object src/liboptical/CMakeFiles/liboptical.dir/shade.c.o [ 67%] [ 67%] Building C object src/liboptical/CMakeFiles/liboptical.dir/turb.c.o Building C object src/liboptical/CMakeFiles/liboptical.dir/vers.c.o [ 67%] Linking C static library ../../lib/librtserver.a Linking C executable ../../bin/firpass Building C object src/liboptical/CMakeFiles/liboptical.dir/wray.c.o [ 67%] Built target tabinterp [ 67%] [ 67%] [ 67%] Built target libmultispectral Built target rtserver-static Built target rtserver [ 67%] Built target firpass Linking CXX static library ../../lib/libpc.a Linking C executable ../../bin/burst Linking C executable ../../bin/lgt Linking CXX static library ../../lib/libwdb.a /usr/bin/ld: warning: librt.so.1, needed by /usr/lib64/libdrm.so.2, may conflict with librt.so.19 [ 67%] Built target burst [ 67%] Built target libpc-static /usr/bin/ld: warning: librt.so.1, needed by /usr/lib64/libdrm.so.2, may conflict with librt.so.19 [ 67%] Built target lgt Linking CXX shared library ../../lib/libpc.so Linking C static library ../../lib/liboptical.a Linking C shared library ../../lib/liboptical.so [ 67%] Built target libwdb-static Linking CXX shared library ../../lib/libwdb.so Linking C executable ../../../bin/g-iges [ 67%] Built target liboptical [ 67%] Built target g-iges [ 67%] Built target liboptical-static [ 67%] [ 67%] Built target libwdb Built target libpc make: *** [all] Error 2 [sean@gcc1-power7 .cmake]$ == Issue History Date ModifiedUsername FieldChange == 2012-02-21 14:38 Christopher Sean MorrisonNew Issue 2012-02-21 14:38 Christopher Sean MorrisonFile Added: messy.png
[cmake-developers] [CMake 0012992]: CHECK_C_COMPILER_FLAG broken for icc
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=12992
==
Reported By:Christopher Sean Morrison
Assigned To:
==
Project:CMake
Issue ID: 12992
Category: CMake
Reproducibility:always
Severity: major
Priority: normal
Status: new
==
Date Submitted: 2012-02-21 14:56 EST
Last Modified: 2012-02-21 14:56 EST
==
Summary:CHECK_C_COMPILER_FLAG broken for icc
Description:
It looks like the CHECK_C_COMPILER_FLAG is outright broken for the Intel
compiler (icc).
Similar to llvm's C compiler, icc *recognizes* many command-line flags supported
by gcc, but it does nothing with them. The compiler outputs a warning during
compilation (haven't found a way to turn it into an error) and the compilation
proceeds. See the Additional Information for an example using the famliar
-pedantic gcc flag.
While for most flags, the failed test merely results in flags getting add added
that do nothing, from a build system perspective it results in tests passing
that should not have. This results in incorrect build system behavior and
*excessively* noisy build output for all the various unsupported flags being
warned about repeatedly.
One of our compilation modes, for example, puts the compiler into strict
standards conformance mode so we can perform source code regression and
portability testing. Being able to select the right compilation flags is
necessary for that mode to work correctly. With other flags (e.g., -kPIC,
-fPIC, etc), you get outright wrong behavior that makes the linker cry when
linking against libraries compiled wrong.
Additional Information:
STATUS: Performing Test PEDANTIC_COMPILER_FLAG_FOUND
STATUS: Performing Test PEDANTIC_COMPILER_FLAG_FOUND - Success
Performing C SOURCE FILE Test PEDANTIC_COMPILER_FLAG_FOUND succeded with the
following output:
Change Dir: /home/morrison/brlcad/.cmake/CMakeFiles/CMakeTmp
Run Build Command:/usr/bin/gmake cmTryCompileExec/fast
/usr/bin/gmake -f CMakeFiles/cmTryCompileExec.dir/build.make
CMakeFiles/cmTryCompileExec.dir/build
gmake[1]: Entering directory `/home/morrison/brlcad/.cmake/CMakeFiles/CMakeTmp'
/home/morrison/Applications/bin/cmake -E cmake_progress_report
/home/morrison/brlcad/.cmake/CMakeFiles/CMakeTmp/CMakeFiles 1
Building C object CMakeFiles/cmTryCompileExec.dir/src.c.o
/opt/intel/bin/icc -DPEDANTIC_COMPILER_FLAG_FOUND -I/usr/local/include
-pedantic -o CMakeFiles/cmTryCompileExec.dir/src.c.o -c
/home/morrison/brlcad/.cmake/CMakeFiles/CMakeTmp/src.c
icc: command line remark http://public.kitware.com/Bug/view.php?id=10148: option
'-pedantic' not supported
Linking C executable cmTryCompileExec
/home/morrison/Applications/bin/cmake -E cmake_link_script
CMakeFiles/cmTryCompileExec.dir/link.txt --verbose=1
/opt/intel/bin/icc -DPEDANTIC_COMPILER_FLAG_FOUND
CMakeFiles/cmTryCompileExec.dir/src.c.o -o cmTryCompileExec -rdynamic
gmake[1]: Leaving directory `/home/morrison/brlcad/.cmake/CMakeFiles/CMakeTmp'
Source file was:
int main(void) { return 0; }
==
Issue History
Date ModifiedUsername FieldChange
==
2012-02-21 14:56 Christopher Sean MorrisonNew Issue
==
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Making Config.cmake files easier to write
On Friday 17 February 2012, Alexander Neundorf wrote: On Thursday 16 February 2012, Brad King wrote: On 2/16/2012 1:24 PM, Alexander Neundorf wrote: Actually I expected I would prefer this over the fixed names, but now that I've done it and look at what Config.cmake.in file I have to write, I think I liked the previous version with the fixed names (CONFIG_HELPER) better. I think it was easier to do, a simple scheme. I think the fixed names are better/simpler too. I'm not fond of CONFIG_HELPER specifically. The information stored in them is about the *package* that the file is configuring, which is why I originally proposed the prefix PACKAGE_. The INCLUDE_INSTALL_DIR is where the *package* goes, not where the config helper is/goes. It's also the same as the package version file input/output variable names. I looked a bit around cmFindPackage. It has a parameter CONFIGS, it has a Config mode and the documentation and error messages use configuration file. So, I'm not that sure that using PACKAGE instead of CONFIG is really better (the branch I pushed uses PACKAGE, but I could change this again). Ok, so we stay here with PACKAGE, also in the light of the new CONFIG keyword for find_package() ? Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] find_package module-only policy (was: find_package error wording)
On Monday 20 February 2012, Alexander Neundorf wrote: On Monday 20 February 2012, Brad King wrote: ... (2) Add the explicit MODULE and CONFIG mode keywords. Warn if they are used and the current minimum CMake version is not = 2.8.8 so that people do not add them in places that will break old versions. (3) Add two possible AUTHOR_WARNING messages in the case that no mode keyword or Find module is present: - If the current minimum CMake required version is = 2.8.8 then warn that MODULE or CONFIG should be used. - Otherwise if CMAKE_FIND_PACKAGE_WARN_NO_MODULE is set to true then warn that NO_MODULE should be used to get the config mode. There is now a branch FindPackage_ModeWarning on stage. I should have probably pushed all my commits to this branch... Done now. Working on your suggestions. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Making Config.cmake files easier to write
On 2/21/2012 3:17 PM, Alexander Neundorf wrote: On Friday 17 February 2012, Alexander Neundorf wrote: So, I'm not that sure that using PACKAGE instead of CONFIG is really better (the branch I pushed uses PACKAGE, but I could change this again). Ok, so we stay here with PACKAGE, also in the light of the new CONFIG keyword for find_package() ? Yes. The information contained in the generated variable values is about the target package, not about the configuration file storing the info. 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] find_package module-only policy (was: find_package error wording)
On Tuesday 21 February 2012, Alexander Neundorf wrote: On Monday 20 February 2012, Alexander Neundorf wrote: On Monday 20 February 2012, Brad King wrote: ... (2) Add the explicit MODULE and CONFIG mode keywords. Warn if they are used and the current minimum CMake version is not = 2.8.8 so that people do not add them in places that will break old versions. (3) Add two possible AUTHOR_WARNING messages in the case that no mode keyword or Find module is present: - If the current minimum CMake required version is = 2.8.8 then warn that MODULE or CONFIG should be used. - Otherwise if CMAKE_FIND_PACKAGE_WARN_NO_MODULE is set to true then warn that NO_MODULE should be used to get the config mode. There is now a branch FindPackage_ModeWarning on stage. I should have probably pushed all my commits to this branch... Done now. Working on your suggestions. Problem ? Somebody has a FindConfig.cmake here: http://lists.gforge.inria.fr/pipermail/blobseer-commits/2009- January/000101.html There may be also a FindCONFIG.cmake or a FindMODULE.cmake somewhere... Even so with FindConfig.cmake, if this runs on Windows, they might be doing find_package(CONFIG REQUIRED) Now it searches for the required package FindCONFIG.cmake. Then it would search for REQUIREDConfig.cmake... Using the next argument only as package name if it is not a known keyword or version number would lead to even more non-working package names: HINTS, PATHS, CONFIGS, 123, REQUIRED, COMPONENTS, NAMES (I left all keywords which have an underscore out, it is probably too unlikely that there is a FindPATH_SUFFIXES.cmake). Ignore and just hope it will be ok ? Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] _check_cxx_compiler_attribute macro from GenerateExportHeader.cmake
This macro does this:
macro(_check_cxx_compiler_attribute _ATTRIBUTE _RESULT)
check_cxx_source_compiles(${_ATTRIBUTE} int somefunc() { return 0; }
int main() { return somefunc();} ${_RESULT}
# Some compilers do not fail with a bad flag
FAIL_REGEX unrecognized .*option # GNU
FAIL_REGEX ignoring unknown option # MSVC
FAIL_REGEX warning D9002 # MSVC, any lang
FAIL_REGEX [Uu]nknown option # HP
FAIL_REGEX [Ww]arning: [Oo]ption # SunPro
FAIL_REGEX command option .* is not recognized # XL
)
endmacro()
The FAIL_REGEX were copied from CheckCXXCompilerFlag and are to match errors
about broken command line arguments. I doubt they make any sense at this
point. Is this intentional or by accident?
Eike
signature.asc
Description: This is a digitally signed message part.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] _check_cxx_compiler_attribute macro from GenerateExportHeader.cmake
Rolf Eike Beer wrote:
This macro does this:
macro(_check_cxx_compiler_attribute _ATTRIBUTE _RESULT)
check_cxx_source_compiles(${_ATTRIBUTE} int somefunc() { return 0; }
int main() { return somefunc();} ${_RESULT}
# Some compilers do not fail with a bad flag
FAIL_REGEX unrecognized .*option # GNU
FAIL_REGEX ignoring unknown option # MSVC
FAIL_REGEX warning D9002 # MSVC, any
lang
FAIL_REGEX [Uu]nknown option # HP
FAIL_REGEX [Ww]arning: [Oo]ption # SunPro
FAIL_REGEX command option .* is not recognized # XL
)
endmacro()
The FAIL_REGEX were copied from CheckCXXCompilerFlag and are to match
errors about broken command line arguments. I doubt they make any sense at
this point. Is this intentional or by accident?
When you say 'not make any sense' what do you mean?
Thanks,
Steve.
--
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] GenerateExportHeader gcc version test failure?
Stephen Kelly wrote: Hi, In the last few days something changed to make the GenerateExportHeader GCC version check fail: http://open.cdash.org/buildSummary.php?buildid=2016288 Any idea what would cause that? It must be one of these: http://open.cdash.org/viewUpdate.php?buildid=2016288 Note that the GenerateExportHeader_MinorFix makes the problem go away, but doesn't explain why the problem occured in the first place. Thanks, Steve. -- 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] _check_cxx_compiler_attribute macro from GenerateExportHeader.cmake
Stephen Kelly wrote:
Rolf Eike Beer wrote:
This macro does this:
macro(_check_cxx_compiler_attribute _ATTRIBUTE _RESULT)
check_cxx_source_compiles(${_ATTRIBUTE} int somefunc() { return 0; }
int main() { return somefunc();} ${_RESULT}
# Some compilers do not fail with a bad flag
FAIL_REGEX unrecognized .*option # GNU
FAIL_REGEX ignoring unknown option # MSVC
FAIL_REGEX warning D9002 # MSVC, any
lang
FAIL_REGEX [Uu]nknown option # HP
FAIL_REGEX [Ww]arning: [Oo]ption # SunPro
FAIL_REGEX command option .* is not recognized # XL
)
endmacro()
The FAIL_REGEX were copied from CheckCXXCompilerFlag and are to match
errors about broken command line arguments. I doubt they make any sense at
this point. Is this intentional or by accident?
When you say 'not make any sense' what do you mean?
You don't want to check for errors coming from bad command line options here,
do you? So why are there expressions there at all?
Eike
signature.asc
Description: This is a digitally signed message part.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] more targets to run in parallel
Anyway just to answer myself, I managed to solve all my problems.
Now I first generate at cmake file a file with some paths, and from
these paths I generate all the targets that I need.
I also create a list with all the targets to make it easy from other
targets to depend on them.
Here below the simplified code (if there are better ways I'm all hears)
foreach (egg ${egg_list})
get_filename(${egg})
set(egg_install ${RESULT_VAR}_install)
add_custom_target(${egg_install})
# generate the list of targets to create more easily dependencies
list(APPEND target_install_list ${egg_install})
add_custom_command(
TARGET ${egg_install}
COMMAND ${PYTHON_EXECUTABLE} setup.py bdist_egg -d
${EGG_BUILD_DIRECTORY}
WORKING_DIRECTORY ${egg}
)
endforeach ()
add_custom_target(install_all_eggs ALL
DEPENDS ${target_install_list}
)
--
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] multi platform path
I want to be able to have this simple translation between full path and
filename.
For example = /very/long/path/file.py - file.py
So I did this quite ugly function:
function (get_filename FULLPATH)
string(REPLACE / ; p2list ${FULLPATH})
list(REVERSE p2list)
list(GET p2list 0 last)
set(RESULT_VAR ${last} PARENT_SCOPE)
endfunction()
but the problem is that it doesn't work on windows unfortunately.
Is there some library/code to do multi-platform path manipulations in
CMake maybe?
get_filename_component()
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] custom command and differences between VS2005 and VS2010
I tried this out with VS 2010 SP0 Win64. Here's my CMakeLists:
cmake_minimum_required(VERSION 2.8)
project(Test CXX)
file(WRITE foo.h //Some Foo Header )
file(WRITE foo.cpp int main(int argc, char** argv) { return 0; }\n)
file(WRITE foo.txt This is the foo text file (simulated config))
set( etc_hdrs foo.h)
set( etc_srcs foo.cpp foo.txt)
add_custom_target( etc SOURCES ${etc_hdrs} ${etc_srcs} )
For me, the resulting VS Solution has the text file as a member of the
project:
Also ended up with an item named 'etc', which seems wrong.. not sure why
that would have happened. I'm using CMake 2.8.7 on Windows 7. I wonder
if there is something else that is a problem. What version of CMake are
you using?
Aaron Meadows
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf
Of walter.schw...@dzbank.de
Sent: Monday, February 20, 2012 5:37 AM
To: cmake@cmake.org
Subject: [CMake] custom command and differences between VS2005 and
VS2010
our project contains a directory with config files. to make the config
files (and other externally supplied header files) visible in the visual
studio solution, the custom command shown below was specified in the
directory.
this worked well with the generator for Visual Studio 2005. it doesn't
any more with the generator for visual studio 2010.
- is this intentional or is it a bug?
- what can i do to fix this?
/regards Walter Schwarz
# Targets: none - placeholder for Murex headers
#
# Library: none
#
set( etc_hdrs
${FLEX_INCLUDE_DIRS}/mdtypes.h
... list shortened ...
)
set( etc_srcs FlexModelConfig.cfg configFile.txt )
include_directories(
${FLEX_INCLUDE_DIRS}
)
add_custom_target( etc SOURCES ${etc_hdrs} ${etc_srcs} )
This email was sent to you by Thomson Reuters, the global news and information
company. Any views expressed in this message are those of the individual
sender, except where the sender specifically states them to be the views of
Thomson Reuters.image001.png--
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] multi platform path
On 02/21/2012 01:39 PM, Rolf Eike Beer wrote: get_filename_component() 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://www.cmake.org/mailman/listinfo/cmake Thank you both that 's what I was looking for :) -- 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] Shared intermediary files
Can you clarify your setup just a bit? Do you have two ways you configure the build tree, once as Dynamic and once as Static libraries? And you are building both at the same time? Or Are you are calling add_library() twice with the same input files but specifying SHARED on one of them, so they are all building together in one project (i.e. Visual Studio Solution)? Or Doing something completely different? Aaron Meadows From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Kevin Schmidt Sent: Monday, February 20, 2012 3:07 PM To: cmake@cmake.org Subject: [CMake] Shared intermediary files Hello, I'm in the process of converting over a large, monolithic tree with many libraries from a custom build solution over to cmake. So far, we've loved it. I am wondering about others' solutions to a problem we have encountered. We have more than a few cases of generated source files - for example, Qt moc files. These all get dumped into CMAKE_CURRENT_BINARY_DIR. Now, the libraries we have build both static shared, and have the same source files. In Visual Studio, this generates two projects in the solution. It seems that these do not share dependencies. Occasionally, this means that both libraries try to write to the generated source file at the same time, which generates a (false) build failure. What do others do? Am I misunderstanding something? Kevin This email was sent to you by Thomson Reuters, the global news and information company. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Thomson Reuters.-- 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] Shared intermediary files
Hi - Actually, I have two calls to add_library, so they are in two projects, but ONE solution. They are built simultaneously by the BUILD_ALL target Kevin From: aaron.mead...@thomsonreuters.com [mailto:aaron.mead...@thomsonreuters.com] Sent: Tuesday, February 21, 2012 9:06 AM To: Kevin Schmidt; cmake@cmake.org Subject: RE: [CMake] Shared intermediary files Can you clarify your setup just a bit? Do you have two ways you configure the build tree, once as Dynamic and once as Static libraries? And you are building both at the same time? Or Are you are calling add_library() twice with the same input files but specifying SHARED on one of them, so they are all building together in one project (i.e. Visual Studio Solution)? Or Doing something completely different? Aaron Meadows From: cmake-boun...@cmake.orgmailto:cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org]mailto:[mailto:cmake-boun...@cmake.org] On Behalf Of Kevin Schmidt Sent: Monday, February 20, 2012 3:07 PM To: cmake@cmake.orgmailto:cmake@cmake.org Subject: [CMake] Shared intermediary files Hello, I'm in the process of converting over a large, monolithic tree with many libraries from a custom build solution over to cmake. So far, we've loved it. I am wondering about others' solutions to a problem we have encountered. We have more than a few cases of generated source files - for example, Qt moc files. These all get dumped into CMAKE_CURRENT_BINARY_DIR. Now, the libraries we have build both static shared, and have the same source files. In Visual Studio, this generates two projects in the solution. It seems that these do not share dependencies. Occasionally, this means that both libraries try to write to the generated source file at the same time, which generates a (false) build failure. What do others do? Am I misunderstanding something? Kevin This email was sent to you by Thomson Reuters, the global news and information company. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Thomson Reuters. -- 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] Shared intermediary files
I'm not sure why there would be a conflict on the generated files (unless you are generating them at Build time rather than at CMake time), but you can probably solve the issue by making one version of the Library depend on the other version, thus preventing them from building at the same time. Someone with more experience may be able to jump in hear and give a better answer.. Aaron Meadows From: Kevin Schmidt [mailto:ke...@eyesopen.com] Sent: Tuesday, February 21, 2012 8:09 AM To: Meadows, Aaron C.; cmake@cmake.org Subject: RE: [CMake] Shared intermediary files Hi - Actually, I have two calls to add_library, so they are in two projects, but ONE solution. They are built simultaneously by the BUILD_ALL target Kevin From: aaron.mead...@thomsonreuters.com [mailto:aaron.mead...@thomsonreuters.com] Sent: Tuesday, February 21, 2012 9:06 AM To: Kevin Schmidt; cmake@cmake.org Subject: RE: [CMake] Shared intermediary files Can you clarify your setup just a bit? Do you have two ways you configure the build tree, once as Dynamic and once as Static libraries? And you are building both at the same time? Or Are you are calling add_library() twice with the same input files but specifying SHARED on one of them, so they are all building together in one project (i.e. Visual Studio Solution)? Or Doing something completely different? Aaron Meadows From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Kevin Schmidt Sent: Monday, February 20, 2012 3:07 PM To: cmake@cmake.org Subject: [CMake] Shared intermediary files Hello, I'm in the process of converting over a large, monolithic tree with many libraries from a custom build solution over to cmake. So far, we've loved it. I am wondering about others' solutions to a problem we have encountered. We have more than a few cases of generated source files - for example, Qt moc files. These all get dumped into CMAKE_CURRENT_BINARY_DIR. Now, the libraries we have build both static shared, and have the same source files. In Visual Studio, this generates two projects in the solution. It seems that these do not share dependencies. Occasionally, this means that both libraries try to write to the generated source file at the same time, which generates a (false) build failure. What do others do? Am I misunderstanding something? Kevin This email was sent to you by Thomson Reuters, the global news and information company. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Thomson Reuters. This email was sent to you by Thomson Reuters, the global news and information company. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Thomson Reuters.-- 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] Shared intermediary files
Yes, for clarity, we do generate the files at build time, not cmake time. Kevin From: aaron.mead...@thomsonreuters.com [mailto:aaron.mead...@thomsonreuters.com] Sent: Tuesday, February 21, 2012 9:14 AM To: Kevin Schmidt; cmake@cmake.org Subject: RE: [CMake] Shared intermediary files I'm not sure why there would be a conflict on the generated files (unless you are generating them at Build time rather than at CMake time), but you can probably solve the issue by making one version of the Library depend on the other version, thus preventing them from building at the same time. Someone with more experience may be able to jump in hear and give a better answer.. Aaron Meadows From: Kevin Schmidt [mailto:ke...@eyesopen.com]mailto:[mailto:ke...@eyesopen.com] Sent: Tuesday, February 21, 2012 8:09 AM To: Meadows, Aaron C.; cmake@cmake.orgmailto:cmake@cmake.org Subject: RE: [CMake] Shared intermediary files Hi - Actually, I have two calls to add_library, so they are in two projects, but ONE solution. They are built simultaneously by the BUILD_ALL target Kevin From: aaron.mead...@thomsonreuters.commailto:aaron.mead...@thomsonreuters.com [mailto:aaron.mead...@thomsonreuters.com]mailto:[mailto:aaron.mead...@thomsonreuters.com] Sent: Tuesday, February 21, 2012 9:06 AM To: Kevin Schmidt; cmake@cmake.orgmailto:cmake@cmake.org Subject: RE: [CMake] Shared intermediary files Can you clarify your setup just a bit? Do you have two ways you configure the build tree, once as Dynamic and once as Static libraries? And you are building both at the same time? Or Are you are calling add_library() twice with the same input files but specifying SHARED on one of them, so they are all building together in one project (i.e. Visual Studio Solution)? Or Doing something completely different? Aaron Meadows From: cmake-boun...@cmake.orgmailto:cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org]mailto:[mailto:cmake-boun...@cmake.org] On Behalf Of Kevin Schmidt Sent: Monday, February 20, 2012 3:07 PM To: cmake@cmake.orgmailto:cmake@cmake.org Subject: [CMake] Shared intermediary files Hello, I'm in the process of converting over a large, monolithic tree with many libraries from a custom build solution over to cmake. So far, we've loved it. I am wondering about others' solutions to a problem we have encountered. We have more than a few cases of generated source files - for example, Qt moc files. These all get dumped into CMAKE_CURRENT_BINARY_DIR. Now, the libraries we have build both static shared, and have the same source files. In Visual Studio, this generates two projects in the solution. It seems that these do not share dependencies. Occasionally, this means that both libraries try to write to the generated source file at the same time, which generates a (false) build failure. What do others do? Am I misunderstanding something? Kevin This email was sent to you by Thomson Reuters, the global news and information company. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Thomson Reuters. This email was sent to you by Thomson Reuters, the global news and information company. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Thomson Reuters. -- 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] Shared intermediary files
If possible, you might want to see about doing all the generation at CMake time. That should allow you to still build in parallel, unless you need them to be generated differently for each one (in which case, you should probably try to generate them in a subdirectory specific to each target). Aaron Meadows From: Kevin Schmidt [mailto:ke...@eyesopen.com] Sent: Tuesday, February 21, 2012 8:26 AM To: Meadows, Aaron C.; cmake@cmake.org Subject: RE: [CMake] Shared intermediary files Yes, for clarity, we do generate the files at build time, not cmake time. Kevin From: aaron.mead...@thomsonreuters.com [mailto:aaron.mead...@thomsonreuters.com] Sent: Tuesday, February 21, 2012 9:14 AM To: Kevin Schmidt; cmake@cmake.org Subject: RE: [CMake] Shared intermediary files I'm not sure why there would be a conflict on the generated files (unless you are generating them at Build time rather than at CMake time), but you can probably solve the issue by making one version of the Library depend on the other version, thus preventing them from building at the same time. Someone with more experience may be able to jump in hear and give a better answer.. Aaron Meadows From: Kevin Schmidt [mailto:ke...@eyesopen.com] Sent: Tuesday, February 21, 2012 8:09 AM To: Meadows, Aaron C.; cmake@cmake.org Subject: RE: [CMake] Shared intermediary files Hi - Actually, I have two calls to add_library, so they are in two projects, but ONE solution. They are built simultaneously by the BUILD_ALL target Kevin From: aaron.mead...@thomsonreuters.com [mailto:aaron.mead...@thomsonreuters.com] Sent: Tuesday, February 21, 2012 9:06 AM To: Kevin Schmidt; cmake@cmake.org Subject: RE: [CMake] Shared intermediary files Can you clarify your setup just a bit? Do you have two ways you configure the build tree, once as Dynamic and once as Static libraries? And you are building both at the same time? Or Are you are calling add_library() twice with the same input files but specifying SHARED on one of them, so they are all building together in one project (i.e. Visual Studio Solution)? Or Doing something completely different? Aaron Meadows From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Kevin Schmidt Sent: Monday, February 20, 2012 3:07 PM To: cmake@cmake.org Subject: [CMake] Shared intermediary files Hello, I'm in the process of converting over a large, monolithic tree with many libraries from a custom build solution over to cmake. So far, we've loved it. I am wondering about others' solutions to a problem we have encountered. We have more than a few cases of generated source files - for example, Qt moc files. These all get dumped into CMAKE_CURRENT_BINARY_DIR. Now, the libraries we have build both static shared, and have the same source files. In Visual Studio, this generates two projects in the solution. It seems that these do not share dependencies. Occasionally, this means that both libraries try to write to the generated source file at the same time, which generates a (false) build failure. What do others do? Am I misunderstanding something? Kevin This email was sent to you by Thomson Reuters, the global news and information company. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Thomson Reuters. This email was sent to you by Thomson Reuters, the global news and information company. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Thomson Reuters. This email was sent to you by Thomson Reuters, the global news and information company. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Thomson Reuters.-- 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] Shared intermediary files
On Mon, Feb 20, 2012 at 4:07 PM, Kevin Schmidt ke...@eyesopen.com wrote: Hello, I’m in the process of converting over a large, monolithic tree with many libraries from a custom build solution over to cmake. So far, we’ve loved it. I am wondering about others’ solutions to a problem we have encountered. We have more than a few cases of generated source files - for example, Qt moc files. These all get dumped into CMAKE_CURRENT_BINARY_DIR. Now, the libraries we have build both static shared, and have the same source files. In Visual Studio, this generates two projects in the solution. It seems that these do not share dependencies. Occasionally, this means that both libraries try to write to the generated source file at the same time, which generates a (false) build failure. What do others do? Am I misunderstanding something? I have my batch build script that calls cmake --build for each configuration build 2 times. This works for almost all cases. However when building VTK in parallel the generation of 1 unicode header usually fails. John -- 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] Common Properties in Visual Studio
Hi all. I was wondering if someone ever have used CMake to configure a .NET project, where one need to add References in: Common Properties - Framework and References I need to locate some .dll-files from a .NET API and add those as references to a project to be able to build against it. I haven't found any relevant info on the web nor in the CMake documentation. Have anyone succeeded in doing this? Or is it outside the scope of CMake? Cheers and thanks for a great tool. /A -- __ Anders Backman, HPC2N 90187 Umeå University, Sweden and...@cs.umu.se http://www.hpc2n.umu.se Cell: +46-70-392 64 67 -- 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] Common Properties in Visual Studio
I'm pretty sure that CMake does not directly support .NET projects. Here, we handle the csharp projects in visual studio and then use the include_external_msproject stuff to pull them in. In our case, we had to apply a patch to get it working correctly. (see: http://www.cmake.org/Bug/print_bug_page.php?bug_id=9742 ) We used the patch titled: 0001-ms-external-project-.NET-project-support-GUID-fixed.patch Aaron Meadows From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Anders Backman Sent: Tuesday, February 21, 2012 9:55 AM To: cmake Subject: [CMake] Common Properties in Visual Studio Hi all. I was wondering if someone ever have used CMake to configure a .NET project, where one need to add References in: Common Properties - Framework and References I need to locate some .dll-files from a .NET API and add those as references to a project to be able to build against it. I haven't found any relevant info on the web nor in the CMake documentation. Have anyone succeeded in doing this? Or is it outside the scope of CMake? Cheers and thanks for a great tool. /A -- __ Anders Backman, HPC2N 90187 Umeå University, Sweden and...@cs.umu.se http://www.hpc2n.umu.se Cell: +46-70-392 64 67 This email was sent to you by Thomson Reuters, the global news and information company. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Thomson Reuters.-- 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 issues
I'm trying to finally create an installer for my project, with CPack and
NSIS.
The project is really really simple, I just need to copy over a
directory somewhere.
And I did something like:
get_filename_component(userprofile $ENV{USERPROFILE} REALPATH)
install(
DIRECTORY ${EGG_BUILD_DIRECTORY}
DESTINATION ${userprofile}/${PROJECT_NAME}
)
The first line is because CPack was exploding using the USERPROFILE, because
it was getting non quoted backslash.
So is it the way to handle windows path variables?
The packing, however, doesn't work and I get something like (from the
NSIS generated log file):
!insertmacro: end of MUI_RESERVEFILE_INSTALLOPTIONS
Section: -Core installation
SetOutPath: $INSTDIR
File: Returning to: H:/long_path/_CPack_Packages/win32/NSIS/Minimum
Drag-0.1.1-win32
File: H:/long_path/_CPack_Packages/win32/NSIS/Minimum
Drag-0.1.1-win32\*.* - no files found.
Usage: File [/nonfatal] [/a] ([/r] [/x filespec [...]] filespec [...] |
/oname=outfile one_file_only)
Error in script
H:/git_projs/Minimum_Drag/airbus.application.minimum_drag/_CPack_Packages/win32/NSIS/project.nsi
on line 640 -- aborting creation process
These are the variables that I defined
set(CPACK_NSIS_INSTALLED_ICON_NAME ${PROJECT_NAME})
set(CPACK_PACKAGE_ICON Company)
set(CPACK_NSIS_PACKAGE_NAME ${PROJECT_NAME})
set(CPACK_RESOURCE_FILE_LICENSE ${CMAKE_CURRENT_SOURCE_DIR}/COPYRIGHT.txt)
set(CPACK_PACKAGE_VERSION_MAJOR 0)
set(CPACK_PACKAGE_VERSION_MINOR 1)
set(CPACK_CREATE_DESKTOP_LINKS ${PROJECT_NAME})
set(CPACK_PACKAGE_INSTALL_DIRECTORY ${PROJECT_NAME}) # add the version
numbers
set(CPACK_PACKAGE_DESCRIPTION Package ${PROJECT_NAME})
is there anything missing?
Any idea what that could be?
--
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 issues
Use:
DESTINATION ${PROJECT_NAME}
instead of the full path you're trying to use.
If you use a full path in a CMake install rule, then CPack does not put it
inside the directory that NSIS packs up to build the installer... If you
use a non-full path, then for make install it gets put under
CMAKE_INSTALL_PREFIX, and for the CPack-based install, it gets put in the
directory that NSIS packs up...
HTH,
David
On Tue, Feb 21, 2012 at 12:40 PM, Andrea Crotti
andrea.crott...@gmail.comwrote:
I'm trying to finally create an installer for my project, with CPack and
NSIS.
The project is really really simple, I just need to copy over a directory
somewhere.
And I did something like:
get_filename_component(**userprofile $ENV{USERPROFILE} REALPATH)
install(
DIRECTORY ${EGG_BUILD_DIRECTORY}
DESTINATION ${userprofile}/${PROJECT_NAME}
)
The first line is because CPack was exploding using the USERPROFILE,
because
it was getting non quoted backslash.
So is it the way to handle windows path variables?
The packing, however, doesn't work and I get something like (from the NSIS
generated log file):
!insertmacro: end of MUI_RESERVEFILE_INSTALLOPTIONS
Section: -Core installation
SetOutPath: $INSTDIR
File: Returning to: H:/long_path/_CPack_Packages/**win32/NSIS/Minimum
Drag-0.1.1-win32
File: H:/long_path/_CPack_Packages/**win32/NSIS/Minimum
Drag-0.1.1-win32\*.* - no files found.
Usage: File [/nonfatal] [/a] ([/r] [/x filespec [...]] filespec [...] |
/oname=outfile one_file_only)
Error in script H:/git_projs/Minimum_Drag/**airbus.application.minimum_**
drag/_CPack_Packages/win32/**NSIS/project.nsi on line 640 -- aborting
creation process
These are the variables that I defined
set(CPACK_NSIS_INSTALLED_ICON_**NAME ${PROJECT_NAME})
set(CPACK_PACKAGE_ICON Company)
set(CPACK_NSIS_PACKAGE_NAME ${PROJECT_NAME})
set(CPACK_RESOURCE_FILE_**LICENSE ${CMAKE_CURRENT_SOURCE_DIR}/**
COPYRIGHT.txt)
set(CPACK_PACKAGE_VERSION_**MAJOR 0)
set(CPACK_PACKAGE_VERSION_**MINOR 1)
set(CPACK_CREATE_DESKTOP_LINKS ${PROJECT_NAME})
set(CPACK_PACKAGE_INSTALL_**DIRECTORY ${PROJECT_NAME}) # add the
version numbers
set(CPACK_PACKAGE_DESCRIPTION Package ${PROJECT_NAME})
is there anything missing?
Any idea what that could be?
--
Powered by www.kitware.com
Visit other Kitware open-source projects at http://www.kitware.com/**
opensource/opensource.htmlhttp://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/**CMake_FAQhttp://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/**listinfo/cmakehttp://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] cpack issues
2012/2/21 Andrea Crotti andrea.crott...@gmail.com:
I'm trying to finally create an installer for my project, with CPack and
NSIS.
The project is really really simple, I just need to copy over a directory
somewhere.
And I did something like:
get_filename_component(userprofile $ENV{USERPROFILE} REALPATH)
install(
DIRECTORY ${EGG_BUILD_DIRECTORY}
DESTINATION ${userprofile}/${PROJECT_NAME}
)
Is userprofile an absolute path? (sorry I'm not working on Windows very often)
if this is the case this will not work.
DO NEVER install with absolute install path on Windows:
1) the installed pieces won't be put in the installer
2) the files/dirs/whatever MAY (if you have enough privilege) be
installed on the machine
on which you are trying to build the package!!
I think we should forcibly forbid absolute install path on
windows...but that's another story.
The first line is because CPack was exploding using the USERPROFILE, because
it was getting non quoted backslash.
So is it the way to handle windows path variables?
Usually you go from to native path representation using
file(TO_NATIVE_PATH path result)
file(TO_CMAKE_PATH path result)
see:
cmake --help-command file
The packing, however, doesn't work and I get something like (from the NSIS
generated log file):
!insertmacro: end of MUI_RESERVEFILE_INSTALLOPTIONS
Section: -Core installation
SetOutPath: $INSTDIR
File: Returning to: H:/long_path/_CPack_Packages/win32/NSIS/Minimum
Drag-0.1.1-win32
File: H:/long_path/_CPack_Packages/win32/NSIS/Minimum Drag-0.1.1-win32\*.*
- no files found.
Usage: File [/nonfatal] [/a] ([/r] [/x filespec [...]] filespec [...] |
/oname=outfile one_file_only)
Error in script
H:/git_projs/Minimum_Drag/airbus.application.minimum_drag/_CPack_Packages/win32/NSIS/project.nsi
on line 640 -- aborting creation process
These are the variables that I defined
set(CPACK_NSIS_INSTALLED_ICON_NAME ${PROJECT_NAME})
this one looks wrong:
CPACK_NSIS_INSTALLED_ICON_NAME
A path to the executable that contains the installer icon.
set(CPACK_PACKAGE_ICON Company)
same for this one:
CPACK_PACKAGE_ICON
A branding image that will be displayed inside the installer.
the documentation currently found in CPack.cmake
or http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#NSIS
(and soon from cpack --help-variable)
could be improved but both the previous variables should refer to files.
set(CPACK_NSIS_PACKAGE_NAME ${PROJECT_NAME})
set(CPACK_RESOURCE_FILE_LICENSE ${CMAKE_CURRENT_SOURCE_DIR}/COPYRIGHT.txt)
set(CPACK_PACKAGE_VERSION_MAJOR 0)
set(CPACK_PACKAGE_VERSION_MINOR 1)
set(CPACK_CREATE_DESKTOP_LINKS ${PROJECT_NAME})
I think this one refers to a executable installed by the project.
(but there is not documentation [yet] for CPACK_CREATE_DESKTOP_LINKS :-]
set(CPACK_PACKAGE_INSTALL_DIRECTORY ${PROJECT_NAME}) # add the version
numbers
set(CPACK_PACKAGE_DESCRIPTION Package ${PROJECT_NAME})
there is no such variable.
There is:
CPACK_PACKAGE_DESCRIPTION_SUMMARY
Short description of the project (only a few words).
CPACK_PACKAGE_DESCRIPTION_FILE
A text file used to describe the project.
Used, for example, the introduction screen of a CPack-generated
Windows installer to describe the project.
is there anything missing?
Any idea what that could be?
A lot of things...
first did have a look at the error:
H:/long_path/_CPack_Packages/win32/NSIS/Minimum Drag-0.1.1-win32\*.*
is it true?
then open the project.nsi file and try to fix things by hand.
then go back to your
--
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] Building and executing tests when building updated libraries
Hi, I'm using Visual Studio as my generator for my CMake projects. As of right now, I make my tests depend on the libraries they test. So for example, tests named: test_thingA test_thingB will all depend on library: libfoo.lib When I build target libfoo in visual studio, it would be nice to have all dependent tests build as well, and have them each execute. The goal for all of this is to make it as convenient as possible for developers on my team to RUN TESTS on their code before they submit to version control. I want to make it automated, so when they rebuild the library, the testing automatically happens. I'd also obviously create an option in cmake cache to turn this automation off should it become too annoying. If this isn't a good idea, can someone recommend a good workflow for running tests locally prior to checking in source code? - Robert Dailey -- 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] Building and executing tests when building updated libraries
On Tue, Feb 21, 2012 at 1:27 PM, Robert Dailey rcdai...@gmail.com wrote: Hi, I'm using Visual Studio as my generator for my CMake projects. As of right now, I make my tests depend on the libraries they test. So for example, tests named: test_thingA test_thingB will all depend on library: libfoo.lib When I build target libfoo in visual studio, it would be nice to have all dependent tests build as well, and have them each execute. The goal for all of this is to make it as convenient as possible for developers on my team to RUN TESTS on their code before they submit to version control. I want to make it automated, so when they rebuild the library, the testing automatically happens. I'd also obviously create an option in cmake cache to turn this automation off should it become too annoying. If this isn't a good idea, can someone recommend a good workflow for running tests locally prior to checking in source code? - Robert Dailey -- 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 If you're using add_test in your CMakeLists files, then the perfect way to prove that the tests all work on a developer's machine is for him or her to run: ctest -D Experimental after making local mods, and before pushing the changes to your source control system. That will configure, build all and run all the tests. And submit the results to your CDash server so that is public evidence that he actually did run the tests, and hopefully that they all passed on his machine at least. You can also restrict the set of tests that run using -R or -I or -L on the ctest command line, although, you should strive to have your test suite be brief enough that it's not painful for folks to run the full test suite prior to checkin. 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] Building and executing tests when building updated libraries
On Tue, Feb 21, 2012 at 12:37 PM, David Cole david.c...@kitware.com wrote: On Tue, Feb 21, 2012 at 1:27 PM, Robert Dailey rcdai...@gmail.com wrote: Hi, I'm using Visual Studio as my generator for my CMake projects. As of right now, I make my tests depend on the libraries they test. So for example, tests named: test_thingA test_thingB will all depend on library: libfoo.lib When I build target libfoo in visual studio, it would be nice to have all dependent tests build as well, and have them each execute. The goal for all of this is to make it as convenient as possible for developers on my team to RUN TESTS on their code before they submit to version control. I want to make it automated, so when they rebuild the library, the testing automatically happens. I'd also obviously create an option in cmake cache to turn this automation off should it become too annoying. If this isn't a good idea, can someone recommend a good workflow for running tests locally prior to checking in source code? - Robert Dailey -- 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 If you're using add_test in your CMakeLists files, then the perfect way to prove that the tests all work on a developer's machine is for him or her to run: ctest -D Experimental after making local mods, and before pushing the changes to your source control system. That will configure, build all and run all the tests. And submit the results to your CDash server so that is public evidence that he actually did run the tests, and hopefully that they all passed on his machine at least. You can also restrict the set of tests that run using -R or -I or -L on the ctest command line, although, you should strive to have your test suite be brief enough that it's not painful for folks to run the full test suite prior to checkin. I think this is a reasonable idea for small projects, but in general I disagree with running all tests. There are hundreds of projects (probably 150) and hundreds more of tests (probably 10 tests per project). In general agile methodology, it only makes sense to unit test those components which have changed. Unit testing a dependent component that did not have a source code change will not be needed or beneficial. All of these tests can take hours to run, which isn't unacceptable because it's a full test suite. Only the build server kicks off a build and runs the FULL test suite (thus running ctest -D Experimental as you have suggested). Developers just do an intermediate check by unit testing only the parts of the code base that have changed. This is essential for practices like continuous integration. Ideally the pipeline goes like this: 1. Programmer makes a change to a certain number of libraries 2. Programmer runs the relevant tests (or all) for each of the libraries that were changed. 3. Once those tests have passed, the developer submits the source code to version control 4. The build server is then instructed to run a full build and test of the entire code base for each checkin. 5. The build server can then run any integration tests that are configured (not sure how these would be setup in CMake - probably again as tests, but not specific to only a single project) 6. Build is considered complete at this point. Seems like there would be no choice but to run them individually in this case, since CMake really shines only in steps after #3 -- 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] Building and executing tests when building updated libraries
On Tue, Feb 21, 2012 at 1:51 PM, Robert Dailey rcdai...@gmail.com wrote: On Tue, Feb 21, 2012 at 12:37 PM, David Cole david.c...@kitware.com wrote: On Tue, Feb 21, 2012 at 1:27 PM, Robert Dailey rcdai...@gmail.com wrote: Hi, I'm using Visual Studio as my generator for my CMake projects. As of right now, I make my tests depend on the libraries they test. So for example, tests named: test_thingA test_thingB will all depend on library: libfoo.lib When I build target libfoo in visual studio, it would be nice to have all dependent tests build as well, and have them each execute. The goal for all of this is to make it as convenient as possible for developers on my team to RUN TESTS on their code before they submit to version control. I want to make it automated, so when they rebuild the library, the testing automatically happens. I'd also obviously create an option in cmake cache to turn this automation off should it become too annoying. If this isn't a good idea, can someone recommend a good workflow for running tests locally prior to checking in source code? - Robert Dailey -- 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 If you're using add_test in your CMakeLists files, then the perfect way to prove that the tests all work on a developer's machine is for him or her to run: ctest -D Experimental after making local mods, and before pushing the changes to your source control system. That will configure, build all and run all the tests. And submit the results to your CDash server so that is public evidence that he actually did run the tests, and hopefully that they all passed on his machine at least. You can also restrict the set of tests that run using -R or -I or -L on the ctest command line, although, you should strive to have your test suite be brief enough that it's not painful for folks to run the full test suite prior to checkin. I think this is a reasonable idea for small projects, but in general I disagree with running all tests. There are hundreds of projects (probably 150) and hundreds more of tests (probably 10 tests per project). In general agile methodology, it only makes sense to unit test those components which have changed. Unit testing a dependent component that did not have a source code change will not be needed or beneficial. All of these tests can take hours to run, which isn't unacceptable because it's a full test suite. Only the build server kicks off a build and runs the FULL test suite (thus running ctest -D Experimental as you have suggested). Developers just do an intermediate check by unit testing only the parts of the code base that have changed. This is essential for practices like continuous integration. Ideally the pipeline goes like this: Programmer makes a change to a certain number of libraries Programmer runs the relevant tests (or all) for each of the libraries that were changed. Once those tests have passed, the developer submits the source code to version control The build server is then instructed to run a full build and test of the entire code base for each checkin. The build server can then run any integration tests that are configured (not sure how these would be setup in CMake - probably again as tests, but not specific to only a single project) Build is considered complete at this point. Seems like there would be no choice but to run them individually in this case, since CMake really shines only in steps after #3 Incremental testing is something we've talked about over the years, but there's no concept of what's changed, what needs to run when ctest runs at the moment. Communicating that information from the build to ctest, or making testing always part of the build are the two approaches we've considered. Nothing exists yet, though, so it's all in the future, yet to come. Sorry to hear you disagree about running all the tests. I'll make one more point and then shut up about it: the larger the project, the more you need to run all the tests when changes are made. Unless the developers all have a very good understanding of what parts need to be tested when they make a change, they should run all the tests. If a system is very large, then developers are more likely to have imperfect understandings about the system... when that's the case, if there is any doubt at all about what dependencies exist, then all the tests should be run to verify a change. Until incremental testing is available, I'd say your best bet is to run all the tests. 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
Re: [CMake] Building and executing tests when building updated libraries
On Tue, Feb 21, 2012 at 1:15 PM, David Cole david.c...@kitware.com wrote: On Tue, Feb 21, 2012 at 1:51 PM, Robert Dailey rcdai...@gmail.com wrote: On Tue, Feb 21, 2012 at 12:37 PM, David Cole david.c...@kitware.com wrote: On Tue, Feb 21, 2012 at 1:27 PM, Robert Dailey rcdai...@gmail.com wrote: Hi, I'm using Visual Studio as my generator for my CMake projects. As of right now, I make my tests depend on the libraries they test. So for example, tests named: test_thingA test_thingB will all depend on library: libfoo.lib When I build target libfoo in visual studio, it would be nice to have all dependent tests build as well, and have them each execute. The goal for all of this is to make it as convenient as possible for developers on my team to RUN TESTS on their code before they submit to version control. I want to make it automated, so when they rebuild the library, the testing automatically happens. I'd also obviously create an option in cmake cache to turn this automation off should it become too annoying. If this isn't a good idea, can someone recommend a good workflow for running tests locally prior to checking in source code? - Robert Dailey -- 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 If you're using add_test in your CMakeLists files, then the perfect way to prove that the tests all work on a developer's machine is for him or her to run: ctest -D Experimental after making local mods, and before pushing the changes to your source control system. That will configure, build all and run all the tests. And submit the results to your CDash server so that is public evidence that he actually did run the tests, and hopefully that they all passed on his machine at least. You can also restrict the set of tests that run using -R or -I or -L on the ctest command line, although, you should strive to have your test suite be brief enough that it's not painful for folks to run the full test suite prior to checkin. I think this is a reasonable idea for small projects, but in general I disagree with running all tests. There are hundreds of projects (probably 150) and hundreds more of tests (probably 10 tests per project). In general agile methodology, it only makes sense to unit test those components which have changed. Unit testing a dependent component that did not have a source code change will not be needed or beneficial. All of these tests can take hours to run, which isn't unacceptable because it's a full test suite. Only the build server kicks off a build and runs the FULL test suite (thus running ctest -D Experimental as you have suggested). Developers just do an intermediate check by unit testing only the parts of the code base that have changed. This is essential for practices like continuous integration. Ideally the pipeline goes like this: Programmer makes a change to a certain number of libraries Programmer runs the relevant tests (or all) for each of the libraries that were changed. Once those tests have passed, the developer submits the source code to version control The build server is then instructed to run a full build and test of the entire code base for each checkin. The build server can then run any integration tests that are configured (not sure how these would be setup in CMake - probably again as tests, but not specific to only a single project) Build is considered complete at this point. Seems like there would be no choice but to run them individually in this case, since CMake really shines only in steps after #3 Incremental testing is something we've talked about over the years, but there's no concept of what's changed, what needs to run when ctest runs at the moment. Communicating that information from the build to ctest, or making testing always part of the build are the two approaches we've considered. Nothing exists yet, though, so it's all in the future, yet to come. Sorry to hear you disagree about running all the tests. I'll make one more point and then shut up about it: the larger the project, the more you need to run all the tests when changes are made. Unless the developers all have a very good understanding of what parts need to be tested when they make a change, they should run all the tests. If a system is very large, then developers are more likely to have imperfect understandings about the system... when that's the case, if there is any doubt at all about what dependencies exist, then all the tests should be run to verify a change. Until incremental testing is available, I'd say your
Re: [CMake] Building and executing tests when building updated libraries
An possible alternative could be to associate one or more labels to your tests, then you should be able to run a specific subset of the test suite. See http://www.cmake.org/cmake/help/ctest-2-8-docs.html#opt:-Lregex--label-regexregex and http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:LABELS Hth Jc On Tue, Feb 21, 2012 at 2:51 PM, Robert Dailey rcdai...@gmail.com wrote: On Tue, Feb 21, 2012 at 1:15 PM, David Cole david.c...@kitware.comwrote: On Tue, Feb 21, 2012 at 1:51 PM, Robert Dailey rcdai...@gmail.com wrote: On Tue, Feb 21, 2012 at 12:37 PM, David Cole david.c...@kitware.com wrote: On Tue, Feb 21, 2012 at 1:27 PM, Robert Dailey rcdai...@gmail.com wrote: Hi, I'm using Visual Studio as my generator for my CMake projects. As of right now, I make my tests depend on the libraries they test. So for example, tests named: test_thingA test_thingB will all depend on library: libfoo.lib When I build target libfoo in visual studio, it would be nice to have all dependent tests build as well, and have them each execute. The goal for all of this is to make it as convenient as possible for developers on my team to RUN TESTS on their code before they submit to version control. I want to make it automated, so when they rebuild the library, the testing automatically happens. I'd also obviously create an option in cmake cache to turn this automation off should it become too annoying. If this isn't a good idea, can someone recommend a good workflow for running tests locally prior to checking in source code? - Robert Dailey -- 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 If you're using add_test in your CMakeLists files, then the perfect way to prove that the tests all work on a developer's machine is for him or her to run: ctest -D Experimental after making local mods, and before pushing the changes to your source control system. That will configure, build all and run all the tests. And submit the results to your CDash server so that is public evidence that he actually did run the tests, and hopefully that they all passed on his machine at least. You can also restrict the set of tests that run using -R or -I or -L on the ctest command line, although, you should strive to have your test suite be brief enough that it's not painful for folks to run the full test suite prior to checkin. I think this is a reasonable idea for small projects, but in general I disagree with running all tests. There are hundreds of projects (probably 150) and hundreds more of tests (probably 10 tests per project). In general agile methodology, it only makes sense to unit test those components which have changed. Unit testing a dependent component that did not have a source code change will not be needed or beneficial. All of these tests can take hours to run, which isn't unacceptable because it's a full test suite. Only the build server kicks off a build and runs the FULL test suite (thus running ctest -D Experimental as you have suggested). Developers just do an intermediate check by unit testing only the parts of the code base that have changed. This is essential for practices like continuous integration. Ideally the pipeline goes like this: Programmer makes a change to a certain number of libraries Programmer runs the relevant tests (or all) for each of the libraries that were changed. Once those tests have passed, the developer submits the source code to version control The build server is then instructed to run a full build and test of the entire code base for each checkin. The build server can then run any integration tests that are configured (not sure how these would be setup in CMake - probably again as tests, but not specific to only a single project) Build is considered complete at this point. Seems like there would be no choice but to run them individually in this case, since CMake really shines only in steps after #3 Incremental testing is something we've talked about over the years, but there's no concept of what's changed, what needs to run when ctest runs at the moment. Communicating that information from the build to ctest, or making testing always part of the build are the two approaches we've considered. Nothing exists yet, though, so it's all in the future, yet to come. Sorry to hear you disagree about running all the tests. I'll make one more point and then shut up about it: the larger the project, the more you need to run all the tests when changes are made. Unless the developers all have a very good understanding of
Re: [CMake] Building and executing tests when building updated libraries
2012/2/21 Robert Dailey rcdai...@gmail.com: I apologize if I sounded like your suggestion wasn't meaningful or useful. I would much rather prefer to do it how you suggest (running all tests), but this leaves me with some concerns: If the developer is running all unit tests on their local machine, what is the purpose of then running them on the server? If the server does it again in response to the commit, wouldn't that be considered redundant? The server may catch interaction between modifications that make some tests fails when features are merged but not when tested alone. This would depend on you VCS as well. With a centralized VCS like (CVS, Subversion etc...) this would be odd if this happened. With DVCS with some non-conflicting merge workflow (think of the 'next' CMake branch) then server may reveal errors that developers cannot catch. Moreover in portable project like those I know using CMake the server may in fact be serversssZZ which may have very different setup than the one the developper is running on. (I do break MacOS X or Windows whatever version compile when I develop on my Linux box). The server breakage may reveal that the project is lacking some test which would have ease the unitary catch. Do you have 100% coverage with your tests? Let's assume that the time it takes to run all tests takes about 1 hour. Not only does this slow down productivity, but it also makes practices like continuous integration impossible to perform, since a lot of people can commit work in that 1 hour window, in which case you'd have to run the tests again after updating. It's a recursive issue. If the whole test is lengthly may be the tested project is beginning to be too big to be tested as a whole. Imagine the test suite a for a whole operating system... Then the project may be subdivided into smaller independent projects, that can be tested independently safely in a shorter time. Then you create some integration project (and put someone responsible for it) which essentially consist integration tests which aggregate use the smaller projects. This integration test suite may be run extensively before each combo release and/or periodically like once a week. How would you address the concerns I have noted above? My 2 cents just above. Plus ask some people with a huge number of tests like OTB: http://dash.orfeo-toolbox.org/index.php?project=OTBdate=2012-02-21 Totals 5 Builds ... 10464 tests :-] I bet they don't run the whole test suite each time they commit. My tests are labeled in such a way that they are easy to spot and work with in the solution explorer. For example: projectA projectA_test_iostreams projectA_test_fileio projectA_test_graphics projectA_test_input Then you have a neat way to run ctest efficiently on those using ctest -L (or ctest -R if your are speaking of test names and not label). By the way would someone explain me (or point me to appropriate place) on test label usage, are those derived from labels that could be put on target or may I put label on test as well (I know I can try, but sometimes I like to read as well). In my example above, target named projectA has 4 unit tests. Each test can be responsible for 1 or more translation units (there is no strict rule here). If I change the way files are loaded by library projectA, then I would run the fileio test. However, in this case it's really easy for the developer to spot the tests for that project and run all of them if they are unsure. Would you also mind commenting on this structure? It seems to ease the concern you mentioned about people not always being able to know which tests to run. Thanks for your feedback. Keep in mind that not only am I covering general testing principles, but I also want to know how to best apply them to the tools (CMake, CTest). This is where your expertise becomes valuable to me :) -- 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] cpack issues
On 02/21/2012 06:25 PM, Eric Noulard wrote:
2012/2/21 Andrea Crottiandrea.crott...@gmail.com:
I'm trying to finally create an installer for my project, with CPack and
NSIS.
The project is really really simple, I just need to copy over a directory
somewhere.
And I did something like:
get_filename_component(userprofile $ENV{USERPROFILE} REALPATH)
install(
DIRECTORY ${EGG_BUILD_DIRECTORY}
DESTINATION ${userprofile}/${PROJECT_NAME}
)
Is userprofile an absolute path? (sorry I'm not working on Windows very often)
if this is the case this will not work.
DO NEVER install with absolute install path on Windows:
1) the installed pieces won't be put in the installer
2) the files/dirs/whatever MAY (if you have enough privilege) be
installed on the machine
on which you are trying to build the package!!
I think we should forcibly forbid absolute install path on
windows...but that's another story.
I see, well I just wanted to get something running quickly to see if the
packaging actually works.
Anyway my assumption was that $ENV{USERPROFILE} would be the userprofile
directory on the machine
where I will run the installer, but I understand now why this is a very
stupid assumption.
With the relative path I got an actual installer in the end, but I get
another error when I try to run it
that I will investigate further tomorrow..
Thanks a lot for now.
--
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] Common Properties in Visual Studio
Actually, a correction: Looks like the VS_DOTNET_REFERENCES target property is in CMake 2.8.7 already. $ cmake --help-property VS_DOTNET_REFERENCES cmake version 2.8.7 VS_DOTNET_REFERENCES Visual Studio managed project .NET references Adds one or more semicolon-delimited .NET references to a generated Visual Studio project. For example, System;System.Windows.Forms. It's the other commit that will first appear in 2.8.8... On Tue, Feb 21, 2012 at 5:57 PM, David Cole david.c...@kitware.com wrote: It's not completely out of scope, but it's not exactly aligned with your typical cross-platform project either. So let's say it's low on the priority list. However, there are some new CMake properties in the 'next' and 'master' branches that will appear in the upcoming CMake 2.8.8 release. See, for example, these recent commits: http://public.kitware.com/gitweb?p=cmake.git;a=commitdiff;h=9e01aefd24cd23878bd88c2f3cae62b5e28802b0 http://public.kitware.com/gitweb?p=cmake.git;a=commitdiff;h=a1f976ce0e62baf513c8726c59aba5f75a0335c6 I think the VS_DOTNET_REFERENCES target property may be exactly what you're asking for here. (It will be available in CMake 2.8.8 and later.) HTH, David On Tue, Feb 21, 2012 at 5:35 PM, Anders Backman ande...@cs.umu.se wrote: No plans on adding more thorough support for .NET projects or is that out of the scope for CMake? /A On Tue, Feb 21, 2012 at 11:57 AM, aaron.mead...@thomsonreuters.com wrote: I’m pretty sure that CMake does not directly support .NET projects. Here, we handle the csharp projects in visual studio and then use the include_external_msproject stuff to pull them in. In our case, we had to apply a patch to get it working correctly. (see: http://www.cmake.org/Bug/print_bug_page.php?bug_id=9742 ) We used the patch titled: 0001-ms-external-project-.NET-project-support-GUID-fixed.patch Aaron Meadows From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Anders Backman Sent: Tuesday, February 21, 2012 9:55 AM To: cmake Subject: [CMake] Common Properties in Visual Studio Hi all. I was wondering if someone ever have used CMake to configure a .NET project, where one need to add References in: Common Properties - Framework and References I need to locate some .dll-files from a .NET API and add those as references to a project to be able to build against it. I haven't found any relevant info on the web nor in the CMake documentation. Have anyone succeeded in doing this? Or is it outside the scope of CMake? Cheers and thanks for a great tool. /A -- This email was sent to you by Thomson Reuters, the global news and information company. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Thomson Reuters. -- 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 command and differences between VS2005 and VS2010
Hi Aaron,
thank you very much für your analysis. we are currently using cmake, ver
2.8.2.
the effect disappears with cmake 2.8.7. so we have to go for an upgrade.
/thanks again and best regardsWalter
Von:aaron.mead...@thomsonreuters.com
An: walter.schw...@dzbank.de, cmake@cmake.org
Datum: 21.02.2012 14:48
Betreff:RE: [CMake] custom command and differences between VS2005
and VS2010
I tried this out with VS 2010 SP0 Win64. Here?s my CMakeLists:
cmake_minimum_required(VERSION 2.8)
project(Test CXX)
file(WRITE foo.h //Some Foo Header )
file(WRITE foo.cpp int main(int argc, char** argv) { return 0; }\n)
file(WRITE foo.txt This is the foo text file (simulated config))
set( etc_hdrs foo.h)
set( etc_srcs foo.cpp foo.txt)
add_custom_target( etc SOURCES ${etc_hdrs} ${etc_srcs} )
For me, the resulting VS Solution has the text file as a member of the
project:
[IMAGE]
Also ended up with an item named ?etc?, which seems wrong.. not sure why
that would have happened. I?m using CMake 2.8.7 on Windows 7. I wonder
if there is something else that is a problem. What version of CMake are
you using?
Aaron Meadows
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf
Of walter.schw...@dzbank.de
Sent: Monday, February 20, 2012 5:37 AM
To: cmake@cmake.org
Subject: [CMake] custom command and differences between VS2005 and VS2010
our project contains a directory with config files. to make the config
files (and other externally supplied header files) visible in the visual
studio solution, the custom command shown below was specified in the
directory.
this worked well with the generator for Visual Studio 2005. it doesn't any
more with the generator for visual studio 2010.
- is this intentional or is it a bug?
- what can i do to fix this?
/regards Walter Schwarz
# Targets: none - placeholder for Murex headers
#
# Library: none
#
set( etc_hdrs
${FLEX_INCLUDE_DIRS}/mdtypes.h
... list shortened ...
)
set( etc_srcs FlexModelConfig.cfg configFile.txt )
include_directories(
${FLEX_INCLUDE_DIRS}
)
add_custom_target( etc SOURCES ${etc_hdrs} ${etc_srcs} )
This email was sent to you by Thomson Reuters, the global news and
information company. Any views expressed in this message are those of the
individual sender, except where the sender specifically states them to be
the views of Thomson Reuters.[attachment image001.png deleted by Walter
Schwarz/CT/Frankfurt/DZ BANK]
--
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-2751-g82c3726
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 82c3726537c24183459270355db507a638ee07e1 (commit)
via df19b9cadb5caca0f77ee87b8e28181e61c0658e (commit)
from a9dd6f0248572cc14896970b2a6d45a504a9333c (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=82c3726537c24183459270355db507a638ee07e1
commit 82c3726537c24183459270355db507a638ee07e1
Merge: a9dd6f0 df19b9c
Author: David Cole david.c...@kitware.com
AuthorDate: Tue Feb 21 11:31:34 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Feb 21 11:31:34 2012 -0500
Merge topic 'fix-12189-support-SBCS-in-VS' into next
df19b9c VS6: Avoid _MBCS define when _SBCS is defined (#12189)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=df19b9cadb5caca0f77ee87b8e28181e61c0658e
commit df19b9cadb5caca0f77ee87b8e28181e61c0658e
Author: David Cole david.c...@kitware.com
AuthorDate: Tue Feb 21 11:29:06 2012 -0500
Commit: David Cole david.c...@kitware.com
CommitDate: Tue Feb 21 11:29:06 2012 -0500
VS6: Avoid _MBCS define when _SBCS is defined (#12189)
Should fix the failing SBCS test on the VS6 dashboard.
diff --git a/Source/cmLocalVisualStudio6Generator.cxx
b/Source/cmLocalVisualStudio6Generator.cxx
index 1dfcbea..fe5d48d 100644
--- a/Source/cmLocalVisualStudio6Generator.cxx
+++ b/Source/cmLocalVisualStudio6Generator.cxx
@@ -1605,11 +1605,13 @@ void cmLocalVisualStudio6Generator
flagsDebugRel = this-Makefile-GetSafeDefinition(flagVar.c_str());
flagsDebugRel += -DCMAKE_INTDIR=\\\RelWithDebInfo\\\ ;
}
-
-// if unicode is not found, then add -D_MBCS
+
+// if _UNICODE and _SBCS are not found, then add -D_MBCS
std::string defs = this-Makefile-GetDefineFlags();
if(flags.find(D_UNICODE) == flags.npos
- defs.find(D_UNICODE) == flags.npos)
+ defs.find(D_UNICODE) == flags.npos
+ flags.find(D_SBCS) == flags.npos
+ defs.find(D_SBCS) == flags.npos)
{
flags += /D \_MBCS\;
}
---
Summary of changes:
Source/cmLocalVisualStudio6Generator.cxx |8 +---
1 files changed, 5 insertions(+), 3 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-2756-g63152d0
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 63152d002f40c9426845246aef04636ce416e72c (commit)
via 35c48e12706f9426eda43b3b077925a2fab0df44 (commit)
via 61cb4ea72e608370b581bae9d9810ca6ae8f84d0 (commit)
via c9f2886b3db9783eaa455c21288eabdc7e6366a1 (commit)
via 628f36514070037dd3dc4f09c61c4df8688e3a2b (commit)
from 82c3726537c24183459270355db507a638ee07e1 (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=63152d002f40c9426845246aef04636ce416e72c
commit 63152d002f40c9426845246aef04636ce416e72c
Merge: 82c3726 35c48e1
Author: Brad King brad.k...@kitware.com
AuthorDate: Tue Feb 21 15:45:33 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Feb 21 15:45:33 2012 -0500
Merge topic 'HandleTargetsInCMakeRequiredLibraries' into next
35c48e1 Check*.cmake: Expand imported targets in CMAKE_REQUIRED_LIBRARIES
61cb4ea bootstrap: move while() and endwhile() into the bootstrap build
c9f2886 -don't pull in CheckTypeSize.cmake from the cmake which is being
built
628f365 -remove trailing whitespace
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=35c48e12706f9426eda43b3b077925a2fab0df44
commit 35c48e12706f9426eda43b3b077925a2fab0df44
Author: Alex Neundorf neund...@kde.org
AuthorDate: Thu Feb 16 23:35:43 2012 +0100
Commit: Brad King brad.k...@kitware.com
CommitDate: Tue Feb 21 15:38:15 2012 -0500
Check*.cmake: Expand imported targets in CMAKE_REQUIRED_LIBRARIES
Add the function cmake_expand_imported_targets() to expand imported
targets in a list of libraries into their on-disk file names for a
particular configuration. Adapt the implementation from KDE's
HANDLE_IMPORTED_TARGETS_IN_CMAKE_REQUIRED_LIBRARIES which has been in
use for over 2 years. Call the function from all the Check*.cmake
macros to handle imported targets named in CMAKE_REQUIRED_LIBRARIES.
Alex
diff --git a/Modules/CMakeExpandImportedTargets.cmake
b/Modules/CMakeExpandImportedTargets.cmake
new file mode 100644
index 000..fba071a
--- /dev/null
+++ b/Modules/CMakeExpandImportedTargets.cmake
@@ -0,0 +1,129 @@
+# CMAKE_EXPAND_IMPORTED_TARGETS(var LIBRARIES lib1 lib2...libN
+# [CONFIGURATION config] )
+#
+# CMAKE_EXPAND_IMPORTED_TARGETS() takes a list of libraries and replaces
+# all imported targets contained in this list with their actual file paths
+# of the referenced libraries on disk, including the libraries from their
+# link interfaces.
+# If a CONFIGURATION is given, it uses the respective configuration of the
+# imported targets if it exists. If no CONFIGURATION is given, it uses
+# the first configuration from ${CMAKE_CONFIGURATION_TYPES} if set, otherwise
+# ${CMAKE_BUILD_TYPE}.
+# This macro is used by all Check*.cmake files which use
+# TRY_COMPILE() or TRY_RUN() and support CMAKE_REQUIRED_LIBRARIES , so that
+# these checks support imported targets in CMAKE_REQUIRED_LIBRARIES:
+#cmake_expand_imported_targets(expandedLibs LIBRARIES
${CMAKE_REQUIRED_LIBRARIES}
+# CONFIGURATION
${CMAKE_TRY_COMPILE_CONFIGURATION} )
+
+
+#=
+# Copyright 2012 Kitware, Inc.
+# Copyright 2009-2012 Alexander Neundorf neund...@kde.org
+#
+# 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 distribute this file outside of CMake, substitute the full
+# License text for the above reference.)
+
+include(CMakeParseArguments)
+
+function(CMAKE_EXPAND_IMPORTED_TARGETS _RESULT )
+
+ set(options )
+ set(oneValueArgs CONFIGURATION )
+ set(multiValueArgs LIBRARIES )
+
+ cmake_parse_arguments(CEIT ${options} ${oneValueArgs}
${multiValueArgs} ${ARGN})
+
+ if(CEIT_UNPARSED_ARGUMENTS)
+ message(FATAL_ERROR Unknown keywords given to
CMAKE_EXPAND_IMPORTED_TARGETS(): \${CEIT_UNPARSED_ARGUMENTS}\)
+ endif()
+
+ if(NOT CEIT_CONFIGURATION)
+ if(CMAKE_CONFIGURATION_TYPES)
+ list(GET CMAKE_CONFIGURATION_TYPES 0 CEIT_CONFIGURATION)
+ else()
+ set(CEIT_CONFIGURATION ${CMAKE_BUILD_TYPE})
+ endif()
+ endif()
+
+ # handle imported library targets
+
+ set(_CCSR_REQ_LIBS ${CEIT_LIBRARIES})
+
+
[Cmake-commits] CMake branch, next, updated. v2.8.7-2762-gae376fb
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 ae376fb0a499baf6e758ebfd1b71104069da700f (commit)
via 810edef9d66bee2001d01ad34de90059f2f5d160 (commit)
via 1f581c860dded4bcdc0a7dffa9f7e2d3ec25ac68 (commit)
via 0793a28b1aa5d332eecfb90242ee5db8d032031c (commit)
via fffdbc1b871805ab617fd3de475477672ce5a4fa (commit)
via cffebe643c9002ee3411c8f293abdf7c23fc622c (commit)
from 63152d002f40c9426845246aef04636ce416e72c (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=ae376fb0a499baf6e758ebfd1b71104069da700f
commit ae376fb0a499baf6e758ebfd1b71104069da700f
Merge: 63152d0 810edef
Author: Rolf Eike Beer e...@sf-mail.de
AuthorDate: Tue Feb 21 15:46:25 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Feb 21 15:46:25 2012 -0500
Merge topic 'improve-findpythonlibs' into next
810edef FindPythonLibs: put debug libraries into PYTHON_LIBRARIES
1f581c8 FindPythonLibs: get the exact version of the found library (#3080)
0793a28 FindPythonLibs: make the version selection work as for PythonInterp
fffdbc1 FindPython{Interp,Libs}: document Python_ADDITIONAL_VERSIONS as
input
cffebe6 KWSys Nightly Date Stamp
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=810edef9d66bee2001d01ad34de90059f2f5d160
commit 810edef9d66bee2001d01ad34de90059f2f5d160
Author: Rolf Eike Beer e...@sf-mail.de
AuthorDate: Tue Feb 21 21:40:02 2012 +0100
Commit: Rolf Eike Beer e...@sf-mail.de
CommitDate: Tue Feb 21 21:44:47 2012 +0100
FindPythonLibs: put debug libraries into PYTHON_LIBRARIES
diff --git a/Modules/FindPythonLibs.cmake b/Modules/FindPythonLibs.cmake
index 9401dbb..6360d53 100644
--- a/Modules/FindPythonLibs.cmake
+++ b/Modules/FindPythonLibs.cmake
@@ -7,7 +7,7 @@
# PYTHON_LIBRARIES - path to the python library
# PYTHON_INCLUDE_PATH- path to where Python.h is found (deprecated)
# PYTHON_INCLUDE_DIRS- path to where Python.h is found
-# PYTHON_DEBUG_LIBRARIES - path to the debug library
+# PYTHON_DEBUG_LIBRARIES - path to the debug library (deprecated)
# PYTHONLIBS_VERSION_STRING - version of the Python libs found (since CMake
2.8.8)
#
# The Python_ADDITIONAL_VERSIONS variable can be used to specify a list of
@@ -148,9 +148,14 @@ MARK_AS_ADVANCED(
# library. We now set the variables listed by the documentation for this
# module.
SET(PYTHON_INCLUDE_DIRS ${PYTHON_INCLUDE_DIR})
-SET(PYTHON_LIBRARIES ${PYTHON_LIBRARY})
SET(PYTHON_DEBUG_LIBRARIES ${PYTHON_DEBUG_LIBRARY})
+# These variables have been historically named in this module different from
+# what SELECT_LIBRARY_CONFIGURATIONS() expects.
+SET(PYTHON_LIBRARY_DEBUG ${PYTHON_DEBUG_LIBRARY})
+SET(PYTHON_LIBRARY_RELEASE ${PYTHON_LIBRARY})
+INCLUDE(${CMAKE_CURRENT_LIST_DIR}/SelectLibraryConfigurations.cmake)
+SELECT_LIBRARY_CONFIGURATIONS(PYTHON)
INCLUDE(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake)
FIND_PACKAGE_HANDLE_STANDARD_ARGS(PythonLibs
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1f581c860dded4bcdc0a7dffa9f7e2d3ec25ac68
commit 1f581c860dded4bcdc0a7dffa9f7e2d3ec25ac68
Author: Rolf Eike Beer e...@sf-mail.de
AuthorDate: Tue Feb 21 21:12:16 2012 +0100
Commit: Rolf Eike Beer e...@sf-mail.de
CommitDate: Tue Feb 21 21:44:41 2012 +0100
FindPythonLibs: get the exact version of the found library (#3080)
diff --git a/Modules/FindPythonLibs.cmake b/Modules/FindPythonLibs.cmake
index 8ba2d39..9401dbb 100644
--- a/Modules/FindPythonLibs.cmake
+++ b/Modules/FindPythonLibs.cmake
@@ -8,6 +8,7 @@
# PYTHON_INCLUDE_PATH- path to where Python.h is found (deprecated)
# PYTHON_INCLUDE_DIRS- path to where Python.h is found
# PYTHON_DEBUG_LIBRARIES - path to the debug library
+# PYTHONLIBS_VERSION_STRING - version of the Python libs found (since CMake
2.8.8)
#
# The Python_ADDITIONAL_VERSIONS variable can be used to specify a list of
# version numbers that should be taken into account when searching for Python.
@@ -126,6 +127,14 @@ FOREACH(_CURRENT_VERSION ${_Python_VERSIONS})
SET(PYTHON_INCLUDE_PATH ${PYTHON_INCLUDE_DIR} CACHE INTERNAL
Path to where Python.h is found (deprecated))
+ IF(PYTHON_INCLUDE_DIR AND EXISTS ${PYTHON_INCLUDE_DIR}/patchlevel.h)
+FILE(STRINGS ${PYTHON_INCLUDE_DIR}/patchlevel.h python_version_str
+ REGEX ^#define[ \t]+PY_VERSION[ \t]+\[^\]+\)
+STRING(REGEX REPLACE ^#define[ \t]+PY_VERSION[ \t]+\([^\]+)\.* \\1
+ PYTHONLIBS_VERSION_STRING ${python_version_str})
+UNSET(python_version_str)
+
[Cmake-commits] CMake branch, master, updated. v2.8.7-386-ge1a6c9b
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 e1a6c9b9a1affb846d997fcf19dc90dbc79b60c1 (commit) via afc75bb7f520b7405a08f24a25a42542d3e3c92f (commit) from 27431d2886ea0062fa0a024d4472dd20e8a23ea1 (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=e1a6c9b9a1affb846d997fcf19dc90dbc79b60c1 commit e1a6c9b9a1affb846d997fcf19dc90dbc79b60c1 Merge: 27431d2 afc75bb Author: David Cole david.c...@kitware.com AuthorDate: Tue Feb 21 15:53:41 2012 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Feb 21 15:53:41 2012 -0500 Merge topic 'link-OpenBSD-shared-libs-issue-12954' afc75bb Recognize OpenBSD versioned .so names (#12954) --- Summary of changes: Source/cmComputeLinkInformation.cxx | 14 +- Source/cmComputeLinkInformation.h |1 + 2 files changed, 14 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.7-388-gd84233a
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 d84233a70dea19b5188700c63c2b1164c97cf8fe (commit) via 10dfec3bb63a8f6552c1d343b6cad245e6b1abdf (commit) from e1a6c9b9a1affb846d997fcf19dc90dbc79b60c1 (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=d84233a70dea19b5188700c63c2b1164c97cf8fe commit d84233a70dea19b5188700c63c2b1164c97cf8fe Merge: e1a6c9b 10dfec3 Author: David Cole david.c...@kitware.com AuthorDate: Tue Feb 21 15:53:50 2012 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Feb 21 15:53:50 2012 -0500 Merge topic 'findperllibs-windows' 10dfec3 FindPerlLibs: properly detect libperl on Windows (#12224) --- Summary of changes: Modules/FindPerlLibs.cmake | 54 ++- 1 files changed, 23 insertions(+), 31 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-394-ge17f270
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 e17f270b7acdfc5e6cfd3179a9f48da53a258996 (commit) via 14dadbde809d5091de44ef880376f69f6be2e23e (commit) from cee42a73e8809ffb0bd877a121d0c042530f8018 (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=e17f270b7acdfc5e6cfd3179a9f48da53a258996 commit e17f270b7acdfc5e6cfd3179a9f48da53a258996 Merge: cee42a7 14dadbd Author: David Cole david.c...@kitware.com AuthorDate: Tue Feb 21 15:54:19 2012 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Feb 21 15:54:19 2012 -0500 Merge topic 'improve-findglut' 14dadbd FindGLUT: honor REQUIRED (#12466) --- Summary of changes: Modules/FindGLUT.cmake | 34 -- 1 files changed, 16 insertions(+), 18 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-406-g7023f61
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 7023f610d4aab3f37197e829a3ba07bc4c30a502 (commit) via 854e76237ce3e8f03d9cabcad1f8f37e04992ad3 (commit) from d39acfa10585e0e671ff6bb7109a4a1f8d917f2a (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=7023f610d4aab3f37197e829a3ba07bc4c30a502 commit 7023f610d4aab3f37197e829a3ba07bc4c30a502 Merge: d39acfa 854e762 Author: David Cole david.c...@kitware.com AuthorDate: Tue Feb 21 15:55:26 2012 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Feb 21 15:55:26 2012 -0500 Merge topic 'improve-findruby' 854e762 FindRuby: clean up querying variables from Ruby --- Summary of changes: Modules/FindRuby.cmake | 57 +-- 1 files changed, 26 insertions(+), 31 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-408-g40d2da0
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 40d2da09c5d2b8659119da31b2f3d43acef3df6b (commit) via 70697a85a0bd273c0b1773471b7ae11b2c7ceb57 (commit) from 7023f610d4aab3f37197e829a3ba07bc4c30a502 (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=40d2da09c5d2b8659119da31b2f3d43acef3df6b commit 40d2da09c5d2b8659119da31b2f3d43acef3df6b Merge: 7023f61 70697a8 Author: David Cole david.c...@kitware.com AuthorDate: Tue Feb 21 15:55:34 2012 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Feb 21 15:55:34 2012 -0500 Merge topic 'improve-findlibxslt' 70697a8 FindLibXslt: support version selection --- Summary of changes: Modules/FindLibXslt.cmake | 18 +++--- 1 files changed, 15 insertions(+), 3 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-410-gae61602
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 ae616023855d4e3772faa424fbf9970143a66b63 (commit) via 378f2291593c5b1d7d9fcd03029b931ce674a3d2 (commit) from 40d2da09c5d2b8659119da31b2f3d43acef3df6b (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=ae616023855d4e3772faa424fbf9970143a66b63 commit ae616023855d4e3772faa424fbf9970143a66b63 Merge: 40d2da0 378f229 Author: David Cole david.c...@kitware.com AuthorDate: Tue Feb 21 15:55:50 2012 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Feb 21 15:55:50 2012 -0500 Merge topic 'document-test-layout' 378f229 Tests: document where to put tests --- Summary of changes: Tests/README | 34 ++ 1 files changed, 34 insertions(+), 0 deletions(-) create mode 100644 Tests/README 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-426-g6c6c266
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 6c6c2664394d9542cf611b7941c0f45cffd1e108 (commit) via 54e1f6f5a572e47c5598fd53e3b9eb0a66739def (commit) from 09c16ca4883db2fff9b3138e348db6bd0560c4cb (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=6c6c2664394d9542cf611b7941c0f45cffd1e108 commit 6c6c2664394d9542cf611b7941c0f45cffd1e108 Merge: 09c16ca 54e1f6f Author: David Cole david.c...@kitware.com AuthorDate: Tue Feb 21 15:57:02 2012 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Feb 21 15:57:02 2012 -0500 Merge topic 'GenerateExportHeader_MinorFix' 54e1f6f GenerateExportHeader: use double quotes around _gcc_version --- Summary of changes: Modules/GenerateExportHeader.cmake |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.7-436-g7d02020
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 7d02020d682018a541b10460b28d6a8d0ef9bcf3 (commit) via 9a8103e929de7569fd2e5459a6676dff64d88892 (commit) via 4da2223ab768e44b7ef6e789ab193ea54c9b5e27 (commit) via cfac874b7783a5c464334bfc13d969a667f1c397 (commit) via dee0a38648195786bae0abce437ef4617ea0912e (commit) via b4abcfecbe281373fd3c28adccf4c3002b7909c4 (commit) via 9717727d5fa29a993b22b9437e67cc28d8eaf52c (commit) via 7a8f44a2d6d23ec0345a1413f3a79c21f9566456 (commit) via b8a274c091b63e6203b61f5aee40393d1409c9fc (commit) via a6bce55aefd332f148a2753d5be0ec4383534473 (commit) from 6c6c2664394d9542cf611b7941c0f45cffd1e108 (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=7d02020d682018a541b10460b28d6a8d0ef9bcf3 commit 7d02020d682018a541b10460b28d6a8d0ef9bcf3 Merge: 6c6c266 9a8103e Author: David Cole david.c...@kitware.com AuthorDate: Tue Feb 21 15:57:17 2012 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Feb 21 15:57:17 2012 -0500 Merge topic 'CPack-dynamicDocSection' 9a8103e Try to fix compile error on Win32-vs70 4da2223 Fix typo in end markup cfac874 More documentation concerning CPack Components dee0a38 Put CPack DMG and PackageMaker doc in separate files b4abcfe Correct copy/paste section name mistake 9717727 Suppress unecessary (now empty) doc sections 7a8f44a Add structure documentation for CPack Bundle generator b8a274c Add structured documentation for NSIS a6bce55 Dynamically add documentation section specified in documented script. --- Summary of changes: Modules/CPack.cmake | 55 -- Modules/CPackBundle.cmake | 12 +++ Modules/CPackComponent.cmake| 47 +- Modules/CPackDMG.cmake | 70 +++ Modules/CPackDeb.cmake |2 +- Modules/CPackNSIS.cmake | 42 +++ Modules/CPackPackageMaker.cmake | 34 +++ Modules/CPackRPM.cmake |2 +- Source/CPack/cpack.cxx |3 +- Source/cmDocumentation.cxx | 24 ++--- Source/cmDocumentation.h|6 ++- 11 files changed, 230 insertions(+), 67 deletions(-) create mode 100644 Modules/CPackDMG.cmake create mode 100644 Modules/CPackPackageMaker.cmake 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-443-gbf65600
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 bf6560091d2d3cc2c57852d414580643036a1974 (commit) via f5066217db3911754006ae64e2a9001382ff66e1 (commit) from 0c00c179380ea5c6d8507249329551b1c63ac91b (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=bf6560091d2d3cc2c57852d414580643036a1974 commit bf6560091d2d3cc2c57852d414580643036a1974 Merge: 0c00c17 f506621 Author: David Cole david.c...@kitware.com AuthorDate: Tue Feb 21 15:58:06 2012 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Feb 21 15:58:06 2012 -0500 Merge topic 'qt3-find-qtmain' f506621 Fix paths/hints for finding qtmain. --- Summary of changes: Modules/FindQt3.cmake |5 - 1 files changed, 4 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.7-448-g8ef15df
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 8ef15df7000bc514b941f04784bccb340f9638b4 (commit) via 35c48e12706f9426eda43b3b077925a2fab0df44 (commit) via 61cb4ea72e608370b581bae9d9810ca6ae8f84d0 (commit) via c9f2886b3db9783eaa455c21288eabdc7e6366a1 (commit) via 628f36514070037dd3dc4f09c61c4df8688e3a2b (commit) from bf6560091d2d3cc2c57852d414580643036a1974 (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=8ef15df7000bc514b941f04784bccb340f9638b4 commit 8ef15df7000bc514b941f04784bccb340f9638b4 Merge: bf65600 35c48e1 Author: David Cole david.c...@kitware.com AuthorDate: Tue Feb 21 15:58:27 2012 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Feb 21 15:58:27 2012 -0500 Merge topic 'HandleTargetsInCMakeRequiredLibraries' 35c48e1 Check*.cmake: Expand imported targets in CMAKE_REQUIRED_LIBRARIES 61cb4ea bootstrap: move while() and endwhile() into the bootstrap build c9f2886 -don't pull in CheckTypeSize.cmake from the cmake which is being built 628f365 -remove trailing whitespace --- Summary of changes: Modules/CMakeExpandImportedTargets.cmake | 129 Modules/CheckCSourceCompiles.cmake |7 ++- Modules/CheckCSourceRuns.cmake | 13 ++- Modules/CheckCXXSourceCompiles.cmake |7 ++- Modules/CheckCXXSourceRuns.cmake | 17 +++-- Modules/CheckFortranFunctionExists.cmake | 11 ++- Modules/CheckFunctionExists.cmake | 13 ++- Modules/CheckLibraryExists.cmake | 17 +++-- Modules/CheckPrototypeDefinition.cmake |7 ++- Modules/CheckSymbolExists.cmake|7 ++- Modules/CheckTypeSize.cmake|7 ++- Modules/CheckVariableExists.cmake | 15 ++- Source/cmBootstrapCommands.cxx |8 ++- Source/cmCommands.cxx |4 - Source/cmWhileCommand.cxx | 18 ++-- Tests/ExportImport/Import/A/CMakeLists.txt | 11 +++ Utilities/cmcurl/CMakeLists.txt| 33 +++ 17 files changed, 257 insertions(+), 67 deletions(-) create mode 100644 Modules/CMakeExpandImportedTargets.cmake 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-2791-g7815a15
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 7815a1531d8dc1c290ed120955eb2f83270b3e99 (commit) via 40efa4db7462312ab9b2c82e601acba0ab67ca19 (commit) from d8b6fca02b789d2d6da6df5fba901074b5b75e02 (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=7815a1531d8dc1c290ed120955eb2f83270b3e99 commit 7815a1531d8dc1c290ed120955eb2f83270b3e99 Merge: d8b6fca 40efa4d Author: Stephen Kelly steve...@gmail.com AuthorDate: Tue Feb 21 17:57:08 2012 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Feb 21 17:57:08 2012 -0500 Merge topic 'fix-generate_export_header-docs' into next 40efa4d Fix documented function signature to match reality. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=40efa4db7462312ab9b2c82e601acba0ab67ca19 commit 40efa4db7462312ab9b2c82e601acba0ab67ca19 Author: Stephen Kelly steve...@gmail.com AuthorDate: Tue Feb 21 23:54:01 2012 +0100 Commit: Stephen Kelly steve...@gmail.com CommitDate: Tue Feb 21 23:54:01 2012 +0100 Fix documented function signature to match reality. The function description is already correct. diff --git a/Modules/GenerateExportHeader.cmake b/Modules/GenerateExportHeader.cmake index f3f61f6..0d9a3b8 100644 --- a/Modules/GenerateExportHeader.cmake +++ b/Modules/GenerateExportHeader.cmake @@ -18,7 +18,7 @@ # [PREFIX_NAME prefix_name] # ) # -# ADD_COMPILER_EXPORT_FLAGS( [FATAL_WARNINGS] ) +# ADD_COMPILER_EXPORT_FLAGS( [output_variable] ) # # By default GENERATE_EXPORT_HEADER() generates macro names in a file name # determined by the name of the library. The ADD_COMPILER_EXPORT_FLAGS function --- Summary of changes: Modules/GenerateExportHeader.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
