[Cmake-commits] CMake branch, master, updated. v3.15.3-1008-g5bdff30
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 5bdff304847995f474797b757fe7a2755de0c1fb (commit) from b5b10c8e955abb2b0f18c3e41b7892471857bcc1 (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=5bdff304847995f474797b757fe7a2755de0c1fb commit 5bdff304847995f474797b757fe7a2755de0c1fb Author: Kitware Robot AuthorDate: Thu Sep 12 00:01:06 2019 -0400 Commit: Kitware Robot CommitDate: Thu Sep 12 00:01:06 2019 -0400 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index 0d48a72..fc86b56 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -1,7 +1,7 @@ # CMake version number components. set(CMake_VERSION_MAJOR 3) set(CMake_VERSION_MINOR 15) -set(CMake_VERSION_PATCH 20190911) +set(CMake_VERSION_PATCH 20190912) #set(CMake_VERSION_RC 0) set(CMake_VERSION_IS_DIRTY 0) --- 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] Packaging a directory with CPack RPM
Hello,
I'm using CPack to create RPMs for an application. I have this working but
the CPack step is quite slow. While investigating this, I noticed that all
files in a directory I'm packaging, which contains a large number of small
files, is being listed in the spec file.
For instance, say I have
set(CPACK_PACKAGING_INSTALL_PREFIX /opt/myapp)
install(DIRECTORY ${CMAKE_BINARY_DIR}/myapp/foo
DESTINATION foo
COMPONENT myapp
)
In the %files section I see
%files
%dir /opt/myapp/foo
" /opt/myapp/foo/file1"
" /opt/myapp/foo/file2"
...
" /opt/myapp/foo/file6"
If I were writing the spec file by hand, this entire section could be
replaced by a single line
%files
/opt/myapp/foo
RPM will package all files within the directory if you specify the
directory under %files (
http://ftp.rpm.org/max-rpm/s1-rpm-inside-files-list-directives.html - the
"The %dir Directive" section)
Is there an option to list just the directory instead of recursively
listing all contained files within the directory?
I'm not claiming this is the reason for CPack being slow, I came across
this while investigating performance and if nothing else, this will result
in a cleaner looking spec file.
Best regards,
Ashish.
--
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] Setting RPATH lookup on macOS
On 9/11/19, 5:42 PM, "Kyle Edwards" wrote:
On Wed, 2019-09-11 at 17:33 -0400, Michael Jackson wrote:
> Already looked on google and at the CMake documentation but
> everything listed does not seem to work so here is the setup.
>
> I am using MKL and I have a home grown FindMKL since there isn’t an
> official one. Inside that is the typical find_library() calls which
> will find the libraries just fine. One of those libraries is a
> dynamic library (.dylib). Using otool -L on that library the
> install_name is encoded as @rpath.
>
> Now I have my add_executable(foo…) and target_link_libraries (Foo
> ${MKL_LIBRARIES} ).
>
> Everything compiles and links fine. The issue is at runtime. The app
> will not launch because libmkl_rt.dylib is not loaded because the
> path to that library is not encoded into the executable.
>
> 639:[mjackson@ferb:ifort-release]$ otool -l
> Bin/EMsoftWorkbench.app/Contents/MacOS/EMsoftWorkbench | grep "path"
> name @rpath/libEbsdLib.dylib (offset 24)
> name @rpath/libmkl_rt.dylib (offset 24)
> name @rpath/QtOpenGL.framework/Versions/5/QtOpenGL (offset
> 24)
> name @rpath/QtNetwork.framework/Versions/5/QtNetwork (offset
> 24)
> name @rpath/QtConcurrent.framework/Versions/5/QtConcurrent
> (offset 24)
> name @rpath/QtWidgets.framework/Versions/5/QtWidgets (offset
> 24)
> name @rpath/QtGui.framework/Versions/5/QtGui (offset 24)
> name @rpath/QtCore.framework/Versions/5/QtCore (offset 24)
> path /Users/Shared/EMsoft_SDK-ifort/EbsdLib-0.1-Release/lib
> (offset 12)
> path /Users/Shared/EMsoft_SDK-
> ifort/Qt5.12.3/5.12.3/clang_64/lib (offset 12)
>
>
> Oddly the Qt libraries and one of my own libraries do get their
> rpaths encoded. I feel like I need to append to the RPATH that gets
> encoded into the executable but I am not really figuring out how to
> do that.
>
> Help
Have you looked at the BUILD_RPATH and INSTALL_RPATH properties?
https://cmake.org/cmake/help/latest/prop_tgt/BUILD_RPATH.html
https://cmake.org/cmake/help/latest/prop_tgt/INSTALL_RPATH.html
Kyle
Missed BUILD_RPATH property. Found every other
one THanks
--
Mike Jackson
--
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] Setting RPATH lookup on macOS
On Wed, 2019-09-11 at 17:33 -0400, Michael Jackson wrote:
> Already looked on google and at the CMake documentation but
> everything listed does not seem to work so here is the setup.
>
> I am using MKL and I have a home grown FindMKL since there isn’t an
> official one. Inside that is the typical find_library() calls which
> will find the libraries just fine. One of those libraries is a
> dynamic library (.dylib). Using otool -L on that library the
> install_name is encoded as @rpath.
>
> Now I have my add_executable(foo…) and target_link_libraries (Foo
> ${MKL_LIBRARIES} ).
>
> Everything compiles and links fine. The issue is at runtime. The app
> will not launch because libmkl_rt.dylib is not loaded because the
> path to that library is not encoded into the executable.
>
> 639:[mjackson@ferb:ifort-release]$ otool -l
> Bin/EMsoftWorkbench.app/Contents/MacOS/EMsoftWorkbench | grep "path"
> name @rpath/libEbsdLib.dylib (offset 24)
> name @rpath/libmkl_rt.dylib (offset 24)
> name @rpath/QtOpenGL.framework/Versions/5/QtOpenGL (offset
> 24)
> name @rpath/QtNetwork.framework/Versions/5/QtNetwork (offset
> 24)
> name @rpath/QtConcurrent.framework/Versions/5/QtConcurrent
> (offset 24)
> name @rpath/QtWidgets.framework/Versions/5/QtWidgets (offset
> 24)
> name @rpath/QtGui.framework/Versions/5/QtGui (offset 24)
> name @rpath/QtCore.framework/Versions/5/QtCore (offset 24)
> path /Users/Shared/EMsoft_SDK-ifort/EbsdLib-0.1-Release/lib
> (offset 12)
> path /Users/Shared/EMsoft_SDK-
> ifort/Qt5.12.3/5.12.3/clang_64/lib (offset 12)
>
>
> Oddly the Qt libraries and one of my own libraries do get their
> rpaths encoded. I feel like I need to append to the RPATH that gets
> encoded into the executable but I am not really figuring out how to
> do that.
>
> Help
Have you looked at the BUILD_RPATH and INSTALL_RPATH properties?
https://cmake.org/cmake/help/latest/prop_tgt/BUILD_RPATH.html
https://cmake.org/cmake/help/latest/prop_tgt/INSTALL_RPATH.html
Kyle
--
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
[CMake] Setting RPATH lookup on macOS
Already looked on google and at the CMake documentation but everything listed
does not seem to work so here is the setup.
I am using MKL and I have a home grown FindMKL since there isn’t an official
one. Inside that is the typical find_library() calls which will find the
libraries just fine. One of those libraries is a dynamic library (.dylib).
Using otool -L on that library the install_name is encoded as @rpath.
Now I have my add_executable(foo…) and target_link_libraries (Foo
${MKL_LIBRARIES} ).
Everything compiles and links fine. The issue is at runtime. The app will not
launch because libmkl_rt.dylib is not loaded because the path to that library
is not encoded into the executable.
639:[mjackson@ferb:ifort-release]$ otool -l
Bin/EMsoftWorkbench.app/Contents/MacOS/EMsoftWorkbench | grep "path"
name @rpath/libEbsdLib.dylib (offset 24)
name @rpath/libmkl_rt.dylib (offset 24)
name @rpath/QtOpenGL.framework/Versions/5/QtOpenGL (offset 24)
name @rpath/QtNetwork.framework/Versions/5/QtNetwork (offset 24)
name @rpath/QtConcurrent.framework/Versions/5/QtConcurrent (offset 24)
name @rpath/QtWidgets.framework/Versions/5/QtWidgets (offset 24)
name @rpath/QtGui.framework/Versions/5/QtGui (offset 24)
name @rpath/QtCore.framework/Versions/5/QtCore (offset 24)
path /Users/Shared/EMsoft_SDK-ifort/EbsdLib-0.1-Release/lib (offset 12)
path /Users/Shared/EMsoft_SDK-ifort/Qt5.12.3/5.12.3/clang_64/lib
(offset 12)
Oddly the Qt libraries and one of my own libraries do get their rpaths encoded.
I feel like I need to append to the RPATH that gets encoded into the executable
but I am not really figuring out how to do that.
Help
--
Michael Jackson | Owner, President
BlueQuartz Software
[e] mike.jack...@bluequartz.net
[w] www.bluequartz.net
--
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] Should header files be listed for a target?
On Mittwoch, 11. September 2019 21:22:04 CEST Kyle Edwards via CMake wrote: > On Wed, 2019-09-11 at 22:00 +0300, Avraham Shukron wrote: > > On Wed, Sep 11, 2019 at 9:49 PM Kyle Edwards > > > m> wrote: > > > You can list them or not list them. CMake will recognize them as > > > header > > > files and ignore them (not attempt to compile them.) It's a matter > > > of > > > personal preference. CMake's own CMake script lists them, but there > > > are > > > plenty of projects that don't and work just fine. > > > > And it far as IDE generators (Xcode, CodeBlocks etc) go - don't they > > care about headers? > > Yes, the headers are more important for IDE generators than they are > for Make/Ninja (though, AFAIK, they still don't affect the build, just > the files that the developer sees in the generated project in the IDE.) it depends. If you use e.g. the kate project generator, and your project is in svn or git, kate retrieves the full list of files via svn/git. Some generators check whether there is a foo.h in the same directory if there is a foo.cpp listed, and add this automatically. 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] Should header files be listed for a target?
On Wed, 2019-09-11 at 22:00 +0300, Avraham Shukron wrote: > > > On Wed, Sep 11, 2019 at 9:49 PM Kyle Edwards m> wrote: > > You can list them or not list them. CMake will recognize them as > > header > > files and ignore them (not attempt to compile them.) It's a matter > > of > > personal preference. CMake's own CMake script lists them, but there > > are > > plenty of projects that don't and work just fine. > And it far as IDE generators (Xcode, CodeBlocks etc) go - don't they > care about headers? Yes, the headers are more important for IDE generators than they are for Make/Ninja (though, AFAIK, they still don't affect the build, just the files that the developer sees in the generated project in the IDE.) Kyle -- 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] Should header files be listed for a target?
On Wed, Sep 11, 2019 at 9:49 PM Kyle Edwards wrote: > You can list them or not list them. CMake will recognize them as header > files and ignore them (not attempt to compile them.) It's a matter of > personal preference. CMake's own CMake script lists them, but there are > plenty of projects that don't and work just fine. And it far as IDE generators (Xcode, CodeBlocks etc) go - don't they care about headers? > > Another question - how does cmake know to create the > > dependency between the target and the header file, even when it is > > not listed explicitly? > > It uses GCC's -MD and -MF options (and the equivalents for other > compilers), which spits out the header dependency information. That is awesome. Thanks! -- 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] Should header files be listed for a target?
On Wed, 2019-09-11 at 21:40 +0300, Avraham Shukron wrote: > Hi! > > I'm pretty new to cmake and I came across a question which I could > not find any information about in the official documentation or blog > posts. > > When adding a target through add_library / add_executable - should > the header files of the target also be listed? > The question also applies to target_sources I guess. > > On one hand - as far as I can tell it compiles perfectly fine without > doing so, and the implicit dependency is also recognized (e.g if the > header changes - the target will be recompiled) > In addition most of the online examples do not list headers. > > On the other hand - it seems wrong not to list them. They ARE part of > the target, even if they do not passed to the compiler directly. > I can also assume that some IDEs will want to know about the > existence of these headers and their relationship with the target. > > So what is the correct answer? should header files be listed as part > of the target? You can list them or not list them. CMake will recognize them as header files and ignore them (not attempt to compile them.) It's a matter of personal preference. CMake's own CMake script lists them, but there are plenty of projects that don't and work just fine. > Another question - how does cmake know to create the > dependency between the target and the header file, even when it is > not listed explicitly? It uses GCC's -MD and -MF options (and the equivalents for other compilers), which spits out the header dependency information. Kyle -- 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
[CMake] Should header files be listed for a target?
Hi! I'm pretty new to cmake and I came across a question which I could not find any information about in the official documentation or blog posts. When adding a target through add_library / add_executable - should the header files of the target also be listed? The question also applies to target_sources I guess. On one hand - as far as I can tell it compiles perfectly fine without doing so, and the implicit dependency is also recognized (e.g if the header changes - the target will be recompiled) In addition most of the online examples do not list headers. On the other hand - it seems wrong not to list them. They ARE part of the target, even if they do not passed to the compiler directly. I can also assume that some IDEs will want to know about the existence of these headers and their relationship with the target. So what is the correct answer? should header files be listed as part of the target? Another question - how does cmake know to create the dependency between the target and the header file, even when it is not listed explicitly? -- 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
[Cmake-commits] CMake branch, master, updated. v3.15.3-1007-gb5b10c8
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 b5b10c8e955abb2b0f18c3e41b7892471857bcc1 (commit)
via 46629d6a49d8a12378778b39bc8827ae2808f3dd (commit)
via 30006e199bb6ac3649332b26c94ccf864e1416b1 (commit)
via 291c83f063d310f700e3e1afa756dcdf968d0f09 (commit)
via 8e973b8e8d6542b5dd15173884bde68a9a390949 (commit)
via 4d5bbb7704a44e56f43585b3f811f37c5200bdd0 (commit)
via 1f6a436bf4188007b87d2582367cde8f970d5e1f (commit)
via 5355a60fd02417a004c6b4b6b8848ce0ff1ea9fa (commit)
via cd7d7362782c2a582bcfd8a86a5523cf20ee6afb (commit)
via a20d2c85d02842a23ef1105daa078a821172cb4e (commit)
via b13207910e848d3c980e4b3dc176e113a3c04bbc (commit)
via ca7b90dcf2fc6ef5345de162ec2532454376fe2f (commit)
via eac8700c7853d88f0682492ccefc70b4246ccf4a (commit)
from 7f46e4a73a4d7aaa4029a04c532d2c99635383b9 (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=b5b10c8e955abb2b0f18c3e41b7892471857bcc1
commit b5b10c8e955abb2b0f18c3e41b7892471857bcc1
Merge: 46629d6 cd7d736
Author: Brad King
AuthorDate: Wed Sep 11 15:39:43 2019 +
Commit: Kitware Robot
CommitDate: Wed Sep 11 11:40:11 2019 -0400
Merge topic 'ctest-no-cmcommand'
cd7d736278 cmCTestTestHandler: Port away from cmCommand
Acked-by: Kitware Robot
Merge-request: !3795
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=46629d6a49d8a12378778b39bc8827ae2808f3dd
commit 46629d6a49d8a12378778b39bc8827ae2808f3dd
Merge: 7f46e4a 30006e1
Author: Brad King
AuthorDate: Wed Sep 11 15:38:40 2019 +
Commit: Kitware Robot
CommitDate: Wed Sep 11 11:38:58 2019 -0400
Merge topic 'fileapiAddMoreBacktraces'
30006e199b fileapi: add backtraces for compile/link options
291c83f063 cmLocalGenerator: Add GetTargetCompileFlags overload with
backtraces
8e973b8e8d cmLocalGenerator: Add GetTargetFlags overload with backtraces
4d5bbb7704 cmLocalGenerator: Add GetStaticLibraryFlags overload with
backtraces
1f6a436bf4 cmLocalGenerator: Add AddCompileOptions overload with backtraces
5355a60fd0 cmLocalGenerator: Add AppendCompileOptions overload with
backtraces
a20d2c85d0 cmLocalGenerator: Add AppendFlags overload with backtraces
b13207910e cmLocalGenerator: Clarify AddCompileOptions filter logic
...
Acked-by: Kitware Robot
Merge-request: !3775
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=30006e199bb6ac3649332b26c94ccf864e1416b1
commit 30006e199bb6ac3649332b26c94ccf864e1416b1
Author: Justin Goshi
AuthorDate: Tue Sep 3 10:25:44 2019 -0700
Commit: Brad King
CommitDate: Tue Sep 10 10:45:41 2019 -0400
fileapi: add backtraces for compile/link options
diff --git a/Source/cmFileAPICodemodel.cxx b/Source/cmFileAPICodemodel.cxx
index 3ac769c..805da81 100644
--- a/Source/cmFileAPICodemodel.cxx
+++ b/Source/cmFileAPICodemodel.cxx
@@ -802,9 +802,13 @@ void Target::ProcessLanguage(std::string const& lang)
{
// FIXME: Add flags from end section of ExpandRuleVariable,
// which may need to be factored out.
-std::string flags;
-lg->GetTargetCompileFlags(this->GT, this->Config, lang, flags);
-cd.Flags.emplace_back(std::move(flags), JBTIndex());
+std::vector> flags =
+ lg->GetTargetCompileFlags(this->GT, this->Config, lang);
+
+cd.Flags.reserve(flags.size());
+for (const BT& f : flags) {
+ cd.Flags.emplace_back(this->ToJBT(f));
+}
}
std::set> defines =
lg->GetTargetDefines(this->GT, this->Config, lang);
@@ -1264,7 +1268,7 @@ Json::Value Target::DumpLinkCommandFragments()
Json::Value linkFragments = Json::arrayValue;
std::string linkLanguageFlags;
- std::string linkFlags;
+ std::vector> linkFlags;
std::string frameworkPath;
std::string linkPath;
std::string linkLibs;
@@ -1275,7 +1279,6 @@ Json::Value Target::DumpLinkCommandFragments()
linkLanguageFlags, linkFlags, frameworkPath, linkPath,
this->GT);
linkLanguageFlags = cmTrimWhitespace(linkLanguageFlags);
- linkFlags = cmTrimWhitespace(linkFlags);
frameworkPath = cmTrimWhitespace(frameworkPath);
linkPath = cmTrimWhitespace(linkPath);
linkLibs = cmTrimWhitespace(linkLibs);
@@ -1286,8 +1289,11 @@ Json::Value Target::DumpLinkCommandFragments()
}
if (!linkFlags.empty()) {
-linkFragments.append(
- this->DumpCommandFragment(std::move(linkFlags), "flags"));
+for (BT frag : linkFlags) {
+ frag.Value = cmTrimWhitespace(frag.Value);
+ linkFragments.append(
+
