[cmake-developers] [CMake 0015959]: Using CMake-Gui to run generate for Windows followed by generate for Unix generates incorrect Unix makefiles
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15959 == Reported By:Jon Kristensen Assigned To: == Project:CMake Issue ID: 15959 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2016-02-08 02:56 EST Last Modified: 2016-02-08 02:56 EST == Summary:Using CMake-Gui to run generate for Windows followed by generate for Unix generates incorrect Unix makefiles Description: Running a generator that uses the Windows Shell, and then running a generator that uses the Unix shell without exiting Cmake-gui first, causes the Unix makefiles to have the wrong shell command (SHELL = cmd.exe) and Windows path names (with ‘\’s instead of ‘/’s). Steps to Reproduce: 1. Start cmake-gui 2. Select a project that uses the Visual Studio 2015 generator and run generate 3. Select a project that uses the CDT4 – Unix makefiles and run generate Additional Information: Assumed cause (based on cmake-3.4.3 source distribution) : The selection of shell seems to be based on the variable cmState::windowsShell This variable is set to false in the cmState constructor, and is set to true (through a call to member SetWindowsShell(true) from all generators that use a Windows shell. But I could find no code that resets it if a non-Windows-Shell generator is run at a later time == Issue History Date ModifiedUsername FieldChange == 2016-02-08 02:56 Jon Kristensen 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] Visual Studio 2015 Makefile Project (GDB)
I did some experiments, and I think it's a bit easier than I thought. I
don't think I need to generate the linux makefile from the Visual Studio
generator on windows. I would just add few new cmake options for the Visual
Studio GDB project type and among those the "build command" option.
And as a user, in the build command option, I can simply execute a script
on the target which calls cmake there to generate the makefile and then
call make.
On Sun, Feb 7, 2016 at 4:01 PM, Cedric Perthuis
wrote:
> Hi,
>
> Visual studio has a new interesting extension which adds the project type
> "Makefile Project (GDB)".
>
> I am interested in exploring adding this project type to cmake, and
> probably to the Visual Studio 2015 generator.
>
> It's used to build and debug a program using GDB over an SSH connection,
> it's mainly targeted at developing Linux programs from the Visual Studio
> IDE. It doesn't include the build, it only hooks the build command of VS to
> a user defined windows command. Up to that command to use SSH to execute
> code on the target.
>
> It's a VS 2015 NMake project type with 3 config files for build command,
> run command, and SSH parameters. Some of the interesting parts of the
> vcxproj
>
>
> LinuxDebugger
> ssh
> gdb
> gdb
> {8E0AD268-B47B-4ED3-B9E0-F93E5CB1077B}
>
>
> Label="Configuration">
> Makefile
> true
> v140
>
>
>
>
> false
> false
> <_ApplicableDebuggers>Desktop
> LinuxDebugger
>
>
> And the 3 config files:
>
>
>
>
>
>
> Neither the project nor the config files include any source file (I am
> sure we can add cpp files but they won't be associated with any compiler).
> The project has slots for build and debug command. As a user you have to
> write a build command which transfers of sources via SSH and do the
> compilation yourself.
>
> Here's an example of build command that the user can use
>
> build.bat $(RemoteHostName) $(RemoteUserName) $(PrivateKey)
> $(SecureShellExecutable) $(RemoteWorkingDirectory) $(RemoteExecutable)
>
> The build.bat would be something along those lines:
> "%SecureShellExecutable%" %RemoteUserName%@%RemoteHostName% -i
> "%PrivateKey%" "mkdir -p %RemoteWorkingDirectory%"
> "%SecureShellCopy%" -i "%PrivateKey%" source.cpp %RemoteUserName%@
> %RemoteHostName%:%RemoteWorkingDirectory%/source.cpp
> "%SecureShellExecutable%" %RemoteUserName%@%RemoteHostName% -i
> "%PrivateKey%" "cd %RemoteWorkingDirectory%;g++ -g source.cpp -o
> %RemoteExecutable%"
>
> Adding a generator for this is probably straightforward, but to respect
> the format of the other cmake (and make it easier for the developer), I
> think it should go further and also generate a linux makefile.
>
> - the vs2015 generator can be augmented to create this new project type
> - the linux makefile can already be generated from the makefile generator.
>
> My question is what would be a good way to combine those 2. I was thinking
> of trying to invoke the makefile generator from the vs2015 generator?
>
> Any thoughts or advice?
>
> Thanks,
> Cedric
>
>
>
>
>
>
--
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] Visual Studio 2015 Makefile Project (GDB)
Hi,
Visual studio has a new interesting extension which adds the project type
"Makefile Project (GDB)".
I am interested in exploring adding this project type to cmake, and
probably to the Visual Studio 2015 generator.
It's used to build and debug a program using GDB over an SSH connection,
it's mainly targeted at developing Linux programs from the Visual Studio
IDE. It doesn't include the build, it only hooks the build command of VS to
a user defined windows command. Up to that command to use SSH to execute
code on the target.
It's a VS 2015 NMake project type with 3 config files for build command,
run command, and SSH parameters. Some of the interesting parts of the
vcxproj
LinuxDebugger
ssh
gdb
gdb
{8E0AD268-B47B-4ED3-B9E0-F93E5CB1077B}
Makefile
true
v140
false
false
<_ApplicableDebuggers>Desktop
LinuxDebugger
And the 3 config files:
Neither the project nor the config files include any source file (I am sure
we can add cpp files but they won't be associated with any compiler). The
project has slots for build and debug command. As a user you have to write
a build command which transfers of sources via SSH and do the compilation
yourself.
Here's an example of build command that the user can use
build.bat $(RemoteHostName) $(RemoteUserName) $(PrivateKey)
$(SecureShellExecutable) $(RemoteWorkingDirectory) $(RemoteExecutable)
The build.bat would be something along those lines:
"%SecureShellExecutable%" %RemoteUserName%@%RemoteHostName% -i
"%PrivateKey%" "mkdir -p %RemoteWorkingDirectory%"
"%SecureShellCopy%" -i "%PrivateKey%" source.cpp %RemoteUserName%@
%RemoteHostName%:%RemoteWorkingDirectory%/source.cpp
"%SecureShellExecutable%" %RemoteUserName%@%RemoteHostName% -i
"%PrivateKey%" "cd %RemoteWorkingDirectory%;g++ -g source.cpp -o
%RemoteExecutable%"
Adding a generator for this is probably straightforward, but to respect the
format of the other cmake (and make it easier for the developer), I think
it should go further and also generate a linux makefile.
- the vs2015 generator can be augmented to create this new project type
- the linux makefile can already be generated from the makefile generator.
My question is what would be a good way to combine those 2. I was thinking
of trying to invoke the makefile generator from the vs2015 generator?
Any thoughts or advice?
Thanks,
Cedric
--
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 0015958]: ctest FTP failure
The following issue has been SUBMITTED. == https://public.kitware.com/Bug/view.php?id=15958 == Reported By:Orion Poplawski Assigned To: == Project:CMake Issue ID: 15958 Category: CTest Reproducibility:have not tried Severity: minor Priority: normal Status: new == Date Submitted: 2016-02-07 17:53 EST Last Modified: 2016-02-07 17:53 EST == Summary:ctest FTP failure Description: See https://bugzilla.redhat.com/show_bug.cgi?id=1305310 332: Expected stderr to match: 332: 332:expect-err> Error message was: ([Cc]ould *n.t resolve host:? '?-no-site-'?|The requested URL returned error:.*) 332:expect-err>Problems when submitting via FTP 332: 332: Actual stderr: 332: 332:actual-err>Error when uploading file: /home/bob/rpmbuild/BUILD/cmake-3.4.3/build/Tests/RunCMake/ctest_submit/FailDrop-ftp-build/Testing/20160206-1516/Configure.xml 332:actual-err>Error message was: Could not resolve host: -no-site-; Name or service not known 332:actual-err>Problems when submitting via FTP Additional Information: diff -urt cmake-3.4.3-orig/Tests/RunCMake/ctest_submit/CDashSubmitQuiet-stderr.txt cmake-3.4.3/Tests/RunCMake/ctest_submit/CDashSubmitQuiet-stderr.txt --- cmake-3.4.3-orig/Tests/RunCMake/ctest_submit/CDashSubmitQuiet-stderr.txt 2016-01-25 17:57:22.0 +0100 +++ cmake-3.4.3/Tests/RunCMake/ctest_submit/CDashSubmitQuiet-stderr.txt 2016-02-06 15:52:14.309214430 +0100 @@ -1,3 +1,3 @@ *Error when uploading file: .*/Configure.xml - *Error message was: ([Cc]ould *n.t resolve host:? '?-no-site-'?|The requested URL returned error:.*) + *Error message was: ([Cc]ould *n.t resolve host:? '?-no-site-'?.*|The requested URL returned error:.*) *Problems when submitting via HTTP diff -urt cmake-3.4.3-orig/Tests/RunCMake/ctest_submit/FailDrop-ftp-stderr.txt cmake-3.4.3/Tests/RunCMake/ctest_submit/FailDrop-ftp-stderr.txt --- cmake-3.4.3-orig/Tests/RunCMake/ctest_submit/FailDrop-ftp-stderr.txt 2016-01-25 17:57:22.0 +0100 +++ cmake-3.4.3/Tests/RunCMake/ctest_submit/FailDrop-ftp-stderr.txt 2016-02-06 16:20:06.557615425 +0100 @@ -1,2 +1,2 @@ -Error message was: ([Cc]ould *n.t resolve host:? '?-no-site-'?|The requested URL returned error:.*) +Error message was: ([Cc]ould *n.t resolve host:? '?-no-site-'?.*|The requested URL returned error:.*) Problems when submitting via FTP diff -urt cmake-3.4.3-orig/Tests/RunCMake/ctest_submit/FailDrop-https-stderr.txt cmake-3.4.3/Tests/RunCMake/ctest_submit/FailDrop-https-stderr.txt --- cmake-3.4.3-orig/Tests/RunCMake/ctest_submit/FailDrop-https-stderr.txt 2016-01-25 17:57:22.0 +0100 +++ cmake-3.4.3/Tests/RunCMake/ctest_submit/FailDrop-https-stderr.txt 2016-02-06 16:19:54.332442544 +0100 @@ -1,2 +1,2 @@ -Error message was: ([Cc]ould *n.t resolve host:? '?-no-site-'?|The requested URL returned error:.*|Protocol "https" not supported or disabled in .*|.* was built with SSL disabled.*) +Error message was: ([Cc]ould *n.t resolve host:? '?-no-site-'?.*|The requested URL returned error:.*|Protocol "https" not supported or disabled in .*|.* was built with SSL disabled.*) Problems when submitting via HTTP diff -urt cmake-3.4.3-orig/Tests/RunCMake/ctest_submit/FailDrop-http-stderr.txt cmake-3.4.3/Tests/RunCMake/ctest_submit/FailDrop-http-stderr.txt --- cmake-3.4.3-orig/Tests/RunCMake/ctest_submit/FailDrop-http-stderr.txt 2016-01-25 17:57:22.0 +0100 +++ cmake-3.4.3/Tests/RunCMake/ctest_submit/FailDrop-http-stderr.txt 2016-02-06 16:19:17.430908893 +0100 @@ -1,2 +1,2 @@ -Error message was: ([Cc]ould *n.t resolve host:? '?-no-site-'?|The requested URL returned error:.*) +Error message was: ([Cc]ould *n.t resolve host:? '?-no-site-'?.*|The requested URL returned error:.*) Problems when submitting via HTTP == Issue History Date ModifiedUsername FieldChange == 2016-02-07 17:53 Orion PoplawskiNew 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/c
[cmake-developers] [CMake 0015957]: cmake-gui.1 man page should not be installed unless --qt-gui is given
The following issue has been SUBMITTED. == https://public.kitware.com/Bug/view.php?id=15957 == Reported By:Orion Poplawski Assigned To: == Project:CMake Issue ID: 15957 Category: CMake Reproducibility:always Severity: trivial Priority: normal Status: new == Date Submitted: 2016-02-07 17:45 EST Last Modified: 2016-02-07 17:45 EST == Summary:cmake-gui.1 man page should not be installed unless --qt-gui is given Description: cmake-gui.1 man page should not be installed unless --qt-gui is given == Issue History Date ModifiedUsername FieldChange == 2016-02-07 17:45 Orion PoplawskiNew 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] [CMake 0015956]: TryCompile generation of cmake failed
The following issue has been SUBMITTED. == https://public.kitware.com/Bug/view.php?id=15956 == Reported By:davidk Assigned To: == Project:CMake Issue ID: 15956 Category: (No Category) Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2016-02-07 17:24 EST Last Modified: 2016-02-07 17:24 EST == Summary:TryCompile generation of cmake failed Description: CMake 3.1.3 fails to compile a project, but CMake 3.0 works well. It seems like the problem occurs when CMake tries to check the avaible compiler features. Yes, I have a working c/c++ compiler installed (gcc 5.3). I'm executing CMake with root privileges, so there shouldn't be any permission problems. Steps to Reproduce: Try to configure kdelibs4support (A KDE library) == Issue History Date ModifiedUsername FieldChange == 2016-02-07 17:24 davidk New Issue 2016-02-07 17:24 davidk File Added: CMakeError.log == -- 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] [PATCH] Help: fix mistake in cmake-buildsystem(7)
The COMPATIBLE_INTERFACE_NUMBER_MAX example now sets INTERFACE_CONTAINER_SIZE_REQUIRED on lib1Version2 and lib1Version3 (it previously set it on lib1Version2 twice and never on lib1Version3. Probably a copy-paste mistake?) --- Help/manual/cmake-buildsystem.7.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Help/manual/cmake-buildsystem.7.rst b/Help/manual/cmake-buildsystem.7.rst index 4a04f31..9004bb2 100644 --- a/Help/manual/cmake-buildsystem.7.rst +++ b/Help/manual/cmake-buildsystem.7.rst @@ -427,7 +427,7 @@ specified will be calculated: ) add_library(lib1Version3 SHARED lib1_v3.cpp) - set_property(TARGET lib1Version2 PROPERTY INTERFACE_CONTAINER_SIZE_REQUIRED 1000) + set_property(TARGET lib1Version3 PROPERTY INTERFACE_CONTAINER_SIZE_REQUIRED 1000) add_executable(exe1 exe1.cpp) # CONTAINER_SIZE_REQUIRED will be "200" -- 1.9.1 -- 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] Bug fix: Dylibs inside .framework folders fails in BundleUtilities.cmake.
> On 5. feb. 2016, at 16.22, Brad King wrote: > > On 02/04/2016 01:34 PM, Christian Askeland wrote: >> The specific cause is when e.g. >> >> /Library/Frameworks/GStreamer.framework/Versions/1.0/lib/libgio-2.0.0.dylib >> >> is detected by fixup_bundle. BundleUtilities.cmake/set_bundle_key_values() >> interprets this as a framework, thus doing a string replace that creates an >> embedded_item that is equal to the original path, i.e. it is not embedded. >> >> The fix is to rely on the correct framework detection in >> GetPrerequisite.cmake/gp_item_default_embedded_path() instead. > [snip] >> -if(item MATCHES "[^/]+\\.framework/") >> +# Use default_embedded_path from gp_item_default_embedded_path() to >> query whether the item is a framework >> +if(default_embedded_path MATCHES "/Frameworks") > > If the project uses gp_item_default_embedded_path_override then > we cannot rely on the value from gp_item_default_embedded_path. Good point, I didn't see that one. > Is there another way to detect whether the item is actually the > main framework library itself or just something else inside one? > We could reuse the check from gp_item_default_embedded_path(), instead of looking at the result from that function: if((item NOT MATCHES "\\.dylib$") AND (item MATCHES "[^/]+\\.framework/")) I haven't tested the line above, but can do so tomorrow and post a new patch, if it looks reasonable. > Thanks, > -Brad > -Christian -- 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
