[cmake-developers] Question regarding [58e3d49] MSVC: Fix encoding of Visual Studio 10+ project files
Hi, I have a question regarding the change [58e3d49] that changed the encoding of generated visual studio project files from utf-8 to Windows-1252. Although the encoding header in the generated xml file was changed the files are still written as utf. Visual Studio does not complain about that fact. However If I try to parse the xml file with some other xml parsers they will complain about that encoding mismatch. What was the reason to change the encoding from utf-8 to Windows-1252? Dominik -- 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 0014788]: [patch] Several fixes for Haiku support.
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=14788 == Reported By:Adrien Destugues Assigned To: == Project:CMake Issue ID: 14788 Category: (No Category) Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2014-03-06 07:22 EST Last Modified: 2014-03-06 07:22 EST == Summary:[patch] Several fixes for Haiku support. Description: The Haiku operating system has been maintaining custom patches to CMake for a while now. It would be simpler for us if those were merged. Here is a patch against CMake 3.0.0-rc1: http://bb.haikuports.org/haikuports/raw/7b0678877260253c3b9ed567c4b35e80116308a4/dev-util/cmake/patches/cmake-3.0.0_rc1.patchset This includes: - Support slightly different naming and features of the elf.h header on Haiku, to enable use of the rpath tricks - Detection of command line length limit - Support for our native HPKG package file format - Some fixes to the Platform/Haiku.cmake to make it more solid, in particular when using distcc or ccache - Changes to some modules (SDL libraries, freetype) to not force the include directory to be named include (for us, it's headers). - The last patch in the patchset (CPU frequency detection) was already applied to KWSys. == Issue History Date ModifiedUsername FieldChange == 2014-03-06 07:22 Adrien DestuguesNew Issue 2014-03-06 07:22 Adrien DestuguesFile Added: cmake-3.0.0_rc1.patchset == -- 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 0014789]: FILE(GLOB variable RELATIVE path globbing_expression) fails when the underlying path contains special character
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=14789
==
Reported By:Ashok Kumar P
Assigned To:
==
Project:CMake
Issue ID: 14789
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2014-03-06 18:19 IST
Last Modified: 2014-03-06 18:19 IST
==
Summary:FILE(GLOB variable RELATIVE path
globbing_expression) fails when the underlying path contains special character
Description:
FILE(GLOB variable RELATIVE path globbing_expression) fails to generate the list
of files when the path contains [some_text].
Steps to Reproduce:
List files in a directory whose path contains '[some_text]'
-- FILE(GLOB lstFiles RELATIVE ${dirPath} ${dirPath}/*)
or
-- FILE(GLOB lstFiles RELATIVE ${dirPath} ${dirPath}/*)
Additional Information:
Escaping '[' and ']' in CMAKE returned PATHs should prevent this, I haven't
tested it.
==
Issue History
Date ModifiedUsername FieldChange
==
2014-03-06 18:19 Ashok Kumar P 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] Exported targets with imported dependencies in CMake 3.0
Hi, one thing that has bothered me in earlier CMake versions is how targets with imported dependencies are exported. Consider this contrived case: add_library(yaml SHARED IMPORTED) set_target_properties(yaml PROPERTIES IMPORTED_LOCATION /usr/lib/libyaml.so) set_target_properties(yaml PROPERTIES INTERFACE_INCLUDE_DIRECTORIES /usr/include) add_library(main SHARED main.cpp) target_link_libraries(main yaml) export(TARGETS main FILE myproj-exports.cmake) The generated export file is going to contain this: # Create imported target main add_library(main SHARED IMPORTED) # Import target main for configuration set_property(TARGET main APPEND PROPERTY IMPORTED_CONFIGURATIONS NOCONFIG) set_target_properties(main PROPERTIES IMPORTED_LINK_INTERFACE_LIBRARIES_NOCONFIG yaml IMPORTED_LOCATION_NOCONFIG /tmp/cmake/build/libmain.so IMPORTED_SONAME_NOCONFIG libmain.so ) The problem I see is that, to make this work for a consumer of the imported target to have a yaml target as well. Unfortunately, I cannot export yaml, because it isn't being build by this tree. Of course, I can just require users to fix the dependency themselves, but sometimes I would like to specify things like INTERFACE_COMPILE_DEFINITIONS on an imported target that I need to propagate. It would be great, if I could export imported targets and if CMake could walk the dependency tree automatically and import those targets on an as-needed basis. Am I missing anything here that already allows me to do this or is this a worthwhile feature to add? Cheers, Philipp -- 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 0014790]: CMake crashes with XCode generator
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14790 == Reported By:Jan Rüegg Assigned To: == Project:CMake Issue ID: 14790 Category: CMake Reproducibility:always Severity: crash Priority: normal Status: new == Date Submitted: 2014-03-06 08:52 EST Last Modified: 2014-03-06 08:52 EST == Summary:CMake crashes with XCode generator Description: The following commit makes cmake segfault on our project: 93fc5a53a... Xcode: Fix storyboard view Version 2.8.12 (before this commit) works fine when running cmake. Version 2.8.12.2 (after this commit) segfaults... Steps to Reproduce: Unfortunately I cannot reproduce it with a simple project, there everything works fine. Running it through gdb I get the following output: -- Configuring done -- Generating done Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0030 0x7fff8a45da26 in std::string::c_str () (gdb) bt http://public.kitware.com/Bug/view.php?id=0 0x7fff8a45da26 in std::string::c_str () http://public.kitware.com/Bug/view.php?id=1 0x00010036c7dc in cmXCodeObject::GetString () http://public.kitware.com/Bug/view.php?id=2 0x0001003583ab in cmGlobalXCodeGenerator::CreateXCodeTargets () http://public.kitware.com/Bug/view.php?id=3 0x0001003697da in cmGlobalXCodeGenerator::CreateXCodeObjects () http://public.kitware.com/Bug/view.php?id=4 0x000100354ae3 in cmGlobalXCodeGenerator::OutputXCodeProject () http://public.kitware.com/Bug/view.php?id=5 0x00010035378f in cmGlobalXCodeGenerator::Generate () http://public.kitware.com/Bug/view.php?id=6 0x00010032f305 in cmake::Generate () http://public.kitware.com/Bug/view.php?id=7 0x00010032cd52 in cmake::Run () http://public.kitware.com/Bug/view.php?id=8 0x00013c0d in do_cmake () http://public.kitware.com/Bug/view.php?id=9 0x000122e3 in main () So it looks to be really related to the commit, that changes something in cmGlobalXCodeGenerator.cxx == Issue History Date ModifiedUsername FieldChange == 2014-03-06 08:52 Jan Rüegg 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] Exported targets with imported dependencies in CMake 3.0
Philipp Möller wrote: It would be great, if I could export imported targets and if CMake could walk the dependency tree automatically and import those targets on an as-needed basis. Part of the problem is that the place where you import your dependent targets from (and the locations calculated) are not necessarily the same for your downstreams. You export your targets to and -exports file, and presumably you import that in a -config file. In the same config file, you should add code to find your dependencies too. http://www.cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html#creating-packages The find_dependency macro can help with forwarding some find_package arguments. http://www.cmake.org/cmake/help/v3.0/module/CMakeFindDependencyMacro.html 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] Exported targets with imported dependencies in CMake 3.0
.. and whenever possible the FindXXX.cmake should defined imported targets. Jc On Thu, Mar 6, 2014 at 9:38 AM, Philipp Möller bootsare...@gmail.comwrote: Stephen Kelly steve...@gmail.com writes: Philipp Möller wrote: It would be great, if I could export imported targets and if CMake could walk the dependency tree automatically and import those targets on an as-needed basis. Part of the problem is that the place where you import your dependent targets from (and the locations calculated) are not necessarily the same for your downstreams. I understand the issue and have been fighting it in versions prior 3.0 as well. It also arises if you simply export targets that have been target_link_librarie'd against full library paths returned by a find_package. That's why I thought some build-in functionality could be helpful for this, e.g. exporting and imported target would lead to a definition in the exports file that automatically triggers a corresponding find_package call. You export your targets to and -exports file, and presumably you import that in a -config file. In the same config file, you should add code to find your dependencies too. http://www.cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html#creating-packages The find_dependency macro can help with forwarding some find_package arguments. http://www.cmake.org/cmake/help/v3.0/module/CMakeFindDependencyMacro.html The documentation is a little sparse, but I think I understand the purpose. I still need to traverse IMPORTED_LINK_INTERFACE_LIBRARIES and figure out which of the list members constitutes a target that needs to trigger a find_dependency and what a full library path is, correct? I can also not rely on a find_package call to actually produce imported targets and need to ship the code that turns the results of find_package in targets. Thanks for your help, Philipp -- 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 -- +1 919 869 8849 -- 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] Who does CMake contract work?
Kitware has been offering CMake consulting since we created CMake. Information can be found here: http://cmake.org/cmake/help/support.html Vince, I also sent you an email off list. This looks like a great addition to CMake, and we would love to help. Thanks. -Bill On 3/5/2014 7:21 PM, Vince Harron wrote: Hi all, Are there any companies/individuals out there that have a history of contributions to CMake that would be interested in adding Android.mk generator and an NSight Tegra (Visual Studio plugin) generator? Details: Modify CMake to be able to generate Android.mk files usable by ndk-build Prove correct operation by building all LiquidFun targets using Android.mk files generated by CMake. Modify open source CMake to be able to generate NSight Tegra project files. Prove correct operation by building all LiquidFun targets using NSight Tegra files generated by CMake. Submit a patch to LiquidFun with working CMake files. (with copyright assignment) LiquidFun - http://google-opensource.blogspot.com/2013/12/liquidfun-rigid-body-physics-library.html (High probability of ongoing work as we port more CMake based open source projects to Android) Thanks, Vince -- Vince Harron | Technical Lead Manager | vhar...@google.com mailto:vhar...@google.com | 858-442-0868 -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoff...@kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 -- 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] Exported targets with imported dependencies in CMake 3.0
Jean-Christophe Fillion-Robin jchris.filli...@kitware.com writes: .. and whenever possible the FindXXX.cmake should defined imported targets. This has been another big problem I encountered while trying to fully targetify my build system: find_package files just aren't up to speed yet. I was thinking about making this a separate post, but I can bring this up here as well. It might be possible to have some general find_targets() which essentially wraps a find_package() call and produce imported targets. This could work for most of the general cases, but some libraries need special-casing (Boost comes to mind, where thread has to depend on system and as of a special version chrono, unless boost-cmake is used, which virtually no distribution does). On Thu, Mar 6, 2014 at 9:38 AM, Philipp Möller bootsare...@gmail.comwrote: Stephen Kelly steve...@gmail.com writes: Philipp Möller wrote: It would be great, if I could export imported targets and if CMake could walk the dependency tree automatically and import those targets on an as-needed basis. Part of the problem is that the place where you import your dependent targets from (and the locations calculated) are not necessarily the same for your downstreams. I understand the issue and have been fighting it in versions prior 3.0 as well. It also arises if you simply export targets that have been target_link_librarie'd against full library paths returned by a find_package. That's why I thought some build-in functionality could be helpful for this, e.g. exporting and imported target would lead to a definition in the exports file that automatically triggers a corresponding find_package call. You export your targets to and -exports file, and presumably you import that in a -config file. In the same config file, you should add code to find your dependencies too. http://www.cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html#creating-packages The find_dependency macro can help with forwarding some find_package arguments. http://www.cmake.org/cmake/help/v3.0/module/CMakeFindDependencyMacro.html The documentation is a little sparse, but I think I understand the purpose. I still need to traverse IMPORTED_LINK_INTERFACE_LIBRARIES and figure out which of the list members constitutes a target that needs to trigger a find_dependency and what a full library path is, correct? I can also not rely on a find_package call to actually produce imported targets and need to ship the code that turns the results of find_package in targets. Thanks for your help, Philipp -- 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 -- 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 0014791]: Allow link directories to be set per target
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=14791
==
Reported By:Philipp Möller
Assigned To:
==
Project:CMake
Issue ID: 14791
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2014-03-06 10:21 EST
Last Modified: 2014-03-06 10:21 EST
==
Summary:Allow link directories to be set per target
Description:
Currently it is not possible to specify the directories in which libraries for
linking are to be searched on a per target basis. This is a standard flag in
most compilers.
Usually specifying the directory in which libraries are searched for is not
necessary as CMake convention is to use full paths for libraries. Unfortunately,
specifying the directory **only** (and not the actual libraries) is necessary to
get the Visual Studio auto-linking feature to work which is used by several C++
libraries (Boost, CGAL).
A common thing for VS users is to do:
find_package(Boost COMPONENTS system) # checks omitted
add_executable(main main.cpp) # executable using Boost.system
link_directories(${Boost_LIBRARY_DIRS}) # global sucks, enable this per target
# set includes and so on
==
Issue History
Date ModifiedUsername FieldChange
==
2014-03-06 10:21 Philipp Möller 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] Exported targets with imported dependencies in CMake 3.0
Philipp Möller wrote:
Stephen Kelly steve...@gmail.com writes:
Philipp Möller wrote:
It would be great, if I could export imported targets and if CMake could
walk the dependency tree automatically and import those targets on an
as-needed basis.
Part of the problem is that the place where you import your dependent
targets from (and the locations calculated) are not necessarily the same
for your downstreams.
I understand the issue and have been fighting it in versions prior 3.0
as well. It also arises if you simply export targets that have been
target_link_librarie'd against full library paths returned by a
find_package.
Yes, exactly. That's the problem with having paths in
INTERFACE_LINK_LIBRARIES, and a good reason not to do that.
That's why I thought some build-in functionality could be helpful for
this, e.g. exporting and imported target would lead to a definition in
the exports file that automatically triggers a corresponding
find_package call.
Seems overly-complex to implement.
You export your targets to and -exports file, and presumably you import
that in a -config file. In the same config file, you should add code to
find your dependencies too.
http://www.cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html#creating-packages
The find_dependency macro can help with forwarding some find_package
arguments.
http://www.cmake.org/cmake/help/v3.0/module/CMakeFindDependencyMacro.html
The documentation is a little sparse, but I think I understand the
purpose.
The code is easy to read, if that helps. However, it's not designed for your
complex case (it deliberately doesn't wrap all arguments of find_package),
so you may have to do something similar to it on your own.
I still need to traverse IMPORTED_LINK_INTERFACE_LIBRARIES and
figure out which of the list members constitutes a target that needs to
trigger a find_dependency and what a full library path is, correct?
No, I don't think so. You shouldn't introspect
IMPORTED_LINK_INTERFACE_LIBRARIES like that.
Simply issue a find_dependency call and ensure that the package can be
found. That probably means writing (and shipping with your config file) a
Find-module for your dependency which creates the needed imported targets.
I can also not rely on a find_package call to actually produce imported
targets and need to ship the code that turns the results of find_package
in targets.
You can actually. You just need to write and ship such a Find-module
yourself (until the necessary imported targets are provided by the Find-
module itself).
Create a wrapper around the relevant Find-module and add the imported
targets.
Something like:
# FindFoo.cmake
find_package(Foo PATH ${CMAKE_ROOT}/Modules NO_DEFAULT_PATH)
add_library(Foo::Lib SHARED IMPORTED)
# ...
and in the config file:
find_package(Foo ${maybe_other_args}
PATH ${CMAKE_CURRENT_LIST_DIR} NO_DEFAULT_PATH)
If you are going to write proper IMPORTED targets for cmake-shipped Find-
modules, I'd recommend contributing them to cmake instead anyway.
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] Exported targets with imported dependencies in CMake 3.0
Stephen Kelly steve...@gmail.com writes:
Philipp Möller wrote:
Stephen Kelly steve...@gmail.com writes:
Philipp Möller wrote:
It would be great, if I could export imported targets and if CMake could
walk the dependency tree automatically and import those targets on an
as-needed basis.
Part of the problem is that the place where you import your dependent
targets from (and the locations calculated) are not necessarily the same
for your downstreams.
I understand the issue and have been fighting it in versions prior 3.0
as well. It also arises if you simply export targets that have been
target_link_librarie'd against full library paths returned by a
find_package.
Yes, exactly. That's the problem with having paths in
INTERFACE_LINK_LIBRARIES, and a good reason not to do that.
That's why I thought some build-in functionality could be helpful for
this, e.g. exporting and imported target would lead to a definition in
the exports file that automatically triggers a corresponding
find_package call.
Seems overly-complex to implement.
You export your targets to and -exports file, and presumably you import
that in a -config file. In the same config file, you should add code to
find your dependencies too.
http://www.cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html#creating-packages
The find_dependency macro can help with forwarding some find_package
arguments.
http://www.cmake.org/cmake/help/v3.0/module/CMakeFindDependencyMacro.html
The documentation is a little sparse, but I think I understand the
purpose.
The code is easy to read, if that helps. However, it's not designed for your
complex case (it deliberately doesn't wrap all arguments of find_package),
so you may have to do something similar to it on your own.
I still need to traverse IMPORTED_LINK_INTERFACE_LIBRARIES and
figure out which of the list members constitutes a target that needs to
trigger a find_dependency and what a full library path is, correct?
No, I don't think so. You shouldn't introspect
IMPORTED_LINK_INTERFACE_LIBRARIES like that.
Simply issue a find_dependency call and ensure that the package can be
found. That probably means writing (and shipping with your config file) a
Find-module for your dependency which creates the needed imported
targets.
Some of my dependencies are chosen at configuration time, so I need to
specify somehow if a target has been build with a public dependency
enabled.
e.g. I have mylib1 and mylib2, mylib1 depends on mylib2 and optionally
on External::stuff. The classic way would be to write a variable
mylib_external_depends and go through that to trigger the appropriate
find_packages. I thought I could save myself the duplication and just
use the interface libraries instead, but you are probably right.
I can also not rely on a find_package call to actually produce imported
targets and need to ship the code that turns the results of find_package
in targets.
You can actually. You just need to write and ship such a Find-module
yourself (until the necessary imported targets are provided by the Find-
module itself).
Create a wrapper around the relevant Find-module and add the imported
targets.
Something like:
# FindFoo.cmake
find_package(Foo PATH ${CMAKE_ROOT}/Modules NO_DEFAULT_PATH)
add_library(Foo::Lib SHARED IMPORTED)
# ...
and in the config file:
find_package(Foo ${maybe_other_args}
PATH ${CMAKE_CURRENT_LIST_DIR} NO_DEFAULT_PATH)
If you are going to write proper IMPORTED targets for cmake-shipped Find-
modules, I'd recommend contributing them to cmake instead anyway.
I'll see what I can do.
--
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] Question regarding [58e3d49] MSVC: Fix encoding of Visual Studio 10+ project files
On Thursday, March 06, 2014 11:09:24 AM Dominik Bernhardt wrote: Hi, I have a question regarding the change [58e3d49] that changed the encoding of generated visual studio project files from utf-8 to Windows-1252. Although the encoding header in the generated xml file was changed the files are still written as utf. Visual Studio does not complain about that fact. However If I try to parse the xml file with some other xml parsers they will complain about that encoding mismatch. What was the reason to change the encoding from utf-8 to Windows-1252? Dominik Hi, CMake's internal encoding on Windows is currently ANSI, not UTF-8. So the generated xml file should actually be ANSI, even if the xml header used to say UTF-8. I do realize that setting the encoding to Windows-1252 encoding is not entirely correct, even for ANSI, but it was an improvement. Previously, only the 7-bit ASCII subset of strings were allowed to be written out by CMake to the xml file with a utf-8 header, and still have a valid xml file. With that commit, a the larger 8-bit Latin-1 set of characters can be written out and still have a valid xml file, which helps the Western European languages, but still not other parts of the world. The other parts of the world should still have the same limitation as before, when the header said it was a UTF-8 file. There has been work going into CMake to support a UTF-8 encoding on Windows, but it is not complete. - 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
Re: [cmake-developers] [Review request] Topic FindPkgConfig_Extend-PKG_CONFIG_PATH
On 03/05/2014 07:47 PM, Daniele E. Domenichelli wrote: I noticed that the CMAKE_FRAMEWORK_PATH and CMAKE_APPBUNDLE_PATH don't have documentation Just leave them as inline-literals for now if there is no doc to link. They can be added later. Am I supposed to add documentation for the variable PKG_CONFIG_USE_CMAKE_PREFIX_PATH, that is checked by this patch? It looks like you've updated the docs further to use the variable directive. Good. Do you mind flipping the order of the patches to revise the documentation formatting first and then make the functional change? That will make it easier to see the actual change. Also it looks like some logic is taken from GNUInstallDirs. Is there enough in common to try to factor that out into a helper module? I just noticed that there is already a global property FIND_LIBRARY_USE_LIB64_PATHS. Perhaps there should be one similar for debian and derivatives (CMAKE_LIBRARY_USE_LIB_ARCHITECTURE_PATHS?) Both GNUInstallDirs and FindPkgConfig could then benefit from them... Perhaps. The global property was from a brief design era when we thought about moving all platform information from variables to properties. It never happened but FIND_LIBRARY_USE_LIB64_PATHS ended up that way. The new one you propose could be a plain variable. The logic if(CMAKE_SYSTEM_NAME MATCHES ^(Linux|kFreeBSD|GNU)$ AND NOT CMAKE_CROSSCOMPILING) if (EXISTS /etc/debian_version) # is this a debian system ? could then be factored over into the platform info modules. Also at the moment on platforms that use lib64 the patch check both lib and lib64, perhaps it should check lib64 only? But locally installed libraries usually just install in prefix/lib, not lib64... But perhaps lib64 be searched first... What do you think? The find_library and find_package commands implement FIND_LIBRARY_USE_LIB64_PATHS by searching lib64 and then lib. This should honor FIND_LIBRARY_USE_LIB64_PATHS too. Look at the find_package implementation: http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmFindPackageCommand.cxx;hb=v3.0.0-rc1#l2077 for how it does lib/arch, then lib64, then lib. 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] Introduction and volunteering for the Matlab package
On 03/05/2014 05:46 PM, Raffi Enficiaud wrote: So, I began writing the doc of the module and changed the license according to the instructions. I am attaching the module to the email. Thanks! The documentation so far is a good start but it looks like you're still working on it. You can copy the module into CMake on top of the current FindMatlab.cmake locally, install sphinx-build, and then enable SPHINX_HTML in your local CMake build tree to build the documentation. It will appear in Utilities/Sphinx/html. - the error messages are more or less message(STATUS... and sometimes message(FATAL_ERROR, rather than using Xxx_NOT_FOUND_MESSAGE. So basically if I set this variable to the error message and just call “return()” from the module scope, it will do the job? The name_NOT_FOUND_MESSAGE variable is a feature of the helper module FindPackageHandleStandardArgs. Use that module's macro at the end of your module to do all the error handling and to set MATLAB_FOUND automatically. Most of the STATUS messages should either be dropped or conditioned on the QUIET option of the invoking find_package command. Some complex find modules like FindBoost have a special variable the user can set to get verbose debug output, e.g. if(MATLAB_FIND_DEBUG) message(STATUS ...) endif() - it looks like I am making too much use of the CACHE. However, I do not know if the variables like Xxx_INCLUDE_DIRS should go to the CACHE or to the PARENT_SCOPE. The singular names that have find_* command calls will be cached by those commands. Plural names like Xxx_INCLUDE_DIRS should just be set as normal variables with set() or list(APPEND), etc. They do not need PARENT_SCOPE unless you are using an internal helper function. CACHE entries should be used only for things that an end user might need to set or change to point at specific things on their system. - some of the variables should be renamed Yes. Also local variables like 64Build should be renamed to have a prefix like _matlab_ and then unset() at the end. - the version matching should be performed in the module, right ? Yes. I haven't read through the module thoroughly yet but please check that it will be compatible with the exiting FindMatlab.cmake that it is replacing. By compatible I mean that the same result variables must be made available to the calling project, even if documented as deprecated. 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] [Review request] Topic FindPkgConfig_Extend-PKG_CONFIG_PATH
On 06/03/14 17:25, Brad King wrote: Am I supposed to add documentation for the variable PKG_CONFIG_USE_CMAKE_PREFIX_PATH, that is checked by this patch? It looks like you've updated the docs further to use the variable directive. Good. Do you mind flipping the order of the patches to revise the documentation formatting first and then make the functional change? That will make it easier to see the actual change. Done. The find_library and find_package commands implement FIND_LIBRARY_USE_LIB64_PATHS by searching lib64 and then lib. This should honor FIND_LIBRARY_USE_LIB64_PATHS too. Look at the find_package implementation: http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmFindPackageCommand.cxx;hb=v3.0.0-rc1#l2077 for how it does lib/arch, then lib64, then lib. For now I reverted the order, but I'm still using the same checks and logic from GNUInstallDirs. Should I change it and use FIND_LIBRARY_USE_LIB64_PATHS instead? It is now something like this: if (debian) add lib/arch elseif (64 bit or unknown) add lib64 add lib (The reason for the unknown is that if project(foo NONE) is used, CMAKE_SIZEOF_VOID_P is not defined, and therefore we cannot use it to know if we are on a 64 bit platform.) The logic is slightly different from find_package that just does if (defined arch) add lib/arch if (UseLib64Paths) add lib64 add lib Should I change the logic as well to follow find_package? Cheers, Daniele -- 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] [Review request] Topic FindPkgConfig_Extend-PKG_CONFIG_PATH
On 03/06/2014 01:22 PM, Daniele E. Domenichelli wrote: For now I reverted the order, but I'm still using the same checks and logic from GNUInstallDirs. Should I change it and use FIND_LIBRARY_USE_LIB64_PATHS instead? Yes, I think so, because GNUInstallDirs is about install destinations and FIND_LIBRARY_USE_LIB64_PATHS is about search locations. In this case we want to influence search locations. if (debian) add lib/arch elseif (64 bit or unknown) add lib64 add lib That looks good except for FIND_LIBRARY_USE_LIB64_PATHS. The logic is slightly different from find_package that just does if (defined arch) add lib/arch if (UseLib64Paths) add lib64 add lib Actually UseLib64Paths depends on CMAKE_SIZEOF_VOID_P too. See the call to PlatformIs64Bit when setting it. 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] [Review request] Topic FindPkgConfig_Extend-PKG_CONFIG_PATH
On 03/06/2014 01:22 PM, Daniele E. Domenichelli wrote: On 06/03/14 17:25, Brad King wrote: revise the documentation formatting first Done. Thanks. Here are a couple comments: +.. command:: pkg_check_modules + +Checks for all the given modules. The text defining the command needs to be indented to be part of the explicit markup block. +.. code-block:: cmake + + pkg_check_modules(PREFIX [REQUIRED] [QUIET] MODULE [MODULE]*) The documentation style guide: http://www.cmake.org/cmake/help/v3.0/manual/cmake-developer.7.html#style says that command signatures should be plain literal blocks and not cmake code-blocks. Similar fixes will be needed throughout the module. 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] [Review request] Topic FindPkgConfig_Extend-PKG_CONFIG_PATH
On 03/06/2014 11:25 AM, Brad King wrote: On 03/05/2014 07:47 PM, Daniele E. Domenichelli wrote: I noticed that the CMAKE_FRAMEWORK_PATH and CMAKE_APPBUNDLE_PATH don't have documentation Just leave them as inline-literals for now if there is no doc to link. They can be added later. I pushed a doc-osx-path-variables topic to the stage to document these variables. You may rebase on that to reference them. 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] [Review request] Topic FindPkgConfig_Extend-PKG_CONFIG_PATH
if (debian) add lib/arch elseif (64 bit or unknown) add lib64 add lib That looks good except for FIND_LIBRARY_USE_LIB64_PATHS. Fixed. Now the logic is if (debian) add lib/arch elseif (FIND_LIBRARY_USE_LIB64_PATHS) add lib64 add lib The text defining the command needs to be indented to be part of the explicit markup block. [...] command signatures should be plain literal blocks and not cmake code-blocks. Done and done. I pushed a doc-osx-path-variables topic to the stage to document these variables. You may rebase on that to reference them. Rebased. Cheers, Daniele -- 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
