[cmake-developers] [CMake 0015409]: FindOpenSSL does not find correct libraries with MinGW
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15409 == Reported By:David Demelier Assigned To: == Project:CMake Issue ID: 15409 Category: Modules Reproducibility:always Severity: major Priority: high Status: new == Date Submitted: 2015-02-18 03:52 EST Last Modified: 2015-02-18 03:52 EST == Summary:FindOpenSSL does not find correct libraries with MinGW Description: When using MinGW Generator, FindOpenSSL locate the following DLL as OPENSSL_LIBRARIES: C:\Program Files (x86)\CMake\bin\libeay32.dll C:\Program Files (x86)\CMake\bin\ssleay32.dll It indeed makes ld.exe crash since these are not import libraries. And OpenSSL built with mingw are named libssl.dll.a and libcrypto.dll.a. Steps to Reproduce: Use find_package(OpenSSL) with MinGW Generator. Ends with: -- Found OpenSSL: C:/Program Files (x86)/CMake/bin/ssleay32.dll;C:/Program Files (x86)/CMake/bin/libeay32.dll (found version 1.0.1h) == Issue History Date ModifiedUsername FieldChange == 2015-02-18 03:52 David Demelier 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] Introduction and volunteering for the Matlab package
Dear Brad,
I just tested the patch I sent you on OSX and Win32 and all the tests are clear.
Best,
Raffi Enficiaud
On 18 Feb 2015, at 01:28, Raffi Enficiaud raffi.enfici...@free.fr wrote:
Dear Brad,
Please find attached a patch addressing the issues mentioned in your email.
The tests were failing because of the following modification:
- matlab_get_version_from_matlab_run(${Matlab_MAIN_PROGRAM}
matlab_list_of_all_versions)
+ matlab_get_version_from_matlab_run(${Matlab_MAIN_PROGRAM}
matlab_list_of_all_versions)
Apparently the quotes here are interpreted as part of the binary name, which
prevents the proper call to matlab using the execute_process function.
I kept the symlink resolution, but I narrowed the case those should be
resolved. I added a variable pointing to the (symlink resolved) location of
the binary from which the version is retrieved. I compare paths symlink
resolved for that purpose. I hope this is in line with what you would like to
have.
Note that I only tested on LinuxLTS14.04 locally, I will test further
tomorrow morning.
I also changed the build path of the Windows agent, the build should be clear
on Windows now.
Best regards,
Raffi Enficiaud
0001-Addressing-the-visibility-of-the-internal-variables-.patch
On 13 Feb 2015, at 16:36, Brad King brad.k...@kitware.com wrote:
On 02/13/2015 09:43 AM, Raffi Enficiaud wrote:
* Why is Matlab_VERSION_STRING cached? Shouldn't it be computed
every time from the matlab that was found?
In case the version is not found with an obvious method
(on OSX /Applications/MATLABVersion, on Win32, the version also is
given by the registry key), we have to find the version of matlab
by running matlab itself. I am caching the version once I have it
to prevent any further execution of matlab for retrieving this
information.
Okay. Currently the value is user-facing, but it shouldn't ever be
edited manually, right? Instead the detected version could be cached
in an INTERNAL cache entry. Also there should be a second internal
entry that records which matlab program was executed to compute the
version. If the latter does not match then the version should be
re-computed.
In case a symlink of the binary called matlab exists in /usr/local/bin
for instance, I need to retrieve the path of the libraries mex, mx etc,
that are relative to the real installation path of matlab.
In that case I think you should look for those pieces relative to
the original executable location first, and if not found then
resolve symlinks into a temporary variable name and then use that.
The resolved path should not be made user-facing so that any user
that sets Matlab_MAIN_PROGRAM explicitly will see that value
persist.
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
[cmake-developers] [CMake 0015410]: Allow more characters in generator expression for config (dash, dot etc.)
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=15410
==
Reported By:peclik
Assigned To:
==
Project:CMake
Issue ID: 15410
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2015-02-18 17:13 EST
Last Modified: 2015-02-18 17:13 EST
==
Summary:Allow more characters in generator expression for
config (dash, dot etc.)
Description:
Currently probably [a-zA-Z_] set is allowed.
Other are needed too (dash, dot, hash etc.)
Probably now with cmake in UTF-8, even national chars could be allowed.
Steps to Reproduce:
Use generator $CONFIG:Release-Tests
Results in error Expression syntax not recognized.
E.g.
target_compile_definitions(tgt PRIVATE
$$CONFIG:Release-Tests:${PROJ_TESTS_DEFS})
==
Issue History
Date ModifiedUsername FieldChange
==
2015-02-18 17:13 peclik 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] Introduction and volunteering for the Matlab package
Please find attached the patch addressing the issues + some others, rebased
against 5dae6cf.
I tested it on the 3 target platforms.
patch.diff
Description: Binary data
On 18 Feb 2015, at 15:13, Brad King brad.k...@kitware.com wrote:
On 02/17/2015 07:28 PM, Raffi Enficiaud wrote:
The tests were failing because of the following modification:
- matlab_get_version_from_matlab_run(${Matlab_MAIN_PROGRAM}
matlab_list_of_all_versions)
+ matlab_get_version_from_matlab_run(${Matlab_MAIN_PROGRAM}
matlab_list_of_all_versions)
Apparently the quotes here are interpreted as part of the binary name,
which prevents the proper call to matlab using the execute_process function.
That should not be possible. The quotes are needed in case the variable
value is an empty string. They will not be treated as part of the value
passed to the function argument.
I restored the quotes. Maybe I experienced a caching issue: I run ctest with
FindMatlab regex, and from time to time the cache is messed while I am
working and I do not clean the folders systematically.
I kept the symlink resolution, but I narrowed the case those should be
resolved. I added a variable pointing to the (symlink resolved) location
of the binary from which the version is retrieved.
Yes, thanks.
I squashed the changes into 9d414ca2 and rebased again. Everything
so far is now in:
FindMatlab: Rewrite module and provide a usage API
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5dae6cfc
and merged to 'next' for testing. Please base fixes for the below
on that.
Couple of questions:
- does the script of the dashboard clean the folders? Or I have to do that
manually? (cf caching issues above)
- is it the next branch that is tested on the nightly section of the
dashboard?
More comments:
Why do you need so many different find_program calls for matlab?
There should be exactly one for Matlab_MAIN_PROGRAM, and it does
not need to be guarded by if(NOT Matlab_MAIN_PROGRAM) because
find_program does that already. Any symlink resolution can be
done on the result.
I wanted to separate the parts in some kind of modules.
- The first part is supposed to output the Matlab_ROOT and nothing else, and
the other parts are relying on that. Finding a matlab_program is an
implementation detail, which is not cross platform. Yet, the method is kind
of robust to find a proper installation ROOT.
- The second part deals with the version, in case we have no other way than
from asking Matlab. Since at this point, we have a ROOT, either given by the
user or from the first part, we search for the matlab program using this
information alone. In case the user gave the ROOT but not the version, we still
have to find the program under this ROOT. In case the user gave nothing, we
have to find the ROOT and the version, the former maybe implying a
matlab_program search. Again, I think this is an implementation detail that the
second part should not rely on.
- The third part is the user facing matlab_program, that we find on demand.
I agree this can be optimized in terms of find_program calls, but I would
like to keep this structure for finding in the appropriate sequence all the
information needed by the module.
The symlink resolutions are made on the appropriate places now.
The get_filename_component(PROGRAM) mode is intended to take a
command line string and figure out which leading piece is an
existing program in case it is an unquoted path with spaces.
While it may be a bug that this can return a directory, there
should be no use case for this functionality in FindMatlab.
I did not understood that from the documentation (the program in filename will
be found in the system search path): I thought it was another way of finding
programs. I removed the corresponding lines.
# list the keys under HKEY_LOCAL_MACHINE\SOFTWARE\mathworks but the call to
# reg does not work from cmake, curiously, as is. The command provides the
# desired result under the command line though.
# Fix: this is because /reg:64 should appended to the command, otherwise
# it gets on the 32 bits software key (curiously again)
This is because the default registry view depends on which reg
tool gets executed. These comments do not belong in the final
version of the module.
Yes, we exchanged on this point already. I removed the comments. Basically, at
some point I thought it would have been useful to use cmake as a make that can
run matlab commands through the matlab_program (and not obliged to link
anything to it). This is not possible in the current state of the module, but
would be possible readily in the future. BTW, I volunteered for the maintenance
of the module, so I guess these would be future extensions.
find_program(MATLAB_REG_EXE_LOCATION reg)
Many projects just execute_process() the reg tool directly
without finding it first. It is reliably available on Windows.
Ok, I made
[cmake-developers] [vc12/idl] output directory problem
hi all,
i'm having troubles with the midl compiler of generated msvc2013 project
files: the generated projects contain a hardcoded output directory:
$(IntDir). however having this property, the midl call fails for me. if
i remove this property, or replace it with $(ProjectDir)/$(IntDir) it
compiles fine.
attached patch resolves this issue for me, though i'm not sure if this
is a good solution in general. also, have to add this include directory:
${CMAKE_CURRENT_BINARY_DIR}/MyProject.dir/${CMAKE_CFG_INTDIR}
i'm not an expert on msvc toolchains, so it would be great if someone
could review this patch.
thanks,
tim
From a9f83bd54c8d7e073c4d8faee7e5b8dd68738fdc Mon Sep 17 00:00:00 2001
From: Tim Blechmann t...@klingt.org
Date: Thu, 19 Feb 2015 14:35:02 +0800
Subject: [PATCH] cmake: Midl - set OutputDir via absolute path
---
Source/cmVisualStudio10TargetGenerator.cxx | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Source/cmVisualStudio10TargetGenerator.cxx
b/Source/cmVisualStudio10TargetGenerator.cxx
index b265c0e..6c09702 100644
--- a/Source/cmVisualStudio10TargetGenerator.cxx
+++ b/Source/cmVisualStudio10TargetGenerator.cxx
@@ -2509,7 +2509,7 @@ WriteMidlOptions(std::string const /*config*/,
}
this-WriteString(%(AdditionalIncludeDirectories)
/AdditionalIncludeDirectories\n, 0);
- this-WriteString(OutputDirectory$(IntDir)/OutputDirectory\n, 3);
+
this-WriteString(OutputDirectory$(ProjectDir)/$(IntDir)/OutputDirectory\n,
3);
this-WriteString(HeaderFileName%(Filename).h/HeaderFileName\n, 3);
this-WriteString(
TypeLibraryName%(Filename).tlb/TypeLibraryName\n, 3);
--
2.3.0
--
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
On 02/17/2015 07:28 PM, Raffi Enficiaud wrote:
The tests were failing because of the following modification:
- matlab_get_version_from_matlab_run(${Matlab_MAIN_PROGRAM}
matlab_list_of_all_versions)
+ matlab_get_version_from_matlab_run(${Matlab_MAIN_PROGRAM}
matlab_list_of_all_versions)
Apparently the quotes here are interpreted as part of the binary name,
which prevents the proper call to matlab using the execute_process function.
That should not be possible. The quotes are needed in case the variable
value is an empty string. They will not be treated as part of the value
passed to the function argument.
I kept the symlink resolution, but I narrowed the case those should be
resolved. I added a variable pointing to the (symlink resolved) location
of the binary from which the version is retrieved.
Yes, thanks.
I squashed the changes into 9d414ca2 and rebased again. Everything
so far is now in:
FindMatlab: Rewrite module and provide a usage API
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5dae6cfc
and merged to 'next' for testing. Please base fixes for the below
on that.
More comments:
Why do you need so many different find_program calls for matlab?
There should be exactly one for Matlab_MAIN_PROGRAM, and it does
not need to be guarded by if(NOT Matlab_MAIN_PROGRAM) because
find_program does that already. Any symlink resolution can be
done on the result.
The get_filename_component(PROGRAM) mode is intended to take a
command line string and figure out which leading piece is an
existing program in case it is an unquoted path with spaces.
While it may be a bug that this can return a directory, there
should be no use case for this functionality in FindMatlab.
# list the keys under HKEY_LOCAL_MACHINE\SOFTWARE\mathworks but the call to
# reg does not work from cmake, curiously, as is. The command provides the
# desired result under the command line though.
# Fix: this is because /reg:64 should appended to the command, otherwise
# it gets on the 32 bits software key (curiously again)
This is because the default registry view depends on which reg
tool gets executed. These comments do not belong in the final
version of the module.
find_program(MATLAB_REG_EXE_LOCATION reg)
Many projects just execute_process() the reg tool directly
without finding it first. It is reliably available on Windows.
execute_process(
COMMAND ${matlab_binary_program} -nosplash -nojvm
${_matlab_additional_commands} -logfile
${_matlab_temporary_folder}/matlabVersionLog.cmaketmp -nodesktop -nodisplay
-r version, exit
OUTPUT_VARIABLE _matlab_version_from_cmd_dummy
RESULT_VARIABLE _matlab_result_version_call
TIMEOUT 30
)
This should quote ${matlab_binary_program} in case it is
empty for some reason. Also you should capture the stderr
output with ERROR_VARIABLE so it does not leak to the output
of the CMake configuration process.
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
