Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
Picking a message randomly, to respond to - Can someone tell me what this comment is referring to? # FIXME: This should be part of Qt5 CMake scripts, but unfortunatelly # Qt5 Mac support is missing there. AFAIR it is about installing correct app bundle PlugIns. Qt provides half-baked CMake support, but some of necessary things still has to be done by user manually, such as installing cocoa platform plugin. --Adam -- 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] New command 'file(LOCK_DIRECTORY ...)'
On Fri, Oct 10, 2014 at 17:59:07 +0400, Ruslan Baratov via cmake-developers wrote: Behavior when there's a lock that still exists (by bug/mistake) after CMake is done running is going to be strange and possibly hard-to-diagnose / hard-to-understand. That's *exactly* the problem I have and why I start this discussion. Currently I'm using mkdir command which return 0 only if directory created by current process (just to clarify, not the cmake -E make_directory). This works fine for me (tested on windows (mingw, cygwin), linux and mac). But I can't (or I don't know how) make remove this directory when I Ctrl+C my build (or abort the job on jenkins server). My current implementation just keep spinning with message: Directory locked by cmake, build started in directory cmake-binary-dir at timestamp. Maybe we need something like the 'trap' shell builtin which runs code on various triggers rather than something like file/directory locks which are…hairy (especially in the face of things like NFS or Samba)? I can think of at least: - end of configure - end of generate - end of directory scope - end of scope (function or directory) --Ben -- 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] New command 'file(LOCK_DIRECTORY ...)'
On 10/10/2014 07:45 AM, Ruslan Baratov wrote: file(TRY_LOCK /path/to/file result) # try to lock and return TRUE on success (needed?) file(LOCK ...) # lock until unlock (unlock by further code (what if exit/crashed?) or by deamon) The LOCK signature should have a timeout after which it returns failure instead of blocking forever. One can just use a timeout of 0 to get TRY_LOCK behavior without a separate signature for it. Or, by leaving out the timeout, one can ask to block forever waiting for the lock. file(LOCK_GUARD ...) # lock for scope of current function or until exit I think the GUARD part can be an option to file(LOCK). We may need more than one to determine the scope, e.g. file(LOCK GUARD_FUNCTION ...) file(LOCK GUARD_PROCESS ...) file(UNLOCK ...) # explicit unlock of LOCK/LOCK_GUARD Perhaps file(LOCK RELEASE ...) # unlock now file(LOCK UNGUARD ...) # drop guard Locking directory is equivalent to locking file `cmake.lock` in directory /path/to/shared/directory/: I think this can be activated buy a DIRECTORY option. If any of this commands failed (e.g. have no permissions) - exit with unsuccessful code (i.e. FATAL_ERROR) ? The commands should all have an optional result argument so callers can find out what happened. If it is not provided, then failure can result in a FATAL_ERROR. With all the above in mind, please brainstorm and propose a more complete signature set. You can use the keyword/value pairing common in other commands to avoid needing a positional argument for every value. Also, please post a summary of how the implementation will work on each platform. 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] New command 'file(LOCK_DIRECTORY ...)'
On 10/13/2014 10:34 AM, Ben Boeckel wrote: Maybe we need something like the 'trap' shell builtin which runs code on various triggers That would first require an 'eval' equivalent in CMake, e.g. cmake_eval(). This has been requested a few times. -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] Proposed Feature: Selective search path re-rooting
Following the topic branch to separately maintain each type of search path,
I'm working on adding a feature for cross-compiling to separately control
how each type of search path gets re-rooted. Currently, the options
CMAKE_FIND_ROOT_PATH_MODE_{INCLUDE_LIBRARY_PROGRAM} can be set to ONLY,
NEVER, or BOTH. This takes effect for all search paths, both CMake
determined and user-specifies (through HINTS and PATHS options). Before
putting the time and effort into implementing the feature this way, I
wanted to get some feedback on the design first:
My approach to control the path types independently is to allow the
variable to be specified as either a single mode, applying to all paths, or
a named list of the form PATH_TYPE1 MODE1 PATH_TYPE2_MODE2... much in the
way that properties are specified. The following search path groups can be
specified:
- CMAKE_PATH
- CMAKE_ENVIRONMENT_PATH
- USER_HINTS_PATH
- SYSTEM_ENVIRONMENT_PATH
- CMAKE_SYSTEM_PATH
- USER_GUESS_PATH
In addition to each search path type, there will also be defined path
groups:
- ALL - All search paths
- DEFAULT
- CMAKE_PATH
- CMAKE_ENVIRONMENT_PATH
- SYSTEM_ENVIRONMENT_PATH
- CMAKE_SYSTEM_PATH
- USER - User hints and user guess paths
If one had:
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ALL ONLY HINTS NEVER)
Then the following modes would be set:
- find_program: All search paths set to never
- find_library: user hints would never be re-rooted and all others would
operate in ONLY mode.
- find_file: All search paths set to BOTH mode since that's the default
behavior.
- Chuck
--
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] fix-OSX-bundle-rpaths-and-Qt5 topic
On 10/13/2014 05:54 AM, Adam Strzelecki wrote: Qt provides half-baked CMake support Side note: this is not a fair characterization of Qt's support for CMake. Qt5 is an outstanding example of how an upstream can make it easy to use a project with CMake even when the upstream itself does not use CMake. Qt5 provides package configuration files for find_package(), and once loaded they provide imported targets with usage requirements. Building a CMake-based project against Qt5 couldn't be much easier IMO. Furthermore, all the CMake-related files come with Qt5 and are maintained there rather than in CMake. This is much easier than Qt4, where FindQt4 in CMake has needed maintenance with every new upstream version. -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] [CPack] Call for volunteer for CPackRPM, CPackDeb maintenance.
On 10/09/2014 04:58 PM, Eric Noulard wrote: Hi everybody, This message is an open request to find volunteer maintainers for CPackRPM and CPackDeb which were my main contributions to CPack (CPackDeb was initially contributed by Mathieu). I have 21 Mantis tickets (http://public.kitware.com/Bug) assigned to me I will soon unassign them or transfer them to volunteering people. I did contribute to CMake/CPack for some time (~2007) now but my CMake free time is now too small to be able to test and integrate contribution/patches to CPackDeb and CPackRPM. I will be listening to the mailing lists as usual but one shall not count on a timely responsiveness from me. I shall say that this is not a lack of interest but a clear lack of time. I do continue to use CMake/CPack/CTest on a daily basis but cannot find enough time to contribute anymore. I'll try my best to help the volunteer(s) to take over. People interested may answer here and/or send me direct e-mail if they find it necessary. I shall say that the CMake developer community including Kitware people (off course) were (and are) very helpful and always kind to handle my cmake/cpack contribution. -- Erk L'élection n'est pas la démocratie -- http://www.le-message.org Hello list, With this mail I would like to help out maintaining these modules. I have been reading this list for a while, and been a happy CMake user for several years now. It has saved me a lot of time, so I deceided it was time I contributed some of it back. With kind regards, Micha Hergarden signature.asc Description: OpenPGP digital signature -- 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] [CPack] Call for volunteer for CPackRPM, CPackDeb maintenance.
On 10/13/2014 01:36 PM, Micha Hergarden wrote: With this mail I would like to help out maintaining these modules. Wonderful, thanks! To others: this does not close the call. We can have more than one maintainer with overlapping responsibilities. Micha, please start by taking a look at the proposal here: [PATCH] Preinstall requirements support for CPack RPM generator http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/11235/focus=11253 and the corresponding issue tracker entry: CPackRPM: need CPACK_RPM_Component_PACKAGE_PRE/POST_REQUIRES http://www.cmake.org/Bug/view.php?id=14769 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] Introduction and volunteering for the Matlab package
Hi Brad,(Sorry for the late answer (again).)I addressed your comments in the files attached to this email (please see the remarks below). I have not yet addressed your comment about “MATLAB_ADDITIONAL_VERSIONS” but I think it is a better proposition, so I will do it next.I updated the documentation also, I think it looks now understandable.I had a hard time making some stuff compile again with Matlab under Linux. The fact is that Matlab is shipped with its own version of libC, libhdf5, libboost etc, and sometimes the filenames are the same (eg. hdf5, or libc) but the subminor versions are not. If I understand properly, the fact that the filenames are the same prevents the dynamic loader of Linux to load the files that are referred by the mex file in their respective rpath (there is only one libhdf51.8.2.so in the matlab process). Beside that, the symbols also may clash: I had an implementation with a dynamic loader under linux, but yet the boost symbols of my mex files were not loaded because same symbols were already there in the process.I found a technical solution to this on Linux:- the use of -Wl,--exclude-libs,ALL for the linker.- the symbol hiding (both include and function definition) from within the mex file- exporting only the mexFunction symbolI know that this scheme is working for statically linked libraries, that then should be recompiled with -fPIC. I know also that this is working for shared libraries that do not have the same name (eg. boost1.49.so vs. boost1.55.so). But I think there is nothing more I can do for the shared library having the same name (like hdf51.8.2.so), having the same symbols but apparently having a different ABI.I do not know how to do that properly under OSX neither. There is no -Wl,--exclude-libs,ALL option in Clang.Also, I am checking against CMAKE_CXX_COMPILER_ID, which is I think a not so good idea. Is there anything for having the -Wl,--exclude-libs,ALL like the variable CXX_VISIBILITY_PRESET in cmake? I started using a .map file on these two platforms, but also I would prefer limiting the number of files.I am using this FindMatlab in two projects now, under OSX 10.9, Win7 Visual2013 and Ubuntu12.04.Best,Raffi
FindMatlab.cmake
Description: Binary data
MatlabTestsRedirect.cmake
Description: Binary data
——Hi Raffi,Thanks for your continuing work on this module.I've made some whitespace and quoting tweaks to the files. See attachedupdated versions. I also renamed the test helper to not start in "Find"since no one should call find_package(Matlab_TestsRedirect). See furthercomments below.On 07/04/2014 08:02 PM, Raffi Enficiaud wrote:Many of our tests use "cmake -P" to run a cmake script that performsthe test inside. You can use -Dvar=${val} before the -P option topass options to the script, such as $TARGET_FILE_DIR:my_mex_target.Done: this is the add_matlab_unit_test function. In fact, I think I canremove the log files since they are redundant with the tests logs.I see no problem with that, but I'm not familiar with the tools.I added a function add_matlab_mex that is like a add_libraryPlease make all APIs start in "matlab_”.DoneThe documentation blocks for each command also need to start in "#.rst:"#.rst:# .. command:: add_matlab_mexor they will not be included in the processed documentation.Ok. I checked the documentation again, and I think it contains now all the necessary information, plus it is now visually more appealing.for creating MEX (compiled) extensions. There is an option to thisfunction called REDUCE_VISIBILITYI see that implemented here:if(HAS_VISIBILITY_INLINE_HIDDEN)target_compile_options(${${prefix}_NAME} PRIVATE "-fvisibility-inlines-hidden")endif()if(HAS_VISIBILITY_HIDDEN)target_compile_options(${${prefix}_NAME} PRIVATE "-fvisibility=hidden")endif()An upstream version of the module should use the builtin featuresfor visibility settings:http://www.cmake.org/cmake/help/v3.0/prop_tgt/LANG_VISIBILITY_PRESET.htmlhttp://www.cmake.org/cmake/help/v3.0/prop_tgt/VISIBILITY_INLINES_HIDDEN.htmlI am not sure how to do that, please have a look at my changes. It looks ok to me (generated compilation command include the visibility element) but maybe there is something better.# set(MATLAB_ADDITIONAL_VERSIONS# "release_name1" "corresponding_version1"# "release_name2" "corresponding_version2"# ...# )Rather than relying on matched pairs, perhaps use "=" to separate:# set(MATLAB_ADDITIONAL_VERSIONS# "release_name1=corresponding_version1"# "release_name2=corresponding_version2"?Right, it is better.I am not sure how my implementation is compatible with the previousFindMatlab package. The requirements are to define the same variables,right? Is there anything else?It needs to produce the same result variables and also respond tothe old "input" variables (like find_ command cached results) thatthe old module did. That way existing build scripts can continueto work.This is something I should now check deeper. Is it an option to call it FindMatlab2 ?+# *
Re: [cmake-developers] [CPack] Call for volunteer for CPackRPM, CPackDeb maintenance.
Hello, I have been talking with Eric for the past few days now and would also like to help out with maintaining these two modules. I am a CMake user for about six years now and have also been using CPackRPM but for now I haven no experience with CPackDeb. As suggested by Eric I'll start with issue tracker: http://public.kitware.com/Bug/view.php?id=13176 Regards, Domen 2014-10-13 20:00 GMT+02:00 Brad King brad.k...@kitware.com: On 10/13/2014 01:36 PM, Micha Hergarden wrote: With this mail I would like to help out maintaining these modules. Wonderful, thanks! To others: this does not close the call. We can have more than one maintainer with overlapping responsibilities. Micha, please start by taking a look at the proposal here: [PATCH] Preinstall requirements support for CPack RPM generator http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/11235/focus=11253 and the corresponding issue tracker entry: CPackRPM: need CPACK_RPM_Component_PACKAGE_PRE/POST_REQUIRES http://www.cmake.org/Bug/view.php?id=14769 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 -- 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] [CPack] Call for volunteer for CPackRPM, CPackDeb maintenance.
On 10/13/2014 03:51 PM, Domen Vrankar wrote: would also like to help out with maintaining these two modules. Thanks for volunteering too! As suggested by Eric I'll start with issue tracker: http://public.kitware.com/Bug/view.php?id=13176 Sounds good! 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] fix-OSX-bundle-rpaths-and-Qt5 topic
Side note: this is not a fair characterization of Qt's support for CMake. (…) Furthermore, all the CMake-related files come with Qt5 and are maintained there rather than in CMake. This is much easier than Qt4, where FindQt4 in CMake has needed maintenance with every new upstream version. Of course it is great that THEY provide official CMake support. Maybe half-baked is a bit harsh, but everything goes smooth until you try to run your freshly compiled Qt5 app in on the any other machine that the one it was compiled on. First you realize you miss some Qt libraries you were linking to. Fine, fixup_bundle should do the job, but it doesn't. $ hello.app/Contents/MacOS/hello This application failed to start because it could not find or load the Qt platform plugin cocoa. Available platform plugins are: cocoa, minimal, offscreen. Reinstalling the application may fix this problem. The message isn't really helpful. Finally after seeking googling for an answer you find out that there are platform plugins and there is no function or module that will help you to bundle them and create proper qt.conf. So all apps that are willing to use Qt5 (not Qt4 legacy version) need to have that manually. This is why I call it half-baked. But to be fair, Qt team is really welcoming and open for improvements, I am sure complete support will arrive sooner or later. FYI I was working hard on relocatable Qt SDK for OSX for a while, it is almost complete. We were to release it for 5.4 but due some fancy testing suite problems probably this will be delayed. This was one of the reasons of my rpath support here. Otherwise once Qt SDK uses rpath it will immediately break CMake compatibility. --Adam -- 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] fix-OSX-bundle-rpaths-and-Qt5 topic
Adam Strzelecki wrote: But to be fair, Qt team is really welcoming and open for improvements, I am sure complete support will arrive sooner or later. As the person who wrote what Qt ships, I can say that it won't be 'complete' sooner or later unless someone with enough interest communicates/contributes what is missing. I don't have the requisite mac experience. I also think there might be a generic solution (or partial solution) to implement in CMake first (an interface for determining the package dependencies perhaps, etc). What makes this a Qt issue instead of a generic issue? Thanks, Steve. -- 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] [CPack] [CPackRPM] mantis ticket 13176 CPackRPM support for per-component summary and description
Hi, I extended the proposed patch for ticket 13176 with: - documentation section - CPACK_RPM_component_PACKAGE_DESCRIPTION fallback to CPACK_COMPONENT_compName_DESCRIPTION - handling of cases when one component sets its variable and the other doesn't 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
