[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
