Re: [cmake-developers] Proposed change to behavior of find_program
On 12/19/2014 06:25 PM, Thompson, KT wrote: Hmm. It looks my original proposal breaks some backward compatibility. [snip] @@ -1148,13 +1148,13 @@ bool SystemTools::FileExists(const kwsys_stl::string filename) [snip] - return access(filename.c_str(), R_OK) == 0; + return access(filename.c_str(), R_OK) == 0 || access(filename.c_str(), X_OK) == 0; The issue your patch tries to address is tracked here: http://www.cmake.org/Bug/view.php?id=10468 However, there is a deeper issue discussed here: http://www.cmake.org/Bug/view.php?id=14022 Basically access is not the right way to implement FileExists. If we're going to change it at all, the change should make it do the right thing. See comments in issue 14022 for details. Unfortunately the full fix likely requires an audit of all FileExists call sites to determine which ones need to be just lstat and which ones care about permissions too. -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/mailman/listinfo/cmake-developers
Re: [cmake-developers] patch to fix installed size for cpack PackageMaker generator
On 12/21/2014 12:34 AM, Calin Cascaval wrote: [PATCH] fixes installed sizes for cpack PackageMaker generator Thanks. Applied: cpack: Fix installed size computation with PackageMaker generator http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=42ed76bc FYI, if you're still using the PackageMaker generator please note that it will require changes to package for OS X 10.10. The cmCPackPackageMakerGenerator::PackageCompatibilityVersion variable uses a floating point value for the OS X version so 10.10 ends up being treated as 10.1. Since Apple has deprecated PackageMaker no one has taken the time to fix this in CMake yet. -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/mailman/listinfo/cmake-developers
Re: [cmake-developers] Which binaries should be required in FindLATEX?
On 12/22/2014 02:44 AM, Christoph Grüninger wrote: please find attached a patch that introduces components handling for optional LaTeX executable. Thanks for working on this. Maybe we should deprecate the old variables name? The names should not be changed at all. They become cache entries that people may be setting in their scripts on the command line, or have set in existing build trees. Also the names are visible to the human in cmake-gui so calling them ..._FOUND does not make sense. The FPHSA component handling still leaves it to the module code to specify whether each component was found. Therefore you should just use a pattern like this: find_program(LATEX2HTML_CONVERTER ...) if (LATEX2HTML_CONVERTER) set(LATEX_LATEX2HTML_FOUND 1) else() set(LATEX_LATEX2HTML_FOUND 0) endif() Once you have that explicit mapping then you can optionally use lower-case component names. I have no strong preference on that though. Thanks, -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/mailman/listinfo/cmake-developers
[cmake-developers] CMake 3.2 feature freeze on 2015-02-02
Hi Folks, The feature freeze in 'master' for CMake 3.2 will be on Feb 2, 2015. I will announce a freeze in 'next' sometime in the preceding week so that we can get any remaining dashboard trouble cleaned up. Please schedule any planned topics accordingly. Any major or disruptive changes should be completed a few weeks prior to the freeze or delayed until after 'next' re-opens. Thanks, -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/mailman/listinfo/cmake-developers
[cmake-developers] Maintainer vacation until Jan 7
Hi Folks, FYI, tomorrow I'm heading out for vacation and will likely not be responsive until at least Jan 7. -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/mailman/listinfo/cmake-developers
Re: [cmake-developers] patch to fix installed size for cpack PackageMaker generator
Hi Brad, Thank you! Quick question: if PackageMaker is deprecated, what do you recommend for packaging on OSX. I will take a look and fix the compatibility version. Thanks, Calin http://developer.qualcomm.com/mare On Dec 22, 2014, at 06:40, Brad King brad.k...@kitware.com wrote: On 12/21/2014 12:34 AM, Calin Cascaval wrote: [PATCH] fixes installed sizes for cpack PackageMaker generator Thanks. Applied: cpack: Fix installed size computation with PackageMaker generator http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=42ed76bc FYI, if you're still using the PackageMaker generator please note that it will require changes to package for OS X 10.10. The cmCPackPackageMakerGenerator::PackageCompatibilityVersion variable uses a floating point value for the OS X version so 10.10 ends up being treated as 10.1. Since Apple has deprecated PackageMaker no one has taken the time to fix this in CMake yet. -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/mailman/listinfo/cmake-developers
[cmake-developers] Introducing targets in FindPkgConfig
Hi Daniele, the feature about CMake language I probably hate most is link_directories(). Sadly one currently needs to use it when working with software dependencies imported from PkgConfig. What I would like to get is the following: when a list of libraries and directories is returned by PkgConfig then for every of these libraries the absolute path to the library is determined using find_library() using the given directories as hints. With that, noone needs to use link_directories() anymore. Since this would introduce new behavior people would need to adapt their CMakeLists.txt to this new feature. Therefore I think it would be a good idea to expose this new information not by new variables, but using targets. So if I search for OpenSSL using PkgConfig I would get a target PkgConfig::OpenSSL that I can link to, and that has the libraries, compile flags, include dirs and whatnot. Sadly, I don't quite understand all the macros in FindPkgConfig.cmake. Can you either point me to the right place where I would hook up something like that or try doing it? Greetings, 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/mailman/listinfo/cmake-developers
Re: [cmake-developers] patch to fix installed size for cpack PackageMaker generator
On 12/22/2014 10:38 AM, Calin Cascaval wrote: if PackageMaker is deprecated, what do you recommend for packaging on OSX. IIRC Apple deprecated PackageMaker and no longer distributes it with Xcode. The preferred method of packaging on OS X is now with the DragNDrop generator. Users see a .dmg that they mount and view in Finder. Finder shows the .app and a symlink to the /Applications folder. The user needs only to drag the .app to the Applications symlink (or anywhere else they want to install it). I will take a look and fix the compatibility version. Great, thanks! -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/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] Avoid bad alloc for large files
On 12/20/2014 08:44 AM, Rolf Eike Beer wrote: This is basically the same, but it avoids the needless floating point arithmetic. Does it work for you? Thanks, Eike. Please add a topic to put this in 'next' when ready. Thanks, -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/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH][CTest] Fix error message in ctest_coverage command
On 12/22/2014 02:34 AM, Владислав Виноградов wrote: I'd like to submit a small patch for CTest tool. It fixes one error message from ctest_coverage command: Looks like there are more lines in the file: Original code prints line, while from logic it should print file name. Thanks! Applied: ctest_coverage: Fix error message to report the file name http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9c4984b4 -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/mailman/listinfo/cmake-developers
Re: [cmake-developers] FindSWIG and UseSWIG modules ain't having maintainer
Hi Tuukka, On 12/22/2014 02:16 AM, Tuukka Pasanen wrote: I'm fairly new to CMake but use it intensive in many applications. In one where SWIG stuff used to work very well in new version error started to rise and I noticed that SWIG ain't maintained anymore. If it's so I can start keeping it up-to-date as we rely on that. Great, thanks for volunteering! Please start by reading CONTRIBUTING.rst at the top of the CMake source tree. At first please send patches to this mailing list for review and integration. Thanks, -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/mailman/listinfo/cmake-developers
Re: [cmake-developers] patch to fix installed size for cpack PackageMaker generator
On 12/22/2014 10:52 AM, Sean McBride wrote: I had started a patch but haven't had time to test it. Perhaps you could continue from where I left off, see attached. Thanks, Sean. Calin, the patch currently hard-codes encoding of the major and minor versions into an integer: this-PackageCompatibilityVersion = ((10 16) | 4); I think the encoding is a good approach, but please factor it out into a helper macro (local to the .cxx file) so the encoding logic does not have to be repeated. Thanks, -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/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0015322]: Double backslash to escape '#' in CMAKE_CXX_FLAGS no longer works
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=15322
==
Reported By:Braden McDaniel
Assigned To:
==
Project:CMake
Issue ID: 15322
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2014-12-22 11:55 EST
Last Modified: 2014-12-22 11:55 EST
==
Summary:Double backslash to escape '#' in CMAKE_CXX_FLAGS no
longer works
Description:
In versions of CMake prior to 3.1.0, this worked:
set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} -Wno-\\#pragma-messages)
In CMake 3.1.0, that no longer works; this, however, does:
set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} -Wno-#pragma-messages)
I'm not sure if this is a deliberate change or not; but it's a slightly annoying
break with backward compatibility.
==
Issue History
Date ModifiedUsername FieldChange
==
2014-12-22 11:55 Braden McDanielNew 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/mailman/listinfo/cmake-developers
[cmake-developers] [Review request] Topic install_CMAKE_INSTALL_RELATIVE
Hello all, Please review the topic install_CMAKE_INSTALL_RELATIVE. install: Add CMAKE_INSTALL_RELATIVE variable http://www.cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=3b57fa0 This patch adds a a variable CMAKE_INSTALL_RELATIVE to install files in CMAKE_INSTALL_PREFIX using relative path, even if an absolute path was passed to the install() command. This might be useful in some cases to create binary packages. For example, CPack will refuse to create a relocatable package if files are installed using absolute paths, even if inside the prefix. In my experience, I found that many projects install files using absolute paths, even when they should be installed using a path relative to the CMAKE_INSTALL_PREFIX. This makes it impossible to package them using CPack without large modification of the cmake code. Moreover it makes it hard to install only one component in a different prefix, for example using: cmake -DCMAKE_PREFIX_PATH=/new/prefix -DCOMPONENT=foo \ -P cmake_install.cmake (You can probably use DESTDIR, calculating the relative path between the original prefix and the new prefix, but I believe that's not the best way to do it) Since the usage of absolute path instead of relative is in most of the cases just a an unwanted effect, I believe that using this variable, could simplify this kind of tasks. What do you think? Cheers, Daniele -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introducing targets in FindPkgConfig
Hello Eike, On 22/12/14 16:39, Rolf Eike Beer wrote: What I would like to get is the following: when a list of libraries and directories is returned by PkgConfig then for every of these libraries the absolute path to the library is determined using find_library() using the given directories as hints. [...] Since this would introduce new behavior people would need to adapt their CMakeLists.txt to this new feature. Therefore I think it would be a good idea to expose this new information not by new variables, but using targets. We have a macro to do exactly this and a few other things (actually 2 macros, that diverged slightly I will make them one again as soon I as I have some time), you can find them here: https://github.com/robotology/yarp/blob/master/conf/MacroStandardFindModule.cmake https://github.com/robotology/ycm/blob/master/modules/StandardFindModule.cmake The macro tries first to find a CMake config file (some recent version of some package installs cmake config files, but we still need to support older versions, so that's the reason for this check). If the config files were not found, it uses pkg-config to detect the package, and find the libraries as you want to do, but instead of creating targets it sets some variables (see the documentation in the files). It's probably not perfect, but with this, creating a FindXXX.cmake for a software using pkg-config becomes trivial, for example: https://github.com/robotology/yarp/blob/master/conf/FindGtkDataboxMM.cmake and then you just use find_package() to locate your package and to get the variables. I agree that using targets would be a great thing, but at the time I didn't find a way generic enough to do all of this in the macro, since it's not always easy to understand which one is the main library add_library(UNKNOWN IMPORTED) and which ones should be in the INTERFACE_LINK_LIBRARIES property. Moreover we depend on CMake 2.8.9 that does not support all the features that we would need for targets. Perhaps using a recent CMake version you can use add_library(INTERFACE IMPORTED) and put all of them in the INTERFACE_LINK_LIBRARIES? So if I search for OpenSSL using PkgConfig I would get a target PkgConfig::OpenSSL that I can link to, and that has the libraries, compile flags, include dirs and whatnot. Sadly, I don't quite understand all the macros in FindPkgConfig.cmake. Can you either point me to the right place where I would hook up something like that or try doing it? You can start from the macros I linked before for the pkg-config part, and then have a look at the CMake modules that create imported targets (FindQt4, FindGTK2, FindZLIB, FindGLUT, FindGLEW) for the targets part (all the variables you need should be there already). Let me know if you do it, I'd like to do it too one day... About the FindPkgConfig macros documentation, what is that is not clear? http://www.cmake.org/cmake/help/git-master/module/FindPkgConfig.html It looks well documented to me, but if there is something that is not clear we could try to improve it... I hope this helps. Let me know if I can help you more specifically with this... Cheers, Daniele -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introducing targets in FindPkgConfig
Am Montag, 22. Dezember 2014, 18:55:16 schrieb Daniele E. Domenichelli: Hello Eike, On 22/12/14 16:39, Rolf Eike Beer wrote: What I would like to get is the following: when a list of libraries and directories is returned by PkgConfig then for every of these libraries the absolute path to the library is determined using find_library() using the given directories as hints. [...] Since this would introduce new behavior people would need to adapt their CMakeLists.txt to this new feature. Therefore I think it would be a good idea to expose this new information not by new variables, but using targets. We have a macro to do exactly this and a few other things (actually 2 macros, that diverged slightly I will make them one again as soon I as I have some time), you can find them here: https://github.com/robotology/yarp/blob/master/conf/MacroStandardFindModule.cmake https://github.com/robotology/ycm/blob/master/modules/StandardFindModule.cmake [...] So if I search for OpenSSL using PkgConfig I would get a target PkgConfig::OpenSSL that I can link to, and that has the libraries, compile flags, include dirs and whatnot. Sadly, I don't quite understand all the macros in FindPkgConfig.cmake. Can you either point me to the right place where I would hook up something like that or try doing it? You can start from the macros I linked before for the pkg-config part, and then have a look at the CMake modules that create imported targets (FindQt4, FindGTK2, FindZLIB, FindGLUT, FindGLEW) for the targets part (all the variables you need should be there already). Let me know if you do it, I'd like to do it too one day... The imported targets was not the thing worrying me, although my experience with this is a bit limited at the moment. About the FindPkgConfig macros documentation, what is that is not clear? It's not about the documentation of that module, but where I need to hack it into the module. The code is quite a bit of indirections, I guess I would need to do this _pkg_check_modules_internal at the end of the last foreach? 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/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] Avoid bad alloc for large files
I received a bad alloc when uploading a large file with CTest. The patch below resolved this. Your patch is line-wrapped and can't be applied. However, I did this by hand. This is basically the same, but it avoids the needless floating point arithmetic. Does it work for you? snip std::string cmCTest::Base64EncodeFile(std::string file) snip -static_castdouble(len) * 1.5 + 5.0) ]; += new unsigned char [ (len * 3) / 2 + 5 ]; snip I came across a similar issue a few days ago in our code base (bad alloc when compressing a large file in-memory with 256 MB data ulimit per process) and I used a different formula to calculate the maximum buffer size: http://stackoverflow.com/questions/1533113/calculate-the-size-to-a-base-64-encoded-message I used a bit modified answer from kanaka. size_t output_size = ((len - 1) / 3) * 4 + 4; size_t final_size = output_size + (output_size / 64) * 2; // 64 instead of 76 since RFC 3548 and RFC 4648 allow CLRF line breaks every 64 characters This formula would give less memory allocation overhead. Regards, Domen -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] DragNDrop: Easier custom dmg layouts
I have pushed to next a branch called better_custom_dmgs that improves and helps automate the process of creating custom dmg's. Previously the DragNDrop generator allowed the user to specify a custom background image file and a custom .DS_Store. This approach had some serious limitations the primary being that a new .DS_Store would have to be externally created each time the package name was changed. The new version now allows the user to specify a custom apple script to run during the package step that is used to generate the .DS_Store. This allows projects to now have a nice looking package without having to externally generate a new .DS_Store. Additionally this branch has changed the behavior of CPACK_DMG_BACKGROUND_IMAGE. Now the background image is stored in a hidden folder, and the extension of the source image is retained. These changes are needed to allow the custom apple script to easily set the background image. If anyone has any questions or issues with this branch please tell me. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] Avoid bad alloc for large files
I received a bad alloc when uploading a large file with CTest. The patch
below resolved this.
I just took a look at the code and noticed that it is quite memory
consumption heavy ((2 * encoded_buffer_size) + file_buffer_size).
This implementation could be used instead (not tested):
std::string cmCTest::Base64EncodeFile(const std::string file)
{
const size_t len = cmSystemTools::FileLength(file);
cmsys::ifstream ifs(file.c_str(), std::ios::in
#ifdef _WIN32
| std::ios::binary
#endif
);
std::string base64; // set to empty string by default
// section for throwing encoded_buffer out of scope as soon as possible to
// use up less memory
{
const size_t output_size = ((len - 1) / 3) * 4 + 4;
const size_t final_size = output_size + (output_size / 64) * 2;
std::vectorunsigned char encoded_buffer;
encoded_buffer.resize(final_size);
// section for throwing file_buffer out of scope as soon as possible to
// use up less memory
{
std::vectorunsigned char file_buffer;
file_buffer.resize(len);
ifs.read(reinterpret_castchar*(file_buffer), len);
ifs.close();
unsigned long rlen
= cmsysBase64_Encode(file_buffer[0], len, encoded_buffer[0], 1);
}
// consume less memory by swapping tmp string buffer with base64 variable
std::string(encoded_buffer.begin(), encoded_buffer.begin() +
rlen).swap(base64);
}
return base64; // this will produce another copy in C++98
}
It lowers memory consumption to approximately (2 *
encoded_buffer_size) and it also makes memory deallocation exception
safe (file_buffer and encoded_buffer variables).
A better solution would be to rewrite the function to:
void cmCTest::Base64EncodeFile(const std::string file, std::string
base64) to prevent one more copy at return but since this changes the
interface we could go a step further and simply rewrite the entire
function and cmsysBase64_Encode function to use streams and thereby
lower the memory consumption even further (less copying between
different containers and more readable than the above version).
Thoughts?
p.s. I think that using std::ios::binary would work on all platforms
so I guess that the function does not need ifdef at the top.
Regards,
Domen
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [Review request] Topic install_CMAKE_INSTALL_RELATIVE
In my experience, I found that many projects install files using
absolute paths, even when they should be installed using a path relative
to the CMAKE_INSTALL_PREFIX. This makes it impossible to package them
using CPack without large modification of the cmake code.
Maybe others will disagree but to be quite honest I myself don't think
that CMAKE_INSTALL_RELATIVE variable would be the right solution... I
myself prefer to write install commands with relative paths and I
guess that something like that should be fixed in CMakeLists.txt and
contributed to projects that use absolute paths and not add a new
variable for doing this... (maybe someone decided to leave some paths
absolute for a reason e.g. symlinks or system/program requirements for
certain files).
Moreover it makes it hard to install only one component in a different
prefix, for example using:
cmake -DCMAKE_PREFIX_PATH=/new/prefix -DCOMPONENT=foo \
-P cmake_install.cmake
This is again something that can be solved by using for e.g.
GNUInstallDirs.cmake module and adding the paths set in this module to
paths provided to install commands.
As for CPack and different locations... I don't know about other
packagers but for RPM packages I wrote a patch a few weeks ago that
uses GNUInstallDirs.cmake and provides option to have more than one
relocation path per RPM package. The reason that I haven't contributed
it yet is that I still have to write tests for the code (I'll do this
in the following days) before submitting the patch for review.
Preview patch is attached.
Regards,
Domen
From 2d5289559527371e3fce555d49b20e6789d1324c Mon Sep 17 00:00:00 2001
From: Domen Vrankar domen.vran...@gmail.com
Date: Mon, 22 Dec 2014 21:22:34 +0100
Subject: [PATCH] multiple path relocation prefixes
Allow multiple path relocation prefixes for a single rpm package.
---
Modules/CPackRPM.cmake | 108 ++-
Modules/GNUInstallDirs.cmake | 2 +
2 files changed, 99 insertions(+), 11 deletions(-)
diff --git a/Modules/CPackRPM.cmake b/Modules/CPackRPM.cmake
index d2cb2ee..cf058c5 100644
--- a/Modules/CPackRPM.cmake
+++ b/Modules/CPackRPM.cmake
@@ -395,6 +395,83 @@
# Author: Eric Noulard with the help of Alexander Neundorf.
+function(cpack_rpm_prepare_relocation_paths)
+ set(RPM_RELOCATION_PATH_VARS
+ CPACK_PACKAGING_INSTALL_FULL_BINDIR CPACK_PACKAGING_INSTALL_FULL_SBINDIR
+ CPACK_PACKAGING_INSTALL_FULL_LIBEXECDIR CPACK_PACKAGING_INSTALL_FULL_SYSCONFDIR
+ CPACK_PACKAGING_INSTALL_FULL_SHAREDSTATEDIR CPACK_PACKAGING_INSTALL_FULL_LOCALSTATEDIR
+ CPACK_PACKAGING_INSTALL_FULL_LIBDIR CPACK_PACKAGING_INSTALL_FULL_INCLUDEDIR
+ CPACK_PACKAGING_INSTALL_FULL_OLDINCLUDEDIR CPACK_PACKAGING_INSTALL_FULL_DATAROOTDIR
+ CPACK_PACKAGING_INSTALL_FULL_DATADIR CPACK_PACKAGING_INSTALL_FULL_INFODIR
+ CPACK_PACKAGING_INSTALL_FULL_LOCALEDIR CPACK_PACKAGING_INSTALL_FULL_MANDIR
+ CPACK_PACKAGING_INSTALL_FULL_DOCDIR)
+ file(TO_CMAKE_PATH ${CPACK_PACKAGING_INSTALL_PREFIX} RPM_PACKAGE_PREFIX_PART)
+
+ if(CPACK_RPM_${CPACK_RPM_PACKAGE_COMPONENT}_PACKAGE_PREFIX)
+# remove possible trailing slash and convert backslashes to slashes
+file(TO_CMAKE_PATH ${CPACK_RPM_${CPACK_RPM_PACKAGE_COMPONENT}_PACKAGE_PREFIX} RPM_COMPONENT_PREFIX_)
+string(LENGTH ${RPM_PACKAGE_PREFIX_PART} RPM_PACKAGE_PREFIX_PART_LEN)
+set(RPM_PACKAGE_PREFIXES ${RPM_COMPONENT_PREFIX_})
+
+foreach(RELOCATE_PATH_VAR ${RPM_RELOCATION_PATH_VARS})
+ if(${RELOCATE_PATH_VAR})
+# check if path is a subpath of CPACK_PACKAGING_INSTALL_PREFIX
+file(RELATIVE_PATH REL_PATH_ ${RPM_PACKAGE_PREFIX_PART} ${${RELOCATE_PATH_VAR}})
+string(SUBSTRING ${REL_PATH_} 0 2 PREFIX_)
+
+if(${PREFIX_} STREQUAL ..) # not a subpath - leave it as is
+ file(TO_CMAKE_PATH ${${RELOCATE_PATH_VAR}} RELOCATE_PATH)
+ list(APPEND RPM_PACKAGE_PREFIXES ${RELOCATE_PATH})
+else() # a subpath - it should be replaced with component path
+ list(APPEND RPM_PACKAGE_PREFIXES ${RPM_COMPONENT_PREFIX_}/${REL_PATH_})
+endif()
+ endif()
+endforeach()
+ else()
+set(RPM_PACKAGE_PREFIXES ${RPM_PACKAGE_PREFIX_PART})
+foreach(RELOCATE_PATH_VAR ${RPM_RELOCATION_PATH_VARS})
+ if(${RELOCATE_PATH_VAR})
+file(TO_CMAKE_PATH ${${RELOCATE_PATH_VAR}} RELOCATE_PATH)
+list(APPEND RPM_PACKAGE_PREFIXES ${RELOCATE_PATH})
+ endif()
+endforeach()
+ endif()
+
+ list(REMOVE_DUPLICATES RPM_PACKAGE_PREFIXES)
+
+ # remove all the paths that are not used
+ foreach(RELOCATION_PATH ${RPM_PACKAGE_PREFIXES})
+if(EXISTS ${WDIR}/${RELOCATION_PATH})
+ set(TMP_RPM_PREFIXES ${TMP_RPM_PREFIXES}Prefix: ${RELOCATION_PATH}\n)
+ list(APPEND RPM_USED_PACKAGE_PREFIXES ${RELOCATION_PATH})
+endif()
+ endforeach()
+
+ # warn about all the paths that are not relocatable
+ file(GLOB_RECURSE FILE_PATHS_ ${WDIR}/*)
+ foreach(TMP_PATH ${FILE_PATHS_})
+string(LENGTH
[cmake-developers] [CMake 0015323]: Visual Studio 2013 %3B in IMPORTED_IMPLIB_CONFIG
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15323 == Reported By:yaruopooner Assigned To: == Project:CMake Issue ID: 15323 Category: CMake Reproducibility:always Severity: minor Priority: high Status: new == Date Submitted: 2014-12-22 15:45 EST Last Modified: 2014-12-22 15:45 EST == Summary:Visual Studio 2013 %3B in IMPORTED_IMPLIB_CONFIG Description: Include %3B in the output of the IMPORTED_IMPLIB_CONFIG. This problem has occurred from cmake3.1.0. 3.0.2 don't have this issue. I tried a few pattern. set_property(TARGET additional_dependencies PROPERTY IMPORTED_IMPLIB_RELEASE foo.lib bar.lib) or set_property(TARGET additional_dependencies PROPERTY IMPORTED_IMPLIB_RELEASE foo.lib;bar.lib) but I got same output. foo.lib%3Bbar.lib Steps to Reproduce: -console cmake -G Visual Studio 12 2013 Win64 . -CMakeLists.txt(Excerpt) add_library(additional_dependencies SHARED IMPORTED) set_property(TARGET additional_dependencies PROPERTY IMPORTED_IMPLIB_RELEASE foo.lib bar.lib) -output foo.lib%3Bbar.lib == Issue History Date ModifiedUsername FieldChange == 2014-12-22 15:45 yaruopoonerNew 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/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] Avoid bad alloc for large files
Am Montag, 22. Dezember 2014, 10:50:28 schrieb Brad King: On 12/20/2014 08:44 AM, Rolf Eike Beer wrote: This is basically the same, but it avoids the needless floating point arithmetic. Does it work for you? Thanks, Eike. Please add a topic to put this in 'next' when ready. Done. I wonder if we should not check for new returning null? 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/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0015324]: CMake 3.1.0 Crashes When Told to Regenerate a Project Originally Generated Under CMake 3.0.2
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15324 == Reported By:Bryce Glover Assigned To: == Project:CMake Issue ID: 15324 Category: CMake Reproducibility:sometimes Severity: crash Priority: low Status: new == Date Submitted: 2014-12-22 16:20 EST Last Modified: 2014-12-22 16:20 EST == Summary:CMake 3.1.0 Crashes When Told to Regenerate a Project Originally Generated Under CMake 3.0.2 Description: If one runs the command 'cmake -G Xcode [project-location]' from within '[project-location]/build/' after updating CMake from version 3.0.2 to version 3.1.0 when this directory was last populated by CMake 3.0.2. Steps to Reproduce: 1.) Make sure that CMake 3.0.2 is installed. 2.) Run 'cmake -G Xcode [project-location]' from within '[project-location]/build/' via Terminal. 3.) Update CMake from version 3.0.2 to version 3.1.0. 4.) Run 'cmake -G Xcode [project-location]' from within '[project-location]/build/' via Terminal again. 5.) CMake should crash when 'Checking for a C compiler using Xcode….' Additional Information: The project I'm having trouble with is LLVM/Clang/compiler-rt/test-suite, and I use Homebrew in order to keep CMake up to date. == Issue History Date ModifiedUsername FieldChange == 2014-12-22 16:20 Bryce Glover 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/mailman/listinfo/cmake-developers
Re: [cmake-developers] [Review request] Topic install_CMAKE_INSTALL_RELATIVE
On 12/22/2014 03:28 PM, Domen Vrankar wrote: Maybe others will disagree but to be quite honest I myself don't think that CMAKE_INSTALL_RELATIVE variable would be the right solution... I myself prefer to write install commands with relative paths and I guess that something like that should be fixed in CMakeLists.txt and contributed to projects that use absolute paths and not add a new variable for doing this... I agree. If a project uses absolute install paths that means its authors have not thought about making relocatable packages. There could be many other problems with making such projects relocatable other than just install rules. -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/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0015325]: Regression building x265 using CMake 3.1 (Segmentation fault)
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15325 == Reported By:David Coppa Assigned To: == Project:CMake Issue ID: 15325 Category: CMake Reproducibility:always Severity: crash Priority: normal Status: new == Date Submitted: 2014-12-22 16:27 EST Last Modified: 2014-12-22 16:27 EST == Summary:Regression building x265 using CMake 3.1 (Segmentation fault) Description: CMake 3.1 segfaults while building x265 using the ninja generator, Unix Makefiles generator is not affected. This crash didn't happen with cmake-3.0.2 (same version of x265). I have the same segfault on both Arch Linux and OpenBSD-current. I've attached two files with the gdb output for both systems. You can have a look at the source code for x265 here: https://github.com/videolan/x265/tree/master/source/cmake $ cmake -G Ninja -DCMAKE_INSTALL_PREFIX=/usr ../source/ -- cmake version 3.1.0 -- The C compiler identification is GNU 4.9.2 -- The CXX compiler identification is GNU 4.9.2 -- Check for working C compiler using: Ninja -- Check for working C compiler using: Ninja -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler using: Ninja -- Check for working CXX compiler using: Ninja -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Detected x86 target processor -- Looking for include file inttypes.h -- Looking for include file inttypes.h - found -- Performing Test CC_HAS_NO_NARROWING -- Performing Test CC_HAS_NO_NARROWING - Success -- Performing Test CC_HAS_NO_ARRAY_BOUNDS -- Performing Test CC_HAS_NO_ARRAY_BOUNDS - Success -- Performing Test CC_HAS_FAST_MATH -- Performing Test CC_HAS_FAST_MATH - Success -- Performing Test CC_HAS_STACK_REALIGN -- Performing Test CC_HAS_STACK_REALIGN - Success -- Performing Test CC_HAS_FNO_EXCEPTIONS_FLAG -- Performing Test CC_HAS_FNO_EXCEPTIONS_FLAG - Success -- Found yasm: /usr/bin/yasm (found version 1.3.0) -- Found Yasm 1.3.0 to build assembly primitives -- x265 version 1.4 -- The ASM_YASM compiler identification is unknown -- Found assembler: /usr/bin/yasm -- Looking for strtok_r -- Looking for strtok_r - found -- Looking for include file getopt.h -- Looking for include file getopt.h - found -- Configuring done CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly. Missing variable is: CMAKE_ASM_YASM_COMPILE_OBJECT Segmentation fault (core dumped) Steps to Reproduce: Try building x265 using the ninja generator of CMake 3.1.0. == Issue History Date ModifiedUsername FieldChange == 2014-12-22 16:27 David CoppaNew Issue 2014-12-22 16:27 David CoppaFile Added: cmake31-x265-openbsd.out == -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Which binaries should be required in FindLATEX?
Hi Brad,
please find attached a new patch following your latest suggestions.
Once you have that explicit mapping then you can optionally use
lower-case component names. I have no strong preference on that
though.
I'd like to have lower case components but I dislike mixed-cased
variable names. The latter feeling is stronger.
Wish you nice holidays,
Christoph
From 66b20975b29af82d2f561e9324c53fed717311a1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Christoph=20Gr=C3=BCninger?= gruen...@dune-project.org
Date: Tue, 23 Dec 2014 00:24:04 +0100
Subject: [PATCH] FindLATEX: Add components handling
---
Modules/FindLATEX.cmake | 85 +
1 file changed, 79 insertions(+), 6 deletions(-)
diff --git a/Modules/FindLATEX.cmake b/Modules/FindLATEX.cmake
index a935f00..954f8f7 100644
--- a/Modules/FindLATEX.cmake
+++ b/Modules/FindLATEX.cmake
@@ -6,17 +6,42 @@
#
# This module finds an installed Latex and determines the location
# of the compiler. Additionally the module looks for Latex-related
-# software like BibTeX. This code sets the following variables:
+# software like BibTeX.
+#
+# This module sets the following result variables:
#
# ::
#
+# LATEX_FOUND: whether found Latex and requested components
+# LATEX_component_FOUND: whether found component
# LATEX_COMPILER: path to the LaTeX compiler
# PDFLATEX_COMPILER:path to the PdfLaTeX compiler
# BIBTEX_COMPILER: path to the BibTeX compiler
# MAKEINDEX_COMPILER: path to the MakeIndex compiler
# DVIPS_CONVERTER: path to the DVIPS converter
+# DVIPDF_CONVERTER: path to the DVIPDF converter
# PS2PDF_CONVERTER: path to the PS2PDF converter
# LATEX2HTML_CONVERTER: path to the LaTeX2Html converter
+#
+# Possible components are:
+#
+# ::
+#
+# PDFLATEX
+# BIBTEX
+# MAKEINDEX
+# DVIPS
+# DVIPDF
+# PS2PDF
+# LATEX2HTML
+#
+# Example Usages:
+#
+# ::
+#
+# find_package(LATEX)
+# find_package(LATEX COMPONENTS PDFLATEX)
+# find_package(LATEX COMPONENTS BIBTEX PS2PDF)
#=
# Copyright 2002-2014 Kitware, Inc.
@@ -32,9 +57,7 @@
# License text for the above reference.)
if (WIN32)
-
# Try to find the MikTex binary path (look for its package manager).
-
find_path(MIKTEX_BINARY_PATH mpm.exe
[HKEY_LOCAL_MACHINE\\SOFTWARE\\MiK\\MiKTeX\\CurrentVersion\\MiKTeX;Install Root]/miktex/bin
DOC
@@ -43,7 +66,6 @@ if (WIN32)
mark_as_advanced(MIKTEX_BINARY_PATH)
# Try to find the GhostScript binary path (look for gswin32).
-
get_filename_component(GHOSTSCRIPT_BINARY_PATH_FROM_REGISTERY_8_00
[HKEY_LOCAL_MACHINE\\SOFTWARE\\AFPL Ghostscript\\8.00;GS_DLL] PATH
)
@@ -64,45 +86,76 @@ if (WIN32)
DOC Path to the GhostScript library directory.
)
mark_as_advanced(GHOSTSCRIPT_LIBRARY_PATH)
-
endif ()
+# try to find Latex and the related programs
find_program(LATEX_COMPILER
NAMES latex
PATHS ${MIKTEX_BINARY_PATH}
/usr/bin
)
+# find pdflatex
find_program(PDFLATEX_COMPILER
NAMES pdflatex
PATHS ${MIKTEX_BINARY_PATH}
/usr/bin
)
+if (PDFLATEX_COMPILER)
+ set(LATEX_PDFLATEX_FOUND TRUE)
+else()
+ set(LATEX_PDFLATEX_FOUND FALSE)
+endif()
+# find bibtex
find_program(BIBTEX_COMPILER
NAMES bibtex
PATHS ${MIKTEX_BINARY_PATH}
/usr/bin
)
+if (BIBTEX_COMPILER)
+ set(LATEX_BIBTEX_FOUND TRUE)
+else()
+ set(LATEX_BIBTEX_FOUND FALSE)
+endif()
+# find makeindex
find_program(MAKEINDEX_COMPILER
NAMES makeindex
PATHS ${MIKTEX_BINARY_PATH}
/usr/bin
)
+if (MAKEINDEX_COMPILER)
+# set(LATEX_MAKEINDEX_FOUND TRUE)
+else()
+ set(LATEX_MAKEINDEX_FOUND FALSE)
+endif()
+# find dvips
find_program(DVIPS_CONVERTER
NAMES dvips
PATHS ${MIKTEX_BINARY_PATH}
/usr/bin
)
+if (DVIPS_CONVERTER)
+ set(LATEX_DVIPS_FOUND TRUE)
+else()
+ set(LATEX_DVIPS_FOUND FALSE)
+endif()
+# find dvipdf
find_program(DVIPDF_CONVERTER
NAMES dvipdfm dvipdft dvipdf
PATHS ${MIKTEX_BINARY_PATH}
/usr/bin
)
+if (DVIPDF_CONVERTER)
+ set(LATEX_DVIPDF_FOUND TRUE)
+else()
+ set(LATEX_DVIPDF_FOUND FALSE)
+endif()
+# find ps2pdf
if (WIN32)
find_program(PS2PDF_CONVERTER
NAMES ps2pdf14.bat ps2pdf14 ps2pdf
@@ -114,26 +167,46 @@ else ()
NAMES ps2pdf14 ps2pdf
)
endif ()
+if (PS2PDF_CONVERTER)
+ set(LATEX_PS2PDF_FOUND TRUE)
+else()
+ set(LATEX_PS2PDF_FOUND FALSE)
+endif()
+# find latex2html
find_program(LATEX2HTML_CONVERTER
NAMES latex2html
PATHS ${MIKTEX_BINARY_PATH}
/usr/bin
)
+if (LATEX2HTML_CONVERTER)
+ set(LATEX_LATEX2HTML_FOUND TRUE)
+else()
+ set(LATEX_LATEX2HTML_FOUND FALSE)
+endif()
mark_as_advanced(
LATEX_COMPILER
PDFLATEX_COMPILER
+ LATEX_PDFLATEX_FOUND
BIBTEX_COMPILER
+ LATEX_BIBTEX_FOUND
MAKEINDEX_COMPILER
+ LATEX_MAKEINDEX_FOUND
DVIPS_CONVERTER
+ LATEX_DVIPS_FOUND
DVIPDF_CONVERTER
+ LATEX_DVIPDF_FOUND
PS2PDF_CONVERTER
+
Re: [cmake-developers] Extracting target metadata, IDE integration
On Thu, Sep 25, 2014 at 9:14 AM, Anton Makeev anton.mak...@jetbrains.com wrote: Hey everyone, We are developing CLion at JetBrains that utilizes CMake as its main project model. Stephen Kelly timely drew our attention to this discussion, and I’d like to share some thoughts. Here are the general ones and I’ll also comment on separate messages in the thread. We’ve managed to get almost all the necessary project information, using ‘GNU/MinGW Makefiles’ generators: * list of targets comes from 'CMakeFiles/TargetDirectories.txt' * list of source files from ‘CMakeFiles/A.dir/DependInfo.cmake’ * list of headers and resources from ‘codeblocks.cbp’ file * per-file/target compiler and its flags from ‘CMakeFiles/Target.dir/flags.make’ * location of product files from ‘CMakeFiles/Target.dir/build.make’ What we miss (not all of them are directly related the targets metadata, but I'd like to share anyway since the topic is about IDE integration): * Location of every source file and target in CMakeLists - it would greatly help to refactorings, navigation etc. In the implementation I'm proposing, the target is specified. The file is hard to figure out given that it's passed as a string argument and it could come virtually from anywhere (i.e. glob, operations, a set() somewhere else, etc.). My conclusion is that knowing the target position is already a good enough help. * Complete list of headers and resource files - they are only listed in special generators like code blocks. I'll look into it, what do you need exactly? The headers in each target? * An easily parseable list of errors and warnings with origin information. At the moment we parse error output but not everything can be parsed reliably. Agreed, It's something we're missing as well. I also don't really like the fact that sometimes the paths are absolute and sometimes they're relative, especially in the relative case, since it's hard to tell if it's relative to the build directory or source directory. * No progress indication. Since the generation may take several minutes, providing feedback is crucial. I never found such case, I would argue that a project which has a cmake script that takes several minutes is broken, but maybe we can open a thread to discuss it? * Ability to distinguish a library from an executable target. This will help to offer a better UI for run/debug configurations. It's included in the proposed implementation. * Possibility to collect information for every build target in one run. Currently, we have to invoke generator for every CMAKE_BUILT_TYPE separately. Well, that's because you use CodeBlocks generators. It seems like for example in MSVC they generate many build configurations at once. This implementation supports having parallel debug/release builds. Then we can fix make/ninja generators or even create new ones. * CMake stops processing when it find a missing file, so that IDE cannot have full project model, until this files is created. Well, it's related to the error generation issue we discussed. I think it's something we should discuss in parallel. * When there are existing in-source generated files in the project dir, CMake doesn't allow generating into a separate out-of-source folder. An IDE has to invent workarounds here. Arguably, in-source generation is broken by definition... * Not sure if it’s possible at all - a lightweight phase where CMake only collects necessary information (list of files/targets, compiler settings). This will help IDE react to the changes much faster. That would be extra-cool, agreed. Maybe it's an iteration we can consider in the future. Here is why I think the discussed functionality should not be a separate generator: CLion doesn’t have it’s own project model nor is intended as build tool replacement. Currently, the only option for CLion users is makefiles build, that is not a best option for everyone: there is a good and fast alternative ‘Ninja’. Ideally, users should be able to choose whatever tool better suites them. The problem is that the generated Makefiles are used both, for internal needs, like reading project structure, and also to build and run the user’s program. If we wanted to support Ninja generator, we would need to rewrite all the logic that retrieves the project information, using the files that are created by Ninja generator. While I suppose it’s possible, it’s not the best option - very error prone and resource demanding. If CMake generated a separate descriptor, regardless the generator used (Makefiles, Ninja), it would be much easier to support; and the users will benefit from better, more reliable and faster CMake integration in an IDE. I'd really appreciate your feedback on the patch I provided, I'll be happy to provide the information you miss. Aleix -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at:
Re: [cmake-developers] Extracting target metadata, IDE integration
On Tue, Dec 23, 2014 at 1:30 AM, Aleix Pol aleix...@kde.org wrote: On Thu, Sep 25, 2014 at 9:14 AM, Anton Makeev anton.mak...@jetbrains.com wrote: Hey everyone, We are developing CLion at JetBrains that utilizes CMake as its main project model. Stephen Kelly timely drew our attention to this discussion, and I’d like to share some thoughts. Here are the general ones and I’ll also comment on separate messages in the thread. We’ve managed to get almost all the necessary project information, using ‘GNU/MinGW Makefiles’ generators: * list of targets comes from 'CMakeFiles/TargetDirectories.txt' * list of source files from ‘CMakeFiles/A.dir/DependInfo.cmake’ * list of headers and resources from ‘codeblocks.cbp’ file * per-file/target compiler and its flags from ‘CMakeFiles/Target.dir/flags.make’ * location of product files from ‘CMakeFiles/Target.dir/build.make’ What we miss (not all of them are directly related the targets metadata, but I'd like to share anyway since the topic is about IDE integration): * Location of every source file and target in CMakeLists - it would greatly help to refactorings, navigation etc. In the implementation I'm proposing, the target is specified. The file is hard to figure out given that it's passed as a string argument and it could come virtually from anywhere (i.e. glob, operations, a set() somewhere else, etc.). My conclusion is that knowing the target position is already a good enough help. * Complete list of headers and resource files - they are only listed in special generators like code blocks. I'll look into it, what do you need exactly? The headers in each target? * An easily parseable list of errors and warnings with origin information. At the moment we parse error output but not everything can be parsed reliably. Agreed, It's something we're missing as well. I also don't really like the fact that sometimes the paths are absolute and sometimes they're relative, especially in the relative case, since it's hard to tell if it's relative to the build directory or source directory. * No progress indication. Since the generation may take several minutes, providing feedback is crucial. I never found such case, I would argue that a project which has a cmake script that takes several minutes is broken, but maybe we can open a thread to discuss it? * Ability to distinguish a library from an executable target. This will help to offer a better UI for run/debug configurations. It's included in the proposed implementation. * Possibility to collect information for every build target in one run. Currently, we have to invoke generator for every CMAKE_BUILT_TYPE separately. Well, that's because you use CodeBlocks generators. It seems like for example in MSVC they generate many build configurations at once. This implementation supports having parallel debug/release builds. Then we can fix make/ninja generators or even create new ones. * CMake stops processing when it find a missing file, so that IDE cannot have full project model, until this files is created. Well, it's related to the error generation issue we discussed. I think it's something we should discuss in parallel. * When there are existing in-source generated files in the project dir, CMake doesn't allow generating into a separate out-of-source folder. An IDE has to invent workarounds here. Arguably, in-source generation is broken by definition... * Not sure if it’s possible at all - a lightweight phase where CMake only collects necessary information (list of files/targets, compiler settings). This will help IDE react to the changes much faster. That would be extra-cool, agreed. Maybe it's an iteration we can consider in the future. Here is why I think the discussed functionality should not be a separate generator: CLion doesn’t have it’s own project model nor is intended as build tool replacement. Currently, the only option for CLion users is makefiles build, that is not a best option for everyone: there is a good and fast alternative ‘Ninja’. Ideally, users should be able to choose whatever tool better suites them. The problem is that the generated Makefiles are used both, for internal needs, like reading project structure, and also to build and run the user’s program. If we wanted to support Ninja generator, we would need to rewrite all the logic that retrieves the project information, using the files that are created by Ninja generator. While I suppose it’s possible, it’s not the best option - very error prone and resource demanding. If CMake generated a separate descriptor, regardless the generator used (Makefiles, Ninja), it would be much easier to support; and the users will benefit from better, more reliable and faster CMake integration in an IDE. I'd really appreciate your feedback on the patch I provided, I'll be happy to provide the information you miss. Aleix By the way, I just
Re: [cmake-developers] [Review request] Topic install_CMAKE_INSTALL_RELATIVE
On Mon, Dec 22, 2014 at 1:25 PM, Brad King brad.k...@kitware.com wrote:
On 12/22/2014 03:28 PM, Domen Vrankar wrote:
Maybe others will disagree but to be quite honest I myself don't think
that CMAKE_INSTALL_RELATIVE variable would be the right solution... I
myself prefer to write install commands with relative paths and I
guess that something like that should be fixed in CMakeLists.txt and
contributed to projects that use absolute paths and not add a new
variable for doing this...
I agree. If a project uses absolute install paths that means its
authors have not thought about making relocatable packages. There
could be many other problems with making such projects relocatable
other than just install rules.
THere's not a problem with relative install paths; why were they passed as
absolute? Just apply a pre-filter on your side like if( matches
${destpath} ${cmake_install_prefix} ) subst it out. All paths are
relative to start with; and seems like a corruption to have an abosolute
path
-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/mailman/listinfo/cmake-developers
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
