[Cmake-commits] CMake branch, master, updated. v3.14.0-rc1-74-g99ec095
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, master has been updated via 99ec095d9ddc6c2a8f073d38e14da66d1a245f80 (commit) from 9d2ab63aaf5fb29d812dbfc942da4d7671c5d1b3 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=99ec095d9ddc6c2a8f073d38e14da66d1a245f80 commit 99ec095d9ddc6c2a8f073d38e14da66d1a245f80 Author: Kitware Robot AuthorDate: Wed Feb 13 00:01:06 2019 -0500 Commit: Kitware Robot CommitDate: Wed Feb 13 00:01:06 2019 -0500 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index a4eb53f..e1284df 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -1,5 +1,5 @@ # CMake version number components. set(CMake_VERSION_MAJOR 3) set(CMake_VERSION_MINOR 14) -set(CMake_VERSION_PATCH 20190212) +set(CMake_VERSION_PATCH 20190213) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org https://cmake.org/mailman/listinfo/cmake-commits
[CMake] Cdash - Display Start Time in local time zone
Greetings,
I understand that start times are stored in UTC.
But I would like the Start Time column in the Dashboard window to
display those times in my local time zone of 'America/New York' or EST.
I have looked at the code in index.php, but I am not a php expert.
2) Running date in Ubuntu gets this: Tue Feb 12 21:47:16 EST 2019
So why is the CDash browser showing the current time in UTC? Wednesday,
February 13 2019 02:41:47.
I have my project nightly start time set to 00:00:01 EST.
Thanks in advance.
--
Donald [|]
A bad day in [] is better than a good day in {}.
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
--
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:
https://cmake.org/mailman/listinfo/cmake
Re: [CMake] OBJECT libraries getting fully support?
https://cmake.org/cmake/help/latest/release/3.12.html says that target_link_libraries got OBJECT in 3.12 - is that what you had in mind? -Mike > On Feb 12, 2019, at 3:35 PM, Paul Smith wrote: > > Don't want to be a noodge but wondering if anyone has any thoughts > about this question or ideas on how to solve my problem? > > > On Sat, 2019-02-09 at 12:29 -0500, Paul Smith wrote: >> Hi all; >> >> I saw an email to the list from Chuck Atkins in the summer of 2017 >> suggesting that OBJECT libraries were being enhanced and could become >> fully-functional libraries hopefully sometime that year. I'm wondering >> if that ever actally happened and if so what release of cmake it was >> in, and if not is there still a plan for this sometime? >> >> I'm trying to convert a large and complex cmake environment originally >> started in 2007 or so, which uses all old-school cmake facilities, to >> use modern cmake methods. >> >> I have a situation where we have a library containing basic methods >> which can be implemented multiple ways and different executables use >> different implementations. However these methods are used by all sorts >> of static libraries as well. >> >> Since we don't know until executable link time which library to use, >> the static libraries cannot depend on the base library: it has to be >> listed only in the executable's target_link_libraries. But of course >> because the static libraries use them as well we need the base library >> to be listed last (or near last) in the link line else we get undefined >> symbols. Adding the base library to the executable TLL doesn't allow >> us to do that. >> >> So I was thinking of making this base library an OBJECT library so it >> would always be fully linked but it seems that our version of cmake >> doesn't allow an OBJECT library to be used as a normal library and I'd >> be reduced to adding lots of generator expressions for it everywhere >> which is a huge PITA. >> >> Any ideas on how best to address this situation, if OBJECT libraries >> are not supported yet? > > -- > > 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: > https://cmake.org/mailman/listinfo/cmake -- 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: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] OBJECT libraries getting fully support?
Don't want to be a noodge but wondering if anyone has any thoughts about this question or ideas on how to solve my problem? On Sat, 2019-02-09 at 12:29 -0500, Paul Smith wrote: > Hi all; > > I saw an email to the list from Chuck Atkins in the summer of 2017 > suggesting that OBJECT libraries were being enhanced and could become > fully-functional libraries hopefully sometime that year. I'm wondering > if that ever actally happened and if so what release of cmake it was > in, and if not is there still a plan for this sometime? > > I'm trying to convert a large and complex cmake environment originally > started in 2007 or so, which uses all old-school cmake facilities, to > use modern cmake methods. > > I have a situation where we have a library containing basic methods > which can be implemented multiple ways and different executables use > different implementations. However these methods are used by all sorts > of static libraries as well. > > Since we don't know until executable link time which library to use, > the static libraries cannot depend on the base library: it has to be > listed only in the executable's target_link_libraries. But of course > because the static libraries use them as well we need the base library > to be listed last (or near last) in the link line else we get undefined > symbols. Adding the base library to the executable TLL doesn't allow > us to do that. > > So I was thinking of making this base library an OBJECT library so it > would always be fully linked but it seems that our version of cmake > doesn't allow an OBJECT library to be used as a normal library and I'd > be reduced to adding lots of generator expressions for it everywhere > which is a huge PITA. > > Any ideas on how best to address this situation, if OBJECT libraries > are not supported yet? -- 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: https://cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] Properly Documenting a CMake Module
Note: I have additionally posted this question to stack overflow so if you would like to answer there rather than email it may help a larger audience: https://stackoverflow.com/questions/54660549/what-is-the-proper-way-to-document-a-cmake-module On Tue, Feb 12, 2019 at 6:37 PM Timothy Wrona wrote: > A quick Google search (...actually many rather extensive Google searches) > have not been able to explain how to properly document a CMake module. > > What I'm looking for is a way to document custom CMake modules so that > they work with the "cmake --help-module " command. Is there > any standard way of doing this? Can anyone point me to some good examples? > The documentation process seems oddly not well documented. Haha. > > How are modules that work with "cmake --help-module" documented? > > Any help is appreciated. > > Thanks, > Tim > -- 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: https://cmake.org/mailman/listinfo/cmake-developers
[cmake-developers] Properly Documenting a CMake Module
A quick Google search (...actually many rather extensive Google searches) have not been able to explain how to properly document a CMake module. What I'm looking for is a way to document custom CMake modules so that they work with the "cmake --help-module " command. Is there any standard way of doing this? Can anyone point me to some good examples? The documentation process seems oddly not well documented. Haha. How are modules that work with "cmake --help-module" documented? Any help is appreciated. Thanks, Tim -- 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: https://cmake.org/mailman/listinfo/cmake-developers
Re: [CMake] [CMAKE] Disable testing when building using bootstrap
Hi Robert, thanks. That answers the question ! Cheers, JON HAITZ On Tue, Feb 12, 2019 at 1:24 PM Robert Maynard wrote: > > You can pass CMake arguments to the bootstrap by doing: > > ./bootstrap -- -DBUILD_TESTING=OFF > > On Mon, Feb 11, 2019 at 12:03 PM Jon Haitz Legarreta Gorroño > wrote: > > > > Hi, > > > > I'm trying to build CMake from sources using the `bootstrap` script. > > > > Please, correct me if I'm wrong, but it looks like CMake is being > > built with `BUILD_TESTING=ON` by default. > > > > I'd like to disable testing (and any other non-essential option), but > > AFAIK bootstrap does not expose the `-DBUILD_TESTING` flag, or I have > > not found a way to set it to `OFF`. > > > > Is this possible / does this make sense at all? Can anyone please > > provide me with the pointers to do so? > > > > Thank you, > > JON HAITZ > > -- > > > > 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: > > https://cmake.org/mailman/listinfo/cmake -- 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: https://cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] Fwd: [CMake] link only with targets feature
On 2019 M02 12, Tue 08:34:57 CET Timothy Wrona wrote: > I saw this email come through the cmake users mailing list but feel it is > more fitting for it to go to cmake-developers so I'm forwarding it here. > > It is a pretty long rant, but I think his idea to add a keyword to the > "target_link_libraries()" command that would only look for cmake targets is > a pretty great idea. I dont think it would break backwards compatibility > either. > > For example: > > target_link_libraries(mytarget > LINK_TARGETS > target1 > target1 > ) > > This would only search for CMake targets to link to and would not search > for libraries with the same name. It would make adding alias namespace to > targets not necessary anymore and would potentially make a lot of code look > cleaner. (I already replied on the cmake-list before I saw this here). I would prefer if this could be combined with the include-directories via linking feature. E.g. a command target_link_targets() which accepts only targets, and which has the include-directories features, and a policy to disable the include- directories via target_link_libraries(). Alex -- 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: https://cmake.org/mailman/listinfo/cmake-developers
Re: [CMake] link only with targets feature
On 2019 M02 12, Tue 08:02:43 CET Starka Tomáš wrote: > tldr; > It would be wonderful to have function or signature for > target_link_libraries tha would link only to a targets. Did I overlook > something? > > like target_link_libraries(name [PUBLIC...] TARGETS myFavouriteLib ... > QUIET/VERBOSE) > ... > But then I guess it wouldn't hurt to have something like > target_link_libraries(name [PUBLIC...] TARGETS myFavouriteLib ... > QUIET/VERBOSE) which would not try to give linker myFavouriteLib.lib > if there was no target of that name in question. Or > target_link_targets... realy doesn't matter as long as it does that > and maybe when asked by the last parameter it gives an error if the > one of the target is non-existent or ill-formed. I agree to target_link_targets(). Additionally I would prefer if (maybe with a policy) include directories would be only applied when using target_link_targets(), but not when using target_link_libraries(). This would make it more obvious IMO. Alex -- 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: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] [SPAM] Re: [SPAM] Re: resource installation
The same behavior is also present in version 3.14.0-rc1.
On 2/12/19, 11:54 AM, "CMake on behalf of Rob Boehne" wrote:
Hmmm, I think I've found a bug. Here is what I have in my top-level
CMakeLists.txt file:
if(WIN32)
#
# run the script to install the resources
#
set(RI_RESULT " ")
set(RI_OUTPUT " ")
set(RI_ERROR " ")
install(CODE "message(\"running
${CMAKE_CURRENT_SOURCE_DIR}/ResourceInstall.bat ${WIN_PLATFORM}
${CMAKE_BUILD_TYPE}\")")
install(CODE execute_process(COMMAND
${CMAKE_CURRENT_SOURCE_DIR}/ResourceInstall.bat ${WIN_PLATFORM}
${CMAKE_BUILD_TYPE}
RESULT_VARIABLE RI_RESULT
OUTPUT_VARIABLE RI_OUTPUT
ERROR_VARIABLE RI_ERROR
OUTPUT_FILE ResInst.out
ERROR_FILE ResInst.err )
)
install(CODE "message(\"ResourceInstall results \\\"${RI_RESULT}\\\"
output: \\\"${RI_OUTPUT}\\\" error: \\\"${RI_ERROR}\\\" \")")
endif()
(As you can see I haven't figured out quoting yet)
This is what comes out of the above code:
if("x${CMAKE_INSTALL_COMPONENT}x" STREQUAL "xUnspecifiedx" OR NOT
CMAKE_INSTALL_COMPONENT)
message("running
C:/Users/robb/Development/apdfl-sandbox/pdfl15_all/ResourceInstall.bat x64
Release")
endif()
if("x${CMAKE_INSTALL_COMPONENT}x" STREQUAL "xUnspecifiedx" OR NOT
CMAKE_INSTALL_COMPONENT)
execute_process(COMMAND
"C:/Users/robb/Development/apdfl-sandbox/pdfl15_all/ResourceInstall.bat x64
Release"
WORKING_DIRECTORY C:/Users/robb/Development/apdfl-sandbox/pdfl15_all
RESULT_VARIABLE RI_RESULT
OUTPUT_VARIABLE RI_OUTPUT
ERROR_VARIABLE RI_ERROR
OUTPUT_FILE ResInst.out
ERROR_FILE ResInst.err ")
endif()
if("x${CMAKE_INSTALL_COMPONENT}x" STREQUAL "xUnspecifiedx" OR NOT
CMAKE_INSTALL_COMPONENT)
message("ResourceInstall results output: error: ")
endif()
From cmake 3.12.2 on Win64. The issue is the closing quote inside
"execute_process" which appears to have been magically added by cmake.
When I run the cmake_install.cmake as is it fails on that line:
CMake Error at cmake_install.cmake:87:
Parse error. Function missing ending ")". Instead found unterminated
string with text ")
".
If I remove that stray double quote, it runs, doing all the subdir install
tasks, but still doesn't run the ResourceInstall.bat file.
And it generates the error:
1> -- Installing:
C:/Users/robb/Development/apdfl-sandbox/pdfl15_all/cmake_vs2013/../dist/x64/release/Resources/Sample_Input/XPStoPDF.xps
1>C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error
MSB3073: The command "setlocal
1>C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error
MSB3073: "C:\Program Files\CMake\bin\cmake.exe" -DBUILD_TYPE=RelWithDebInfo -P
cmake_install.cmake
1>C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error
MSB3073: if %errorlevel% neq 0 goto :cmEnd
1>C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error
MSB3073: :cmEnd
1>C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error
MSB3073: endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone
1>C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error
MSB3073: :cmErrorLevel
1>C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error
MSB3073: exit /b %1
1>C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error
MSB3073: :cmDone
1>C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error
MSB3073: if %errorlevel% neq 0 goto :VCEnd
1>C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error
MSB3073: :VCEnd" exited with code -1.
1>Done executing task "Exec" -- FAILED.
1>Done building target "PostBuildEvent" in project "INSTALL.vcxproj" --
FAILED.
1>
1>Build FAILED.
1>
1>Time Elapsed 00:00:29.40
== Build: 0 succeeded, 1 failed, 31 up-to-date, 0 skipped ==
I know the batch file does not get run because I have statements at the top
that create a file before anything else, and it also sends output to stdout.
Any advice on how I can move forward here?
Thanks,
Rob Boehne
On 2/5/19, 4:09 PM, "Robert Maynard" wrote:
If you add 'OUTPUT_VARIABLE' and 'ERROR_VARIABLE'
Re: [CMake] [CMAKE] Disable testing when building using bootstrap
You can pass CMake arguments to the bootstrap by doing: ./bootstrap -- -DBUILD_TESTING=OFF On Mon, Feb 11, 2019 at 12:03 PM Jon Haitz Legarreta Gorroño wrote: > > Hi, > > I'm trying to build CMake from sources using the `bootstrap` script. > > Please, correct me if I'm wrong, but it looks like CMake is being > built with `BUILD_TESTING=ON` by default. > > I'd like to disable testing (and any other non-essential option), but > AFAIK bootstrap does not expose the `-DBUILD_TESTING` flag, or I have > not found a way to set it to `OFF`. > > Is this possible / does this make sense at all? Can anyone please > provide me with the pointers to do so? > > Thank you, > JON HAITZ > -- > > 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: > https://cmake.org/mailman/listinfo/cmake -- 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: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] [SPAM] Re: resource installation
Hmmm, I think I've found a bug. Here is what I have in my top-level
CMakeLists.txt file:
if(WIN32)
#
# run the script to install the resources
#
set(RI_RESULT " ")
set(RI_OUTPUT " ")
set(RI_ERROR " ")
install(CODE "message(\"running
${CMAKE_CURRENT_SOURCE_DIR}/ResourceInstall.bat ${WIN_PLATFORM}
${CMAKE_BUILD_TYPE}\")")
install(CODE execute_process(COMMAND
${CMAKE_CURRENT_SOURCE_DIR}/ResourceInstall.bat ${WIN_PLATFORM}
${CMAKE_BUILD_TYPE}
RESULT_VARIABLE RI_RESULT
OUTPUT_VARIABLE RI_OUTPUT
ERROR_VARIABLE RI_ERROR
OUTPUT_FILE ResInst.out
ERROR_FILE ResInst.err )
)
install(CODE "message(\"ResourceInstall results \\\"${RI_RESULT}\\\"
output: \\\"${RI_OUTPUT}\\\" error: \\\"${RI_ERROR}\\\" \")")
endif()
(As you can see I haven't figured out quoting yet)
This is what comes out of the above code:
if("x${CMAKE_INSTALL_COMPONENT}x" STREQUAL "xUnspecifiedx" OR NOT
CMAKE_INSTALL_COMPONENT)
message("running
C:/Users/robb/Development/apdfl-sandbox/pdfl15_all/ResourceInstall.bat x64
Release")
endif()
if("x${CMAKE_INSTALL_COMPONENT}x" STREQUAL "xUnspecifiedx" OR NOT
CMAKE_INSTALL_COMPONENT)
execute_process(COMMAND
"C:/Users/robb/Development/apdfl-sandbox/pdfl15_all/ResourceInstall.bat x64
Release"
WORKING_DIRECTORY C:/Users/robb/Development/apdfl-sandbox/pdfl15_all
RESULT_VARIABLE RI_RESULT
OUTPUT_VARIABLE RI_OUTPUT
ERROR_VARIABLE RI_ERROR
OUTPUT_FILE ResInst.out
ERROR_FILE ResInst.err ")
endif()
if("x${CMAKE_INSTALL_COMPONENT}x" STREQUAL "xUnspecifiedx" OR NOT
CMAKE_INSTALL_COMPONENT)
message("ResourceInstall results output: error: ")
endif()
From cmake 3.12.2 on Win64. The issue is the closing quote inside
"execute_process" which appears to have been magically added by cmake.
When I run the cmake_install.cmake as is it fails on that line:
CMake Error at cmake_install.cmake:87:
Parse error. Function missing ending ")". Instead found unterminated
string with text ")
".
If I remove that stray double quote, it runs, doing all the subdir install
tasks, but still doesn't run the ResourceInstall.bat file.
And it generates the error:
1> -- Installing:
C:/Users/robb/Development/apdfl-sandbox/pdfl15_all/cmake_vs2013/../dist/x64/release/Resources/Sample_Input/XPStoPDF.xps
1>C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error
MSB3073: The command "setlocal
1>C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error
MSB3073: "C:\Program Files\CMake\bin\cmake.exe" -DBUILD_TYPE=RelWithDebInfo -P
cmake_install.cmake
1>C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error
MSB3073: if %errorlevel% neq 0 goto :cmEnd
1>C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error
MSB3073: :cmEnd
1>C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error
MSB3073: endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone
1>C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error
MSB3073: :cmErrorLevel
1>C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error
MSB3073: exit /b %1
1>C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error
MSB3073: :cmDone
1>C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error
MSB3073: if %errorlevel% neq 0 goto :VCEnd
1>C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error
MSB3073: :VCEnd" exited with code -1.
1>Done executing task "Exec" -- FAILED.
1>Done building target "PostBuildEvent" in project "INSTALL.vcxproj" -- FAILED.
1>
1>Build FAILED.
1>
1>Time Elapsed 00:00:29.40
== Build: 0 succeeded, 1 failed, 31 up-to-date, 0 skipped ==
I know the batch file does not get run because I have statements at the top
that create a file before anything else, and it also sends output to stdout.
Any advice on how I can move forward here?
Thanks,
Rob Boehne
On 2/5/19, 4:09 PM, "Robert Maynard" wrote:
If you add 'OUTPUT_VARIABLE' and 'ERROR_VARIABLE' information to the
execute_process call you should be able to dump the information using
'message' and see if the execute_process is running.
On Tue, Jan 29, 2019 at 3:04 PM Rob Boehne wrote:
>
> I’m still not getting this script executed. I can copy the “message”
output and run it – and it does what I want, and I see it in
cmake_install.cmake – the message() and execute_process() calls are inside of
identical conditionals, but there’s no indication that it is
[cmake-developers] Fwd: [CMake] link only with targets feature
I saw this email come through the cmake users mailing list but feel it is more fitting for it to go to cmake-developers so I'm forwarding it here. It is a pretty long rant, but I think his idea to add a keyword to the "target_link_libraries()" command that would only look for cmake targets is a pretty great idea. I dont think it would break backwards compatibility either. For example: target_link_libraries(mytarget LINK_TARGETS target1 target1 ) This would only search for CMake targets to link to and would not search for libraries with the same name. It would make adding alias namespace to targets not necessary anymore and would potentially make a lot of code look cleaner. -- Forwarded message - From: Starka Tomáš Date: Tue, Feb 12, 2019, 2:17 AM Subject: [CMake] link only with targets feature To: tldr; It would be wonderful to have function or signature for target_link_libraries tha would link only to a targets. Did I overlook something? like target_link_libraries(name [PUBLIC...] TARGETS myFavouriteLib ... QUIET/VERBOSE) (*read with the voice of a child*) Dear CMake developers, dear Santa I wish you could make the mess of using "fake namespace" notation go away. I no longer know what to link to when i write find_package(myFavouriteLib). In cmake 2.6, 2.8 there was a set of variables, which you need to get from the FindmyFavouriteLib.cmake. Smart people used MYFAVOURITELIB_INCLUDE_DIR and MYFAVOURITELIB_LIBRARY. Well sometimes a plural but mostly just that. Then there came the targets. A really nice way of packing all the things together and then it mostly got even simpler - link to the same string you provided to the find_package. So myFavouriteLib or in case of having a COMPONENTS a 'componentName'. But some spooky people were constantly making mistakes about not checking their targets and so for the sake of the backward compatibility with the target_link_libraries someone brought a "fake namespace" to once again break the backward compatibility. Some of the libraries changed the string to link to again from myFavouriteLib to myFavouriteLib::myFavouriteLib (e.g. assimp, and thanks to my colleague for that, but their cmake config never really worked anyway) which is horribly long and now I need to change every cmake that uses it. Well in some cases I changed only the custom find module but since I can't effectively alias imported targets (that aren't globaly vissible, wtf) nor I could clone them (WH?, did I again overlook something) it was a hell and the code is unnecesserily long. But now once again I don't know what to link to when calling find_package. It could be anything from myFavouriteLib, myFavouriteLib::myFavouriteLib, myFavouriteLib::component, MFL::component, component, and more (glm, Qt, OpenSceneGraph...). The programmers (myself included) seldomly have a time to write a proper documentation for their libraries (like Qt or Java do) and moreover this goes for documenting their cmake behaviour. So I once again need to go through the code to realy find what to link to. What a mess. But then I guess it wouldn't hurt to have something like target_link_libraries(name [PUBLIC...] TARGETS myFavouriteLib ... QUIET/VERBOSE) which would not try to give linker myFavouriteLib.lib if there was no target of that name in question. Or target_link_targets... realy doesn't matter as long as it does that and maybe when asked by the last parameter it gives an error if the one of the target is non-existent or ill-formed. And maybe then after couple of years when the dusts settles (after otherwise great talk from Daniel Pfeifer on cppCon) we could see the cmakes that when you know the name of the library, you don't need to search throu the code to find what you are supposed to link to like glm. Eventhough this doesn't look like it, it is just a short 'story' to pinpoint, from my perspective, one of the biggest flaw in one great configuration system. There could be done lot of the arguments for every thing I mentioned and lot's of problems that I for sake of simplicity didn't. After 10 years of using cmake and couple of years of trying to teach it to people that knows only a makefile and sometimes a bit about MSVC I came across a lot. And for me this class of problems boils down to the inconsistency between the find_package call and what you get from it. I now that it is great, that librety of doing what ever you want in that config script, but... Hope I don't spark a flame war about the naming conventions. I would like this proposal to be calmly considered. In best case just say that I'm an idiot and there is exactly that feature since 3.x.x. Best regards forry -- 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
[Cmake-commits] CMake branch, release, updated. v3.14.0-rc1-16-ga251b61
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, release has been updated via a251b61181252eb380d24778cdd8224ea7198eef (commit) via 572b4fd85b5987858ee6ce6fd7381c3cfd6720e9 (commit) via 3ff5a43c499c74715a282e782f4191d4420c9c73 (commit) via 40176749bc2243adb4acc8c53c902f6c349da24b (commit) via 633b3145c0e4d918f53272dab3358867bc252b0b (commit) via 6725975bd8c47c7817a286ada9eadb9b0fbf324c (commit) from 9e309cd4f0266144f269cab9006b51c252e25380 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - --- Summary of changes: Help/command/if.rst | 2 +- Modules/FindMatlab.cmake | 4 ++-- Modules/FindOctave.cmake | 14 +- Tests/FindOctave/Test/CMakeLists.txt | 4 Tests/FindOctave/Test/interp_main.cpp | 26 ++ 5 files changed, 46 insertions(+), 4 deletions(-) create mode 100644 Tests/FindOctave/Test/interp_main.cpp hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org https://cmake.org/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.14.0-rc1-73-g9d2ab63
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, master has been updated via 9d2ab63aaf5fb29d812dbfc942da4d7671c5d1b3 (commit) via 20afd497c92f66883de5dae92e2105c2f0cb4f70 (commit) via a7a85719332b5be90bb9ce1f3707a767197566c0 (commit) via c0ba467d2de9b6af7bd1657c73eb0638f1d2c89c (commit) via 336300d53003d2ec135d302acfdd1827062a05a6 (commit) via f468c0e1b98389fde7df2baccdc3815171a47a35 (commit) via 9e34f11b3604269c8c4f98bbcf237daeca9eaa2c (commit) via f0a57d42a2b0309c14615b7a9572f611ddda435e (commit) via a251b61181252eb380d24778cdd8224ea7198eef (commit) via 572b4fd85b5987858ee6ce6fd7381c3cfd6720e9 (commit) via 3ff5a43c499c74715a282e782f4191d4420c9c73 (commit) via 40176749bc2243adb4acc8c53c902f6c349da24b (commit) via 950c099d83757acd57cec78a3579ea1f6aaddf96 (commit) via 091afa7342e6c093f404b4777b81313535d73435 (commit) via 006768903cb6586098218822129d622737848299 (commit) via d625dfcdf9ad36802d0615cd929dd5c407a46524 (commit) via 633b3145c0e4d918f53272dab3358867bc252b0b (commit) via f6291eee251ec4fbc699ee63294057b0bc7016a4 (commit) via 948c55857e126825ce5f8282857d6970ba14e6bb (commit) via 6725975bd8c47c7817a286ada9eadb9b0fbf324c (commit) from 64ae72c52ac44984c9d5a23b19f4bd9dc9a68fdf (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9d2ab63aaf5fb29d812dbfc942da4d7671c5d1b3 commit 9d2ab63aaf5fb29d812dbfc942da4d7671c5d1b3 Merge: 20afd49 091afa7 Author: Brad King AuthorDate: Tue Feb 12 13:28:56 2019 + Commit: Kitware Robot CommitDate: Tue Feb 12 08:31:00 2019 -0500 Merge topic 'clangcl-fixes' 091afa7342 Tests: Teach tests when to treat clang-cl as MSVC 006768903c Work around clang-cl breakage on make_unique/std::forward d625dfcdf9 Avoid compiling CMake itself as C++17 with Clang's MSVC ABI Acked-by: Kitware Robot Merge-request: !2573 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=20afd497c92f66883de5dae92e2105c2f0cb4f70 commit 20afd497c92f66883de5dae92e2105c2f0cb4f70 Merge: a7a8571 950c099 Author: Brad King AuthorDate: Tue Feb 12 13:28:43 2019 + Commit: Kitware Robot CommitDate: Tue Feb 12 08:30:13 2019 -0500 Merge topic 'progress-stdstring' 950c099d83 cmake: Progress functions use `std::string` param Acked-by: Kitware Robot Merge-request: !2948 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a7a85719332b5be90bb9ce1f3707a767197566c0 commit a7a85719332b5be90bb9ce1f3707a767197566c0 Merge: c0ba467 f6291ee Author: Brad King AuthorDate: Tue Feb 12 13:28:32 2019 + Commit: Kitware Robot CommitDate: Tue Feb 12 08:29:08 2019 -0500 Merge topic 'modernize-cmCursesMainForm' f6291eee25 cmCursesMainForm: Modernize with STL and ranged-for loops Acked-by: Kitware Robot Merge-request: !2947 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c0ba467d2de9b6af7bd1657c73eb0638f1d2c89c commit c0ba467d2de9b6af7bd1657c73eb0638f1d2c89c Merge: 336300d 948c558 Author: Brad King AuthorDate: Tue Feb 12 13:28:17 2019 + Commit: Kitware Robot CommitDate: Tue Feb 12 08:28:24 2019 -0500 Merge topic 'cmCTestRunTest-compress' 948c55857e cmCTestRunTest: Remove duplicated compression logic Acked-by: Kitware Robot Merge-request: !2946 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=336300d53003d2ec135d302acfdd1827062a05a6 commit 336300d53003d2ec135d302acfdd1827062a05a6 Merge: f468c0e a251b61 Author: Brad King AuthorDate: Tue Feb 12 08:27:01 2019 -0500 Commit: Brad King CommitDate: Tue Feb 12 08:27:01 2019 -0500 Merge branch 'release-3.14' https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f468c0e1b98389fde7df2baccdc3815171a47a35 commit f468c0e1b98389fde7df2baccdc3815171a47a35 Merge: 9e34f11 4017674 Author: Brad King AuthorDate: Tue Feb 12 13:24:10 2019 + Commit: Kitware Robot CommitDate: Tue Feb 12 08:25:51 2019 -0500 Merge topic 'FindMatlab-version-empty' 40176749bc FindMatlab: Tolerate empty version log file Acked-by: Kitware Robot Merge-request: !2949 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9e34f11b3604269c8c4f98bbcf237daeca9eaa2c commit 9e34f11b3604269c8c4f98bbcf237daeca9eaa2c Merge: f0a57d4 572b4fd Author: Brad King AuthorDate: Tue Feb 12 13:24:18 2019 + Commit: Kitware Robot CommitDate: Tue Feb 12 08:24:59 2019 -0500 Merge topic 'doc-if-legacy' 572b4fd85b Help: Fix elseif/endif typo Acked-by: Kitware Robot
