Re: [cmake-developers] What about #line like feature in cmake language?
On Thu, May 22, 2014 at 3:16 PM, Brad King brad.k...@kitware.com wrote: One remaining challenge is CMAKE_CURRENT_LIST_FILE and CMAKE_CURRENT_LIST_LINE. Since the current file is not handled by the lexer these may not be consistent unless some kind of refactoring is done in the language implementation. However, it is not clear whether CMAKE_CURRENT_LIST_FILE can safely refer back to some transformed location because sometimes code uses it to look next to the file being processed to locate other files. If some source location mapping is in place then that may not be well-defined. I think we should not touch those variables because they have dynamic behavior and if they are used in the generated code I expect the current behavior. Why not adding __FILE__ and __LINE__ tokens that would be expanded by the lexer with the file name and line number last set by #cmake-source-line? -- Nicolas Desprès -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0014929]: Dependencies of custom targets are built as part of Build Solution in Visual Studio
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=14929 == Reported By:Lars Christensen Assigned To: == Project:CMake Issue ID: 14929 Category: CMake Reproducibility:always Severity: minor Priority: low Status: new == Date Submitted: 2014-05-23 06:44 EDT Last Modified: 2014-05-23 06:44 EDT == Summary:Dependencies of custom targets are built as part of Build Solution in Visual Studio Description: If a CMakeLists.txt has two add_custom_target()'s where one is a dependency of the other, the dependency gets built every time you Build Solution in Visual Studio. add_custom_target(foo DEPENDS main COMMAND cmd /c echo foo MESSAGE foo) add_custom_target(bar DEPENDS foo COMMAND cmd /c echo bar MESSAGE bar) In this case, the 'foo' target is selected for as a project to build every time in the Visual Studio 'Configuration Manager'. 'bar' is NOT selected to build every time, and is only build if built explicitly. If 'bar' is removed from CMakeLists.txt, 'foo' is no longer built every time, and is deselected from Build in the 'Configuration Manager'. Neither 'foo' nor 'bar' is marked as a dependency of ALL_BUILD (As expected). The problems is in the 'Configuration Manager', which selected which projects are build when you choose 'Build Solution'. == Issue History Date ModifiedUsername FieldChange == 2014-05-23 06:44 Lars ChristensenNew Issue == -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0014930]: CMake FindQt4.cmake missing some modules
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14930 == Reported By:Mathieu MARACHE Assigned To: == Project:CMake Issue ID: 14930 Category: Modules Reproducibility:always Severity: major Priority: high Status: new == Date Submitted: 2014-05-23 08:38 EDT Last Modified: 2014-05-23 08:38 EDT == Summary:CMake FindQt4.cmake missing some modules Description: Trying to deploy a Qt4 Application on Mac/Windows/Linux are missing some bearer (platform dependent) and the qtga plugin. I can override defaults in my Applications CMakeLists.txt by setting the lists used like this : set( QT_BEARER_PLUGINS qcorewlanbearer qgenericbearer qnativewifibearer qconnmanbearer qnmbearer) set( QT_IMAGEFORMATS_PLUGINS qgif qjpeg qmng qico qsvg qtiff qtga ) but it would be better to make them correct by default == Issue History Date ModifiedUsername FieldChange == 2014-05-23 08:38 Mathieu MARACHENew Issue 2014-05-23 08:38 Mathieu MARACHEFile Added: MissingQt4Plugins.patch == -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [ANNOUNCE] CMake 3.0-rc6 now ready for testing!
I am proud to announce the CMake 3.0 sixth and hopefully last release candidate. Sources and binaries are available at: http://www.cmake.org/files/v3.0/?C=M;O=D Documentation is available at: http://www.cmake.org/cmake/help/v3.0 Release notes appear below and are also published at http://www.cmake.org/cmake/help/v3.0/release/3.0.0.html Some of the more significant features of CMake 3.0 are: * Compatibility options supporting code written for CMake versions prior to 2.4 have been removed. * The CMake language has been extended with *Bracket Argument* and *Bracket Comment* syntax inspired by Lua long brackets. * The CMake documentation has been converted to reStructuredText and uses Sphinx generation. * Generators for Visual Studio 10 (2010) and later were renamed to include the product year like generators for older VS versions: * Visual Studio 10 - Visual Studio 10 2010 * Visual Studio 11 - Visual Studio 11 2012 * Visual Studio 12 - Visual Studio 12 2013 This clarifies which generator goes with each Visual Studio version. The old names are recognized for compatibility. * A new CodeLite extra generator is available for use with the Makefile or Ninja generators. * A new Kate extra generator is available for use with the Makefile or Ninja generators. * The add_library() command learned a new INTERFACE library type. Interface libraries have no build rules but may have properties defining usage requirements and may be installed, exported, and imported. This is useful to create header-only libraries that have concrete link dependencies on other libraries. * The export() command learned a new EXPORT mode that retrieves the list of targets to export from an export set configured by the install(TARGETS) command EXPORT option. This makes it easy to export from the build tree the same targets that are exported from the install tree. * The project() command learned to set some version variables to values specified by the new VERSION option or to empty strings. See policy CMP0048. * Several long-outdated commands that should no longer be called have been disallowed in new code by policies: * Policy CMP0029 disallows subdir_depends() * Policy CMP0030 disallows use_mangled_mesa() * Policy CMP0031 disallows load_command() * Policy CMP0032 disallows output_required_files() * Policy CMP0033 disallows export_library_dependencies() * Policy CMP0034 disallows utility_source() * Policy CMP0035 disallows variable_requires() * Policy CMP0036 disallows build_name() --- Changes made since CMake 3.0.0-rc5: Brad King (3): CMP0022: Fix link language propagation in NEW behavior KWSys SystemTools: Port cygwin path conversion to modern API KWSys Process: Workaround child kill trouble on Cygwin Eric Berge (1): cmSystemTools::RenameFile: Retry on Windows ERROR_SHARING_VIOLATION James Bigler (1): FindCUDA: Use CUDA_NVCC_FLAGS* for separable compilation -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] What about #line like feature in cmake language?
On 05/23/2014 03:39 AM, Nicolas Desprès wrote: One remaining challenge is CMAKE_CURRENT_LIST_FILE and CMAKE_CURRENT_LIST_LINE. Since the current file is not [snip] I think we should not touch those variables because they have dynamic behavior and if they are used in the generated code I expect the current behavior. CMAKE_CURRENT_LIST_LINE comes from the lexer currently. I think CMAKE_CURRENT_LIST_FILE could too, and I'm not sure why it does not currently. That would take some investigation in the history to learn. Why not adding __FILE__ and __LINE__ tokens that would be expanded by the lexer with the file name and line number last set by #cmake-source-line? That is what the above variables were meant to be. They just happen to be implemented by replacing during variable evaluation instead of by the lexer. Having the lexer do actual replacements would be a change to the language beyond the scope of the #line proposal. I think this issue as a reason to not add a #line feature. For your generated source case you can add comments that refer back to the original source locations for human reference. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] FindFreetype Patch
On 05/22/2014 02:58 PM, Taylor Holberton wrote:
This patch adds windows and unix search paths that Freetype normally installs
to.
Thanks for working on this. The patch appears to make style
and code layout changes at the same time as functional changes.
Please split that up into separate patches. Clean up style
first, then make functional changes.
The proposed paths:
+if (WIN32)
+ set (FREETYPE_PATHS ${FREETYPE_PATHS} $ENV{PROGRAMFILES}/freetype)
+ set (FREETYPE_PATHS ${FREETYPE_PATHS} $ENV{PROGRAMFILES}/freetype2)
+else()
+ set (FREETYPE_PATHS ${FREETYPE_PATHS} /usr)
+ set (FREETYPE_PATHS ${FREETYPE_PATHS} /usr/local)
+endif()
should not be necessary.
See CMAKE_SYSTEM_PREFIX_PATH settings on unix and windows:
http://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/Platform/UnixPaths.cmake;hb=v3.0.0-rc6#l32
http://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/Platform/WindowsPaths.cmake;hb=v3.0.0-rc6#l32
and how the find commands use it:
http://www.cmake.org/cmake/help/v3.0/command/find_library.html
http://www.cmake.org/cmake/help/v3.0/command/find_path.html
With proper PATH_SUFFIXES I do not think the above guesses
should be needed.
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] FindFreetype Maintenance
On Fri, May 23, 2014 at 12:56 AM, Greg Jung gvj...@gmail.com wrote:
Somehow $ENV{CFLAGS} impossibly translates the first group but fails to go
beyond that first blank.
The *only* program that translates paths in MinGW is the MSYS shell.
When it passes command line arguments and environment variables to
programs not located inside one of its soft mounts, it tries to
convert paths to pure windows paths. In your example the value of
CFLAGS has been changed by the shell before CMake even runs.
For example, try:
$ CFLAGS='-I/usr/local/include -I/usr/include' cmd //c echo %CFLAGS%
-IC:/MinGW/msys/1.0/local/include -I/usr/include
Certainly cmd and echo are not doing that conversion.
Including /usr and /usr/local in the .cmake file's search would solve the
unix problem.
They shouldn't be needed explicitly in the module at all. See my
response to Taylor's first patch.
It doesn't make sense to me to chase every different freetype install
location.
Agreed. The current module's guesses need to be preserved for compatibility
(if they are not otherwise searched already), but should not be used as an
example of how to do it.
It does make sense to reform
the original kludge, which finds ft2build.h (should be easy) then goes after
config/ftheader.h; ft2build simply
includes (???)/config/ftheader.h in whatever the way it would show.
A simple search for freetype as a library, then verifying the affiliated
include directory for ft2build.h,
should replace the gymnastics there now.
Searching for ft2build.h is correct because that is the header that
applications are expected to include directly. The rest of the
search is an attempt to locate the real headers so the version
can be extracted, AFAICT.
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] What about #line like feature in cmake language?
On Fri, May 23, 2014 at 3:11 PM, Brad King brad.k...@kitware.com wrote: That is what the above variables were meant to be. They just happen to be implemented by replacing during variable evaluation instead of by the lexer. Having the lexer do actual replacements would be a change to the language beyond the scope of the #line proposal. I see... I think this issue as a reason to not add a #line feature. For your generated source case you can add comments that refer back to the original source locations for human reference. Indeed it is not a strong requirement at your suggestion will work too. I will think more about it and get back to you if I have another idea. Thanks for your time, -- Nicolas Desprès -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [PATCH] Proposed HPUX Build Fix
Compilation of cmake failed on HPUX (master as well as v2.8.12.2), at least on my HPUX systems (uname info: B.11.31 U ia64 1105973567). I did not write the supplied patch but found it online at: http://vouters.dyndns.org/tima/HP-UX-IA64-MySQL-Building_and_Installing_MySQL_on_HP-UX.html but it appeared to fix the problem, so I'm submitting this for consideration. Presummably HPUX has this fcntl but not quite the same set of structures that support it as Tru64 even though they are part of the same company. Odd. Thanks, Eric 0001-HPUX-compilation-fix.patch Description: Binary data -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] Proposed HPUX Build Fix
Eric Berge wrote: Compilation of cmake failed on HPUX (master as well as v2.8.12.2), at least on my HPUX systems (uname info: B.11.31 U ia64 1105973567). At least next is fine, and every patch master has been in next. So which commit on master are you testing with? Eike -- signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] Proposed HPUX Build Fix
On 05/23/2014 02:22 PM, Eric Berge wrote: Compilation of cmake failed on HPUX (master as well as v2.8.12.2), at least on my HPUX systems (uname info: B.11.31 U ia64 1105973567). I did not write the supplied patch but found it online at: http://vouters.dyndns.org/tima/HP-UX-IA64-MySQL-Building_and_Installing_MySQL_on_HP-UX.html but it appeared to fix the problem, so I'm submitting this for consideration. Presummably HPUX has this fcntl but not quite the same set of structures that support it as Tru64 even though they are part of the same company. Odd. There is an issue tracker entry for this. See here: http://www.cmake.org/Bug/view.php?id=14386#c33863 The real problem is that we have no one running nightly testing for HP-UX B.11.31 (only 11.11-hppa and 11.23-ia64, IIRC). Would you be able to run one? Instructions are here: http://www.cmake.org/Wiki/CMake/Git/Dashboard -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0014932]: Cannot set library linker flags for each configuration individually
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=14932 == Reported By:Saad Assigned To: == Project:CMake Issue ID: 14932 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2014-05-23 16:55 EDT Last Modified: 2014-05-23 16:55 EDT == Summary:Cannot set library linker flags for each configuration individually Description: Issue is related to: 0012295(http://www.cmake.org/Bug/view.php?id=12295) We already have CMAKE_EXE_LINKER_FLAGS_RELEASE for specifying executable linker flags (as well as MODULE and SHARED) but no variable for STATIC libraries. STATIC_LIBRARY_FLAGS does not work because it sets the flag(s) for all configurations. A variable such as CMAKE_STATIC_LINKER_FLAGS_RELEASE (and CMAKE_STATIC_LINKER_FLAGS_DEBUG etc.) that sets the flags for the VC++ librarian would be ideal. == Issue History Date ModifiedUsername FieldChange == 2014-05-23 16:55 Saad New Issue == -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
