[cmake-developers] [CMake 0014641]: FindMatlab.cmake is outdated/broken
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=14641
==
Reported By:kentwilliams
Assigned To:
==
Project:CMake
Issue ID: 14641
Category: CMake
Reproducibility:always
Severity: major
Priority: normal
Status: new
==
Date Submitted: 2013-12-09 14:52 EST
Last Modified: 2013-12-09 14:52 EST
==
Summary:FindMatlab.cmake is outdated/broken
Description:
The current FindMatlab.cmake doesn't work very well in finding libraries and
important executables.
There is a version that originated in the Gerardus project
(https://code.google.com/p/gerardus/) that does a better job.
Steps to Reproduce:
find_package(MatLab REQUIRED)
if(NOT MATLAB_MEX_PATH)
message("MATLAB_MEX_PATH not found, you must not be using the new
FindMatlab.cmake")
endif()
Additional Information:
Attached file is what we use with some success.
==
Issue History
Date ModifiedUsername FieldChange
==
2013-12-09 14:52 kentwilliams New Issue
2013-12-09 14:52 kentwilliams File Added: FindMatlab.cmake
==
--
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 ExternalProject-independent-step-targets
On 12/09/2013 07:51 AM, Daniele E. Domenichelli wrote:
> And then adding an explicit dependency for each project that requires it
>
> add_dependency(${proj}-download SetupLocalXXXRepository)
...but again this requires the existing cases to be modified and
no longer tests that they work without this extra configuration.
By moving the new property test into a subdirectory or otherwise
making it not apply to the existing cases then that is not a problem.
However, the trouble you're having with Ninja still needs to be
solved because it could affect user projects (and a representative
case needs to be in the test too).
> AFAIK this should wait for SetupLocalXXXRepository to be finished
> before starting ${proj}-download
If both are logical CMake target names then that is the expected
behavior, yes. The Makefile, VS, and Xcode generators all work
by grouping individual shell actions and their dependencies into
separate logical targets that have high-level ordering dependencies.
The Ninja generator (by design) tries to have monolithic dependencies
for all the low-level rules because it is more efficient at build time.
IIUC it tries to connect up all the low-level rule dependencies to
simulate the target-ordering dependencies that CMake defines. Perhaps
that is not working here. I'm not intimately familiar with it though.
Can you reproduce the dependency ordering failure with a few simple
add_custom_command and add_custom_target calls and no ExternalProject
module? That will make it much easier to pin down, and the result
can be added to the general test suite (e.g. CustomCommand test) too.
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] Converting cmake_parse_arguments to a builtin command
On 12/06/2013 04:42 PM, Matthew Woehlke wrote: >> An advantage of keeping the name is that existing callers get the >> speed-up immediately. Furthermore there will be less code left in the >> old module to maintain. > > I think that is still true if the module just wraps the new function? Yes, I think so. Be sure that the wrapper forwards empty arguments correctly or the compatibility policy will not be meaningful ;) 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
[cmake-developers] [CMake 0014640]: PRIVATE linking with target_link_libraries propagates "usage requirements" for static libraries
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=14640 == Reported By:Arunmozhi Assigned To: == Project:CMake Issue ID: 14640 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2013-12-09 08:59 EST Last Modified: 2013-12-09 08:59 EST == Summary:PRIVATE linking with target_link_libraries propagates "usage requirements" for static libraries Description: I have projects in the structure shown below module (EXECUTABLE) | \-- submodule (STATIC_LIBRARY) | \-- subsubmodule (STATIC_LIBRARY) 'submodule' links with 'subsubmodule' using PRIVATE linking as below target_link_libraries(submodule PRIVATE subsubmodule) 'module' links with 'submodule'. It is expected that the 'module' does not get the public include directories of 'subsubmod'. However we see this happening in cmake 2.8.12. It is understood that the libraries linked with 'subsubmodule' are propagated to 'module' since 'subsubmodule' and 'submodule' are STATIC libraries. However this does not apply to the INCLUDE directories and COMPILE definitions. We also note that for SHARED libraries, the PRIVATE linking works fine. == Issue History Date ModifiedUsername FieldChange == 2013-12-09 08:59 Arunmozhi New Issue 2013-12-09 08:59 Arunmozhi File Added: example.tar == -- 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 ExternalProject-independent-step-targets
On 05/12/13 15:00, Brad King wrote:
> However, I do not like having to update all the existing calls
I'm trying to fix this, but I'm having some issues with ninja, and I
don't know anything about...
Instead of using
> +set_property(DIRECTORY PROPERTY EP_INDEPENDENT_STEP_TARGETS update)
> +INDEPENDENT_STEP_TARGETS ""
I'm trying to do
set_property(DIRECTORY PROPERTY EP_INDEPENDENT_STEP_TARGETS download update)
And then adding an explicit dependency for each project that requires it
add_dependency(${proj}-download SetupLocalXXXRepository)
AFAIK this should wait for SetupLocalXXXRepository to be finished
before starting ${proj}-download, and it seems to be working using
Unix Makefiles, but for some reason it does not work as expected
with Ninja generator...
Having a look at the build.ninja file, for each proj there is
something like this:
#
# Utility command for ${proj}-download
build ${proj}-download: phony CMakeFiles/${proj}-download
CMakeExternals/Stamp/${proj}/${proj}-download
CMakeExternals/Stamp/${proj}/${proj}-mkdir SetupLocalXXXRepository
#
# Phony custom command for CMakeFiles/${proj}-download
build CMakeFiles/${proj}-download: phony
CMakeExternals/Stamp/${proj}/${proj}-download || SetupLocalXXXRepository
#
# Custom command for CMakeExternals/Stamp/${proj}/${proj}-download
build CMakeExternals/Stamp/${proj}/${proj}-download: CUSTOM_COMMAND <...>
COMMAND = && /cmake -E touch
/Tests/ExternalProject/CMakeExternals/Stamp/${proj}/${proj}-download
DESC =
Do you know why this isn't working? Am I missing something?
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
