Re: [cmake-developers] Was AUTOMOC designed to run for each build?
Alexander Neundorf wrote: >> I don't see why the target is executed each time, but is it that way by >> design? > > iirc, yes. > The moc files have to be generated before any of the source files is > compiled, so automoc is in a target the actual target depends on. > IIRC it is exclude_from_all so that it is only built when the actual > target is built. > Do you think it should only rerun if any of the source files has changed ? > There was some problem with this. > The headers are usually not part of the listed source files. Hmm, well, we do know which header is relevant right? Because it's the one (or many) we set up commands to run moc on. Maybe we only know the relevant headers too late (at the time of running the -E cmake_autogen command, not at cmake time)? Something else I've wondered is why the parsing of the files is done 'delayed' with the -E cmake_autogen command. Is it just to avoid doing that task during cmake time (because it's time consuming), and to allow parallelization? Thanks, Steve. -- 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] Extracting target metadata, IDE integration
Aleix Pol wrote: > Hi, > Here's another iteration of the patch [1]. Thanks for this. Can you tell me why exportName is part of the output? http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=11009 Thanks, Steve. -- 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] Extracting target metadata, IDE integration
Anton Makeev wrote: > Hey everyone, > > We are developing CLion at JetBrains that utilizes CMake as its main > project model. Stephen Kelly timely drew our attention to this discussion, > and I’d like to share some thoughts. Here are the general ones and I’ll > also comment on separate messages in the thread. Thanks! > * Location of every source file and target in CMakeLists > - it would greatly help to refactorings, navigation etc. Ok, that seems to already be part of the current design/implementation. > * Complete list of headers and resource files > - they are only listed in special generators like code blocks. That generator guesses that if foo.cpp is in the project and foo.h exists, then foo.h must also be part of the project: http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmExtraCodeBlocksGenerator.cxx;h=56a6edbb;hb=HEAD#l449 That might not be true, but you can probably make the same guess inside CLion anyway? > * An easily parseable list of errors and warnings with origin information. > At the moment we parse error output but not everything can be parsed > reliably. That non-reliability of parsing that stuff might be something to file bugs about. I think it's out of scope of the metadata file design. > * No progress indication. Since the generation may take several minutes, > providing feedback is crucial. There is feedback during the configure stage, and as the generation stage may take longer as of the last few releases, I have thought that showing some progress could be worthwhile. I haven't looked into it though. I filed http://public.kitware.com/Bug/view.php?id=15172 to track the idea. Again though, this is out of scope of the target metadata file. > * Ability to distinguish a library from an executable target. > This will help to offer a better UI for run/debug configurations. This is already part of the current design/implementation. > * Possibility to collect information for every build target in one run. > Currently, we have to invoke generator for every CMAKE_BUILD_TYPE > separately. This is part of the updated design. http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=11041 > * CMake stops processing when it find a missing file, so that IDE cannot > have > full project model, until this files is created. True. However, if cmake stops processing (because of a missing file or many other reasons, such as a missing dependency), the full project model is not known. I'm not sure this is 'fixable'. > * When there are existing in-source generated files in the project dir, > CMake doesn't allow generating into a separate out-of-source folder. > An IDE has to invent workarounds here. I'm not sure CMake can provide a better solution to this. Would you want to run cmake in a mode which clears out such files somehow? I'm not sure that would be accepted. > Here is why I think the discussed functionality should not be a separate > generator: I think that ship has sailed. The feature is being implemented with a variable for control, not a generator. Thanks for the feedback! Steve. -- 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 0015172]: Show progress during generation step
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15172 == Reported By:Stephen Kelly Assigned To: == Project:CMake Issue ID: 15172 Category: CMake Reproducibility:have not tried Severity: minor Priority: normal Status: new == Date Submitted: 2014-09-26 01:17 CEST Last Modified: 2014-09-26 01:17 CEST == Summary:Show progress during generation step Description: CMake gives a lot of output during the configure step, but no output during the generate step. As of the last few releases, CMake is doing more during the generation stage to resolve transitive build properties, which can take more time, so feedback could be more valuable. CMake could show more output during the multiple stages of cmGlobalGenerator::Generate quite easily, however, the granularity of that is only the directory level. For the granularity of generating for individual targets (if that is desirable/possible/practical), each of the concrete generators would need to be modified to produce output. The output would have to be the same for each generator so that it could be uniformly parsed. == Issue History Date ModifiedUsername FieldChange == 2014-09-26 01:17 Stephen Kelly 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
[cmake-developers] Support of codesign
Hi there,
I refactored the patches of Brian Milco to support code signing of bundles
in MacOS. As we don't need AppStore support at the moment we didn't added
the special generator for it. That could be a separate step later.
As long as it runs codesign only it should be trivial enough to add it. Is
it possible to add it to cmake 3.1?
Original commits are taken from github: https://github.com/iPenguin/cmake
Best regards
André Klitzing
From 2e2245942f9d30b4703f79584a2f48a801aac8ac Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andr=C3=A9=20Klitzing?=
Date: Thu, 25 Sep 2014 16:15:24 +0200
Subject: [PATCH] Add support for codesign on MacOS
Refactored patch of Brian Milco
https://github.com/iPenguin/cmake
---
Modules/CPackDMG.cmake | 24 ++
Source/CPack/cmCPackBundleGenerator.cxx| 18 -
Source/CPack/cmCPackBundleGenerator.h | 1 +
Source/CPack/cmCPackDragNDropGenerator.cxx | 114 +
Source/CPack/cmCPackDragNDropGenerator.h | 1 +
5 files changed, 157 insertions(+), 1 deletion(-)
diff --git a/Modules/CPackDMG.cmake b/Modules/CPackDMG.cmake
index b7a6ba5..fb9fe39 100644
--- a/Modules/CPackDMG.cmake
+++ b/Modules/CPackDMG.cmake
@@ -36,6 +36,23 @@
# background image is set. The background image is applied after applying the
# custom .DS_Store file.
#
+#
+#
+# .. variable:: CPACK_APPLE_CERT_APP
+# The name of your Apple supplied code signing certificate for the application.
+# The name usually takes the form "Developer ID Application: [Name]" or
+# "3rd Party Mac Developer Application: [Name]". If this variable is not set
+# the application will not be signed.
+#
+# .. variable:: CPACK_APPLE_ENTITLEMENTS
+# The name of the plist file that contains your apple entitlements for sandboxing
+# your application. This file is required for submission to the Mac App Store.
+#
+# .. variable:: CPACK_APPLE_CODESIGN_FILES
+# A list of additional files that you wish to be signed. You do not need to
+# list the main application folder, or the main executable. You should
+# list any frameworks and plugins that are included in your app bundle.
+#
# .. variable:: CPACK_COMMAND_HDIUTIL
#
# Path to the hdiutil(1) command used to operate on disk image files on Mac
@@ -54,6 +71,13 @@
# Path to the Rez(1) command used to compile resources on Mac OS X. This
# variable can be used to override the automatically detected command (or
# specify its location if the auto-detection fails to find it.)
+#
+# .. variable:: CPACK_COMMAND_CODESIGN
+# Path to the codesign(1) command used to sign applications with an
+# Apple cert. This variable can be used to override the automatically
+# detected command (or specify its location if the auto-detection fails
+# to find it.)
+#
#=
# Copyright 2006-2012 Kitware, Inc.
diff --git a/Source/CPack/cmCPackBundleGenerator.cxx b/Source/CPack/cmCPackBundleGenerator.cxx
index 6c994f1..c5f7139 100644
--- a/Source/CPack/cmCPackBundleGenerator.cxx
+++ b/Source/CPack/cmCPackBundleGenerator.cxx
@@ -53,7 +53,7 @@ const char* cmCPackBundleGenerator::GetPackagingInstallPrefix()
}
//--
-int cmCPackBundleGenerator::PackageFiles()
+int cmCPackBundleGenerator::ConstructAppBundle()
{
// Get required arguments ...
@@ -165,6 +165,22 @@ int cmCPackBundleGenerator::PackageFiles()
cmSystemTools::SetPermissions(command_target.str().c_str(), 0777);
}
+ return 1;
+}
+
+//--
+int cmCPackBundleGenerator::PackageFiles()
+{
+ if(!this->ConstructAppBundle())
+{
+return 0;
+}
+
+ if(!this->SignPackage(toplevel))
+{
+return 0;
+}
+
return this->CreateDMG(toplevel, packageFileNames[0]);
}
diff --git a/Source/CPack/cmCPackBundleGenerator.h b/Source/CPack/cmCPackBundleGenerator.h
index ed0187d..fa9f2fa 100644
--- a/Source/CPack/cmCPackBundleGenerator.h
+++ b/Source/CPack/cmCPackBundleGenerator.h
@@ -31,6 +31,7 @@ public:
protected:
virtual int InitializeInternal();
virtual const char* GetPackagingInstallPrefix();
+ int ConstructAppBundle();
int PackageFiles();
bool SupportsComponentInstallation() const;
diff --git a/Source/CPack/cmCPackDragNDropGenerator.cxx b/Source/CPack/cmCPackDragNDropGenerator.cxx
index 9f0a77e..b3041f1 100644
--- a/Source/CPack/cmCPackDragNDropGenerator.cxx
+++ b/Source/CPack/cmCPackDragNDropGenerator.cxx
@@ -103,6 +103,17 @@ int cmCPackDragNDropGenerator::InitializeInternal()
}
this->SetOptionIfNotSet("CPACK_COMMAND_REZ", rez_path.c_str());
+ const std::string codesign_path = cmSystemTools::FindProgram("codesign",
+std::vector(), false);
+ if(codesign_path.empty())
+{
+cmCPackLogger(cmCPackLog::LOG_ERROR,
+ "Cannot locate codesign command"
+ << std::endl);
+return 0;
+}
+ this->SetOptionIfNotS
Re: [cmake-developers] Extracting target metadata, IDE integration
On Thursday, September 25, 2014 07:14:38 Anton Makeev wrote: ... > Here is why I think the discussed functionality should not be a separate > generator: > > CLion doesn’t have it’s own project model nor is intended as build tool > replacement. Currently, the only option for CLion users is makefiles build, > that is not a best option for everyone: there is a good and fast > alternative ‘Ninja’. Ideally, users should be able to choose whatever tool > better suites them. > > The problem is that the generated Makefiles are used both, for internal > needs, like reading project structure, and also to build and run the user’s > program. If we wanted to support Ninja generator, we would need to rewrite > all the logic that retrieves the project information, using the files that > are created by Ninja generator. While I suppose it’s possible, it’s not the > best option - very error prone and resource demanding. > > If CMake generated a separate descriptor, regardless the generator used > (Makefiles, Ninja), it would be much easier to support; and the users will > benefit from better, more reliable and faster CMake integration in an IDE. not sure I fully understand, but it seems you are maybe not aware how the "extra generators" in cmake work. Those are basically run additionally to a "normal" generator. I.e. cmake generates makefiles or ninja files, and additionally project files for an IDE. This project file typically contains the list of targets, and for each target the build command. At that point it doesn't matter much anymore for the IDE whether the main generator is make or ninja. This is implemented with the Eclipse generator, the CodeBlocks generator and the Kate generator. They all write a project file for the IDE additionally to the makefiles/ninja files for the actual building. 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: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake] Windows rpath emulation
On 09/25/2014 03:17 PM, Brad King wrote:
Note that CMake now has a "cmake -E env" feature that could be
used in custom commands and tests to set PATH before launching
an executable.
I currently use CMake scripts as wrappers for custom commands which set
ENV{PATH} and the ENVIRONMENT property in tests.
I don't currently have anything to conveniently run binaries manually
from the build tree but I guess I could come up with something custom
for that as well without having to make this a first class feature.
It would just have been convenient having something more transparent and
without manual set up for every project given how common this seems.
Given the opposition I won't pursue this further.
Thanks.
Nils
--
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] stage/compact-status-log
On 09/25/2014 09:43 AM, Adam Strzelecki wrote: >> I think the delayed-\n approach is the simplest. In the >> case that the output is interrupted by other content it >> almost certainly means something is going wrong anyway. > > Does CMake use popen to launch processes? Or it just spawns > them providing them direct access to stdin/out/err? In Source/kwsys/Process.h.in there is an API for executing child processes. Most of CMake uses a RunSingleCommand method wrapping it up here: http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmSystemTools.cxx;hb=v3.0.2#l624 Some call sites share stdout/stderr and some do not. The execute_process() command is implemented with the KWSys Process API too, and that command has options for what to do with the pipes. As for the check message lines, I think it should be up to the check macro to ensure it does not invoke anything that could print intermediate output between the beginning of the line and the result of the check. -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
Re: [cmake-developers] [PATCH] stage/compact-status-log
> I think the delayed-\n approach is the simplest. In the > case that the output is interrupted by other content it > almost certainly means something is going wrong anyway. Does CMake use popen to launch processes? Or it just spawns them providing them direct access to stdin/out/err? If it was using popen then we can circumvent that too. --Adam -- 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] [CMake] Windows rpath emulation
On 09/25/2014 08:45 AM, Nils Gladitz wrote: > @Brad: Before I rush into implementing anything and given that David > already raised concerns ... would anything like this be considered for > merge into CMake? I'm not convinced it should be a builtin CMake feature. KWSys provides the "SharedForward" component specifically to help projects create launcher executables like this. It even helps create relocatable binaries on *NIX without $ORIGIN, and works for redistributable packages on both Windows and *NIX. All of this works without any special CMake features. While it would be nice to provide a helper for applications to do this, the only reason to include it in CMake would be to avoid an additional external dependency for the application. The same dependency management argument could be made for any library, and we can't include the world in CMake. > $ should continue to point at the real binary. > A new $ could point at the wrapper binary. The original purpose of $ was for add_custom_command and add_test to be able to refer to executables to run on command lines. That would have to be the wrapper for this use case. However, other use cases may want to pass the real binary with $. This makes the behavior of a magic wrapper hard to define in general, so it would be better to have application code manage the separate targets explicitly. Note that CMake now has a "cmake -E env" feature that could be used in custom commands and tests to set PATH before launching an executable. -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
Re: [cmake-developers] [CMake] Windows rpath emulation
@Brad: Before I rush into implementing anything and given that David already raised concerns ... would anything like this be considered for merge into CMake? Nils -- 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] Extracting target metadata, IDE integration
Hey everyone, We are developing CLion at JetBrains that utilizes CMake as its main project model. Stephen Kelly timely drew our attention to this discussion, and I’d like to share some thoughts. Here are the general ones and I’ll also comment on separate messages in the thread. We’ve managed to get almost all the necessary project information, using ‘GNU/MinGW Makefiles’ generators: * list of targets comes from 'CMakeFiles/TargetDirectories.txt' * list of source files from ‘CMakeFiles/A.dir/DependInfo.cmake’ * list of headers and resources from ‘codeblocks.cbp’ file * per-file/target compiler and its flags from ‘CMakeFiles/Target.dir/flags.make’ * location of product files from ‘CMakeFiles/Target.dir/build.make’ What we miss (not all of them are directly related the targets metadata, but I'd like to share anyway since the topic is about IDE integration): * Location of every source file and target in CMakeLists - it would greatly help to refactorings, navigation etc. * Complete list of headers and resource files - they are only listed in special generators like code blocks. * An easily parseable list of errors and warnings with origin information. At the moment we parse error output but not everything can be parsed reliably. * No progress indication. Since the generation may take several minutes, providing feedback is crucial. * Ability to distinguish a library from an executable target. This will help to offer a better UI for run/debug configurations. * Possibility to collect information for every build target in one run. Currently, we have to invoke generator for every CMAKE_BUILT_TYPE separately. * CMake stops processing when it find a missing file, so that IDE cannot have full project model, until this files is created. * When there are existing in-source generated files in the project dir, CMake doesn't allow generating into a separate out-of-source folder. An IDE has to invent workarounds here. * Not sure if it’s possible at all - a lightweight phase where CMake only collects necessary information (list of files/targets, compiler settings). This will help IDE react to the changes much faster. Here is why I think the discussed functionality should not be a separate generator: CLion doesn’t have it’s own project model nor is intended as build tool replacement. Currently, the only option for CLion users is makefiles build, that is not a best option for everyone: there is a good and fast alternative ‘Ninja’. Ideally, users should be able to choose whatever tool better suites them. The problem is that the generated Makefiles are used both, for internal needs, like reading project structure, and also to build and run the user’s program. If we wanted to support Ninja generator, we would need to rewrite all the logic that retrieves the project information, using the files that are created by Ninja generator. While I suppose it’s possible, it’s not the best option - very error prone and resource demanding. If CMake generated a separate descriptor, regardless the generator used (Makefiles, Ninja), it would be much easier to support; and the users will benefit from better, more reliable and faster CMake integration in an IDE. Regards, Anton Makeev -- 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
