[cmake-developers] [CMake 0016023]: OS X CMake.app (version 3.5) contains empty CFBundleIdentifier, which is malformed

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://public.kitware.com/Bug/view.php?id=16023 
== 
Reported By:Sean McBride
Assigned To:
== 
Project:CMake
Issue ID:   16023
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2016-03-17 15:43 EDT
Last Modified:  2016-03-17 15:43 EDT
== 
Summary:OS X CMake.app (version 3.5) contains empty
CFBundleIdentifier, which is malformed
Description: 
CMake.app's Info.plist contains:

CFBundleIdentifier


That entry isn't allowed to be empty.

I suggest a value like "org.cmake.cmake" or something.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-03-17 15:43 Sean McBride   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] more use of cmXMLWriter

[Konstantin Podsvirov]

Hi all! Hi Daniel!

Thank you for the work done.

I'm the developer CPack IFW generator.

I heard about cmXMLWriter and planned to use it,
but I couldn't find the time to do it.

I looked 0007-CPack-IFW-port-to-cmXMLWriter.patch and at first glance
everything should work as before, but I haven't conducted tests
on the real packs.

If I find the time to test, I will report about results here.

20.03.2016, 00:24, "Daniel Pfeifer" :
> Hi,
> I ported. some more generators to cmXMLWriter.
> cheers, Daniel

--
Regards,
Konstantin Podsvirov
-- 

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] Ninja and add_subdirectory EXCLUDE_FROM_ALL

[Brad King]

On 03/16/2016 12:13 PM, Charles Huet wrote:
>> On 03/16/2016 04:59 AM, Charles Huet wrote:
>>> If you have other ideas on how to improve this patch, I'll be happy to
>>> implement them.

All paths that are given to WritePhonyBuild in the outputs and depends
options should be sent through ConvertToNinjaPath.  This makes paths
relative and formats slashes for Windows.  This should avoid the need
to do string manipulation on the paths (e.g. substr) too.  Just be sure
to append the "/all" before calling the conversion method.

Also please keep source lines to 79 characters or less.

Thanks,
-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Ninja and add_subdirectory EXCLUDE_FROM_ALL

[Charles Huet]

Yes, sorry about that.

Le mer. 16 mars 2016 à 15:46, Brad King  a écrit :

> On 03/16/2016 04:59 AM, Charles Huet wrote:
> > Sure, done.
> >
> > If you have other ideas on how to improve this patch, I'll be happy to
> > implement them.
>
> Great.  Did you mean to attach a revised patch?
>
> Thanks,
> -Brad
>
>
From 25308102899bdcab9693da736184a4dc38001b4b Mon Sep 17 00:00:00 2001
From: Charles Huet 
Date: Fri, 11 Mar 2016 16:26:29 +0100
Subject: [PATCH] Added a target for each EXCLUDED_FROM_ALL folder that holds
 all the targets in said folder

---
 Source/cmGlobalNinjaGenerator.cxx | 69 +++
 Source/cmGlobalNinjaGenerator.h   |  1 +
 2 files changed, 70 insertions(+)

diff --git a/Source/cmGlobalNinjaGenerator.cxx b/Source/cmGlobalNinjaGenerator.cxx
index 0f06e43..0fa76a0 100644
--- a/Source/cmGlobalNinjaGenerator.cxx
+++ b/Source/cmGlobalNinjaGenerator.cxx
@@ -577,6 +577,7 @@ void cmGlobalNinjaGenerator::Generate()
 
   this->WriteAssumedSourceDependencies();
   this->WriteTargetAliases(*this->BuildFileStream);
+  this->WriteFolderTargets(*this->BuildFileStream);
   this->WriteUnknownExplicitDependencies(*this->BuildFileStream);
   this->WriteBuiltinTargets(*this->BuildFileStream);
 
@@ -1042,6 +1043,74 @@ void cmGlobalNinjaGenerator::WriteTargetAliases(std::ostream& os)
   }
 }
 
+void cmGlobalNinjaGenerator::WriteFolderTargets(std::ostream& os)
+{
+  cmGlobalNinjaGenerator::WriteDivider(os);
+  os << "# Folder targets.\n\n";
+
+  cmLocalGenerator* firstLocalGenerator = this->LocalGenerators[0];
+  const std::string rootSourceDir = firstLocalGenerator->GetSourceDirectory();
+
+  std::map targetsPerFolder;
+
+  for ( std::vector::const_iterator generatorIt = this->LocalGenerators.begin();
+generatorIt != this->LocalGenerators.end();
+++generatorIt)
+{
+const cmLocalGenerator* localGenerator = *generatorIt;
+const std::string currentSourceFolder(localGenerator->GetStateSnapshot().GetDirectory().GetCurrentSource());
+targetsPerFolder[currentSourceFolder] = cmNinjaDeps();
+for ( std::vector::const_iterator targetIt = localGenerator->GetGeneratorTargets().begin();
+  targetIt != localGenerator->GetGeneratorTargets().end();
+  ++targetIt)
+  {
+  const cmGeneratorTarget* generatorTarget = *targetIt;
+
+  const int type = generatorTarget->GetType();
+  if((type == cmState::EXECUTABLE) ||
+ (type == cmState::STATIC_LIBRARY) ||
+ (type == cmState::SHARED_LIBRARY) ||
+ (type == cmState::MODULE_LIBRARY) ||
+ (type == cmState::OBJECT_LIBRARY) ||
+ (type == cmState::UTILITY) &&
+ (!generatorTarget->GetPropertyAsBool("EXCLUDE_FROM_ALL"))
+ )
+{
+targetsPerFolder[currentSourceFolder].push_back(generatorTarget->GetName());
+}
+  }
+
+  // The directory-level rule should depend on the directory-level
+  // rules of the subdirectories.
+  std::vector children
+  = localGenerator->GetStateSnapshot().GetChildren();
+  for(std::vector::const_iterator
+stateIt = children.begin(); stateIt != children.end(); ++stateIt)
+{
+std::string currentSourceDir(stateIt->GetDirectory().GetCurrentSource());
+std::string subdir = currentSourceDir.substr(rootSourceDir.length() + 1, currentSourceDir.length()) + "/all";
+targetsPerFolder[currentSourceFolder].push_back(subdir);
+}
+}
+
+  for ( std::map::const_iterator it = targetsPerFolder.begin(); it != targetsPerFolder.end(); ++it )
+{
+cmGlobalNinjaGenerator::WriteDivider( os );
+std::string currentSourceDir(it->first);
+
+//do not generate a rule for the root source dir
+if(rootSourceDir.length() >= currentSourceDir.length())
+  continue;
+
+const std::string folderRule = currentSourceDir.substr(rootSourceDir.length() + 1, currentSourceDir.length()) + "/all";
+const std::string comment = "Folder: " + std::string(it->first);
+cmNinjaDeps output(1);
+output.push_back(folderRule);
+
+this->WritePhonyBuild(os, comment, output, it->second);
+}
+}
+
 void cmGlobalNinjaGenerator::WriteUnknownExplicitDependencies(std::ostream& os)
 {
   if (!this->ComputingUnknownDependencies)
diff --git a/Source/cmGlobalNinjaGenerator.h b/Source/cmGlobalNinjaGenerator.h
index 8656590..e95a295 100644
--- a/Source/cmGlobalNinjaGenerator.h
+++ b/Source/cmGlobalNinjaGenerator.h
@@ -342,6 +342,7 @@ private:
   void WriteAssumedSourceDependencies();
 
   void WriteTargetAliases(std::ostream& os);
+  void WriteFolderTargets(std::ostream& os);
   void WriteUnknownExplicitDependencies(std::ostream& os);
 
   void WriteBuiltinTargets(std::ostream& os);
-- 
1.8.3.1

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Re: [cmake-developers] CMake aliasing system

[Tamás Kenéz]

Ruslo, I think we all could argue both against and for implementing
cmake-ini files inside the cmake command. I mean I'm also aware of all the
pros and cons. It's just that we weigh differently.
I like loosely connected simpler building blocks and my own cmake-wrapping
extension script works fine, that's why I thought you would not lose
anything with that.

>> git commit --author="John Doe" --email="john@example.com"
 --branch="master"
>> git push --remote="git://awesome.example.com"
> This is a complete nonsense!

I agree and that's why I think cmake ini files is a good idea.

Tamas

On Tue, Mar 15, 2016 at 3:25 AM, Ruslan Baratov 
wrote:

> On 15-Mar-16 02:42, Tamás Kenéz wrote:
>
> I also doubt this belongs to upstream. But you could write a single,
> generic script which forwards its arguments to cmake and also accepts and
> processes the additional parameters along the way. I don't think we'd lose
> anything:
>
> cmakeini -c ipad -H. -DTHIS_WILL_BE_FORWARDED=AS_IT_IS
>
> This is the approach I took as I needed features like you described. But
> if there would be a mature, versatile, community-tested script I'd be
> willing to use it and contribute to it.
>
> As you can see I'm already using script `build.py` and there is not enough
> power for now (even if it extends CMake basic functionality a lot) so I was
> thinking to introduce global/local ini-configuration file anyway. Then I
> realize that most of the `build.py` functions can be implemented in such
> ini-configuration. So why not use CMake? Why for example not extend CMake
> GUI with this feature support? Why do users need to install some extra
> tools instead of just one?
>
> Global/local configuration files in not something special. Git for example
> has same system, yes it increase complexity but literally every user store
> setting there.
> Just imagine you have to write something like this every commit + push:
>
> > git commit --author="John Doe" --email="john@example.com"
>  --branch="master"
> > git push --remote="git://awesome.example.com"
>
> This is a complete nonsense!
>
> So I'm planning to make a fork anyway and do some experiments even if it
> will not accepted to upstream.
>
> Ruslo
>
>
> Tamas
>
> On Mon, Mar 14, 2016 at 4:22 PM, Ruslan Baratov via cmake-developers <
> cmake-developers@cmake.org> wrote:
>
>> On 14-Mar-16 21:59, Brad King wrote:
>>
>>> On 03/12/2016 08:04 AM, Ruslan Baratov via cmake-developers wrote:
>>>
 I guess it is a well known fact that cmake command is almost never
 executed alone and for non-trivial examples usually hold some extra
 arguments (home directory, build directory, verbosity level, toolchains,
 options, ...). Also I guess that such commands doesn't change from
 day-to-day development process and an obvious way to reduce typing is to
 create wrapper build scripts (.bat or .sh, I personally use a Python
 one).

>>> Sorry, I don't think something like this belongs upstream.  It can easily
>>> be done with shell aliases or other custom scripts.
>>>
>> I've got quite opposite experience. It's hard to say that family of
>> custom scripts (+ a lot of environment variables in .bashrc)  is an "easy
>> shell scripting", example:
>> *
>> https://github.com/ruslo/polly/blob/162cd157d1d05261a7a708435197d883c4209005/bin/build.py
>>
>>We shouldn't increase the complexity of the CMake command line
>>> interface further.
>>>
>> To be clear this feature required only one new CMake option. The rest is
>> responsibility of some pre-build parsing module.
>>
>> In general I feel sad that CMake will not became more user-friendly in
>> this exact part. Though the only proves of my point that can be provided
>> here is a users experience. Since I don't see any feedback here I'm out of
>> arguments...
>>
>> Ruslo
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at
>> 
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/cmake-developers
>>
>
>
>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: 

Re: [cmake-developers] Ninja and add_subdirectory EXCLUDE_FROM_ALL

[Charles Huet]

ConvertToNinjaPath sadly makes the path relative to the binary dir, not the
source dir.

I added a utility function 'ConvertToNinjaFolderRule' that does the same
thing as ConvertToNinjaPath, but makes relative to the source dir, and adds
the '/all' suffix.

I also made the lines less than 79 chars.

Best


Le jeu. 17 mars 2016 à 15:53, Brad King  a écrit :

> On 03/16/2016 12:13 PM, Charles Huet wrote:
> >> On 03/16/2016 04:59 AM, Charles Huet wrote:
> >>> If you have other ideas on how to improve this patch, I'll be happy to
> >>> implement them.
>
> All paths that are given to WritePhonyBuild in the outputs and depends
> options should be sent through ConvertToNinjaPath.  This makes paths
> relative and formats slashes for Windows.  This should avoid the need
> to do string manipulation on the paths (e.g. substr) too.  Just be sure
> to append the "/all" before calling the conversion method.
>
> Also please keep source lines to 79 characters or less.
>
> Thanks,
> -Brad
>
>
From d204066149e098b9e33fc1004807a6d19d3f022b Mon Sep 17 00:00:00 2001
From: Charles Huet 
Date: Fri, 11 Mar 2016 16:26:29 +0100
Subject: [PATCH] Added a target for each EXCLUDED_FROM_ALL folder that holds
 all the targets in said folder

---
 Source/cmGlobalNinjaGenerator.cxx | 85 +++
 Source/cmGlobalNinjaGenerator.h   |  3 ++
 2 files changed, 88 insertions(+)

diff --git a/Source/cmGlobalNinjaGenerator.cxx b/Source/cmGlobalNinjaGenerator.cxx
index 0f06e43..49acfe3 100644
--- a/Source/cmGlobalNinjaGenerator.cxx
+++ b/Source/cmGlobalNinjaGenerator.cxx
@@ -577,6 +577,7 @@ void cmGlobalNinjaGenerator::Generate()
 
   this->WriteAssumedSourceDependencies();
   this->WriteTargetAliases(*this->BuildFileStream);
+  this->WriteFolderTargets(*this->BuildFileStream);
   this->WriteUnknownExplicitDependencies(*this->BuildFileStream);
   this->WriteBuiltinTargets(*this->BuildFileStream);
 
@@ -849,6 +850,18 @@ std::string cmGlobalNinjaGenerator::ConvertToNinjaPath(const std::string& path)
   return convPath;
 }
 
+std::string cmGlobalNinjaGenerator::ConvertToNinjaFolderRule(const std::string& path)
+{
+  cmLocalNinjaGenerator *ng =
+static_cast(this->LocalGenerators[0]);
+  std::string convPath = ng->Convert(path, cmOutputConverter::HOME);
+#ifdef _WIN32
+  cmSystemTools::ReplaceString(convPath, "/", "\\");
+#endif
+  return convPath + "/all";
+}
+
+
 void cmGlobalNinjaGenerator::AddCXXCompileCommand(
   const std::string ,
   const std::string )
@@ -1042,6 +1055,78 @@ void cmGlobalNinjaGenerator::WriteTargetAliases(std::ostream& os)
   }
 }
 
+void cmGlobalNinjaGenerator::WriteFolderTargets(std::ostream& os)
+{
+  cmGlobalNinjaGenerator::WriteDivider(os);
+  os << "# Folder targets.\n\n";
+
+  cmLocalGenerator* firstLocalGenerator = this->LocalGenerators[0];
+  const std::string rootSourceDir = firstLocalGenerator->GetSourceDirectory();
+
+  std::map targetsPerFolder;
+
+  for ( std::vector::const_iterator generatorIt =
+this->LocalGenerators.begin();
+generatorIt != this->LocalGenerators.end();
+++generatorIt)
+{
+const cmLocalGenerator* localGenerator = *generatorIt;
+const std::string currentSourceFolder(
+  localGenerator->GetStateSnapshot().GetDirectory().GetCurrentSource());
+targetsPerFolder[currentSourceFolder] = cmNinjaDeps();
+for ( std::vector::const_iterator targetIt =
+  localGenerator->GetGeneratorTargets().begin();
+  targetIt != localGenerator->GetGeneratorTargets().end();
+  ++targetIt)
+  {
+  const cmGeneratorTarget* generatorTarget = *targetIt;
+
+  const int type = generatorTarget->GetType();
+  if((type == cmState::EXECUTABLE) ||
+ (type == cmState::STATIC_LIBRARY) ||
+ (type == cmState::SHARED_LIBRARY) ||
+ (type == cmState::MODULE_LIBRARY) ||
+ (type == cmState::OBJECT_LIBRARY) ||
+ (type == cmState::UTILITY) &&
+ (!generatorTarget->GetPropertyAsBool("EXCLUDE_FROM_ALL"))
+ )
+{
+targetsPerFolder[currentSourceFolder].push_back(
+  generatorTarget->GetName());
+}
+  }
+
+  // The directory-level rule should depend on the directory-level
+  // rules of the subdirectories.
+  std::vector children
+  = localGenerator->GetStateSnapshot().GetChildren();
+  for(std::vector::const_iterator
+stateIt = children.begin(); stateIt != children.end(); ++stateIt)
+{
+targetsPerFolder[currentSourceFolder].push_back(
+  ConvertToNinjaFolderRule(stateIt->GetDirectory().
+   GetCurrentSource()));
+}
+}
+
+  for ( std::map::const_iterator it =
+targetsPerFolder.begin(); it != targetsPerFolder.end(); ++it )
+   

Re: [cmake-developers] Startup Project Configuration [mantis 15578]

[Taylor Braun-Jones]

Here's Davy's patch rebased against current master with a unit test
added. Tested on Visual Studio 2013 only. Let me know if I screwed up
the rebase. Some conflicts weren't totally obvious to me how to
handle.

Thanks,
Taylor

On Thu, Jun 18, 2015 at 9:10 AM, Brad King  wrote:
> On 06/16/2015 07:34 PM, Davy Durham wrote:
>> Would that involve different macro's anyhow?  I could try
>> and write a macro specifically to check that, or were you thinking I
>> should be able to use the macros that are already there?  And would you
>> be opposed to my writing a dedicated one?
>
> Please write your own if needed.  I was just pointing out that the
> test already does something similar to what you need.
>
> Thanks,
> -Brad
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more 
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers


0001-Add-VS_STARTUP_PROJECT-directory-property-15578.patch
Description: Binary data


0002-fixup-Add-VS_STARTUP_PROJECT-directory-property-1557.patch
Description: Binary data


0003-fixup-Add-VS_STARTUP_PROJECT-directory-property-1557.patch
Description: Binary data


0004-fixup-Add-VS_STARTUP_PROJECT-directory-property-1557.patch
Description: Binary data
-- 

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 aliasing system

[Ruslan Baratov via cmake-developers]

I've openned new issue for further discussion:
* https://github.com/ruslo/CMake/issues/3

On 18-Mar-16 06:24, Tamás Kenéz wrote:
Ruslo, I think we all could argue both against and for implementing 
cmake-ini files inside the cmake command. I mean I'm also aware of all 
the pros and cons. It's just that we weigh differently.
I like loosely connected simpler building blocks and my own 
cmake-wrapping extension script works fine, that's why I thought you 
would not lose anything with that.


>> git commit --author="John Doe" --email="john@example.com" 
 --branch="master"

>> git push --remote="git://awesome.example.com "
> This is a complete nonsense!

I agree and that's why I think cmake ini files is a good idea.

Tamas

On Tue, Mar 15, 2016 at 3:25 AM, Ruslan Baratov 
> wrote:


On 15-Mar-16 02:42, Tamás Kenéz wrote:

I also doubt this belongs to upstream. But you could write a
single, generic script which forwards its arguments to cmake and
also accepts and processes the additional parameters along the
way. I don't think we'd lose anything:

cmakeini -c ipad -H. -DTHIS_WILL_BE_FORWARDED=AS_IT_IS

This is the approach I took as I needed features like you
described. But if there would be a mature, versatile,
community-tested script I'd be willing to use it and contribute
to it.

As you can see I'm already using script `build.py` and there is
not enough power for now (even if it extends CMake basic
functionality a lot) so I was thinking to introduce global/local
ini-configuration file anyway. Then I realize that most of the
`build.py` functions can be implemented in such ini-configuration.
So why not use CMake? Why for example not extend CMake GUI with
this feature support? Why do users need to install some extra
tools instead of just one?

Global/local configuration files in not something special. Git for
example has same system, yes it increase complexity but literally
every user store setting there.
Just imagine you have to write something like this every commit +
push:

> git commit --author="John Doe" --email="john@example.com"
 --branch="master"
> git push --remote="git://awesome.example.com
"

This is a complete nonsense!

So I'm planning to make a fork anyway and do some experiments even
if it will not accepted to upstream.

Ruslo



Tamas

On Mon, Mar 14, 2016 at 4:22 PM, Ruslan Baratov via
cmake-developers > wrote:

On 14-Mar-16 21:59, Brad King wrote:

On 03/12/2016 08:04 AM, Ruslan Baratov via
cmake-developers wrote:

I guess it is a well known fact that cmake command is
almost never
executed alone and for non-trivial examples usually
hold some extra
arguments (home directory, build directory, verbosity
level, toolchains,
options, ...). Also I guess that such commands
doesn't change from
day-to-day development process and an obvious way to
reduce typing is to
create wrapper build scripts (.bat or .sh, I
personally use a Python one).

Sorry, I don't think something like this belongs
upstream.  It can easily
be done with shell aliases or other custom scripts.

I've got quite opposite experience. It's hard to say that
family of custom scripts (+ a lot of environment variables in
.bashrc)  is an "easy shell scripting", example:
*

https://github.com/ruslo/polly/blob/162cd157d1d05261a7a708435197d883c4209005/bin/build.py

 We shouldn't increase the complexity of the CMake
command line interface further.

To be clear this feature required only one new CMake option.
The rest is responsibility of some pre-build parsing module.

In general I feel sad that CMake will not became more
user-friendly in this exact part. Though the only proves of
my point that can be provided here is a users experience.
Since I don't see any feedback here I'm out of arguments...

Ruslo

-- 


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: 

[cmake-developers] [CMake 0016021]: Cannot build on OS X with GCC

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://public.kitware.com/Bug/view.php?id=16021 
== 
Reported By:Erik Schnetter
Assigned To:
== 
Project:CMake
Issue ID:   16021
Category:   CMake
Reproducibility:always
Severity:   major
Priority:   normal
Status: new
== 
Date Submitted: 2016-03-16 14:14 EDT
Last Modified:  2016-03-16 14:14 EDT
== 
Summary:Cannot build on OS X with GCC
Description: 
I cannot build cmake 3.5.0 on OS X "El Capitan" with GCC 5.3. After configuring
normally, the build aborts with an error message. It seems that cmake uses some
system header files with Apple-specific extensions that GCC cannot handle.

These extensions seem to have to do with the user interface; if so, there should
be an option to not build the parts that cannot be built, and still build the
"regular" cmake.

cmake 3.4.3 builds fine with the same setup.


Steps to Reproduce: 
Install GCC 5.3 via MacPorts; make GCC the default compiler

tar xzf cmake-3.5.0.tar.gz 
cd cmake-3.5.0
# Building without the OpenSSL flag aborts with an error
./configure -- -DCMAKE_USE_OPENSSL=ON
gmake


Additional Information: 
The build aborts with

[ 85%] Building CXX object
Source/CMakeFiles/CPackLib.dir/CPack/cmCPackDragNDropGenerator.cxx.o
In file included from /usr/include/Availability.h:168:0,
 from /usr/include/inttypes.h:224,
 from /tmp/cmake-3.5.0/Utilities/KWIML/include/kwiml/int.h:194,
 from /tmp/cmake-3.5.0/Utilities/cm_kwiml.h:22,
 from /tmp/cmake-3.5.0/Source/cmStandardIncludes.h:34,
 from /tmp/cmake-3.5.0/Source/cmObject.h:15,
 from /tmp/cmake-3.5.0/Source/CPack/cmCPackGenerator.h:16,
 from
/tmp/cmake-3.5.0/Source/CPack/cmCPackDragNDropGenerator.h:16,
 from
/tmp/cmake-3.5.0/Source/CPack/cmCPackDragNDropGenerator.cxx:13:
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Headers/LSInfoDeprecated.h:1242:34:
error: expected '}' before '__attribute__'
   kLSHandlerOptionsDefault   __OSX_AVAILABLE_BUT_DEPRECATED_MSG(__MAC_10_4,
__MAC_10_11, __IPHONE_4_0, __IPHONE_9_0, "Creator codes are deprecated on OS
X.") = 0,
  ^
In file included from
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Headers/LSInfo.h:529:0,
 from
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Headers/LaunchServices.h:27,
 from
/System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:39,
 from
/System/Library/Frameworks/Carbon.framework/Headers/Carbon.h:20,
 from
/tmp/cmake-3.5.0/Source/CPack/cmCPackDragNDropGenerator.cxx:34:
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Headers/LSInfoDeprecated.h:1242:163:
error: expected unqualified-id before '=' token
   kLSHandlerOptionsDefault   __OSX_AVAILABLE_BUT_DEPRECATED_MSG(__MAC_10_4,
__MAC_10_11, __IPHONE_4_0, __IPHONE_9_0, "Creator codes are deprecated on OS
X.") = 0,


 ^
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Headers/LSInfoDeprecated.h:1294:1:
error: expected declaration before '}' token
 }
 ^
Source/CMakeFiles/CPackLib.dir/build.make:518: recipe for target
'Source/CMakeFiles/CPackLib.dir/CPack/cmCPackDragNDropGenerator.cxx.o' failed
gmake[2]: ***
[Source/CMakeFiles/CPackLib.dir/CPack/cmCPackDragNDropGenerator.cxx.o] Error 1
CMakeFiles/Makefile2:2018: recipe for target
'Source/CMakeFiles/CPackLib.dir/all' failed
gmake[1]: *** [Source/CMakeFiles/CPackLib.dir/all] Error 2
Makefile:160: recipe for target 'all' failed
gmake: *** [all] Error 2

== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-03-16 14:14 Erik Schnetter 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-developers] Contribution for Issue #0015146

[Sebastian Windisch]

Hi,

I like to contribute code for issue #0015146. I had issues to get the 
/MANIFESTUAC flag (Microsoft C/C++ Compiler) working in CMake. I saw that it is 
a known bug which is not resolved yet since 2014. So I tried my best to solve 
the issue.

What I did: I introduced a new flag in cmIDEFlagTable.h called 
RegularExpression, and made some changes in cmIDEOptions::CheckFlagTable and 
the cmVS*LinkFlagTable.h files. These changes now allow matching regular 
expressions to complex flags and extracting the relevant values out of it to 
finally map them to the according IDE XML variables.

Example:

{"UACUIAccess", "MANIFESTUAC:level=([a-zA-Z]+) uiAccess=([a-zA-Z]+)$", "", 
"\\2", cmVS7FlagTable::RegularExpression},

If the flag matches with the second argument, the subexpressions get extracted 
from which the second one will be mapped to variable UACUIAccess.

Since this is my first contribution I attached it as a patch (master @ 
9cdb37e9175b2e3c6367bc4863fda0404cb1c3a2).

Regards,
Sebastian





patch.diff
Description: Binary data
-- 

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 to only consider build dependencies between files in the source directory

[Brad King]

On 03/17/2016 09:54 AM, Attila Krasznahorkay wrote:
> Attached is a new attempt. It seems to work correctly in my tests
> with the Makefile generator.

Thanks.

> +  // If it's an absolute path, check if it starts with the source
> +  // direcotory:
> +  return ( ( path.find( SourceDir ) != 0 ) &&
> +   ( path.find( BinaryDir ) != 0 ) );

Please look at using strncmp and a check that the following character
is a nul terminator or '/'.  Otherwise an external location with
a common prefix may be mistaken for part of the project.

Also please add documentation in a

  Help/variable/CMAKE_DEPENDS_IN_PROJECT_ONLY.rst

file and update Help/manual/cmake-variables.7.rst to reference it.

Thanks,
-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Ninja and add_subdirectory EXCLUDE_FROM_ALL

[Charles Huet]

Awesome, thanks!

I'll check monday and report, but this looks like it'll work the same as
the patch I sent last, which I've been using the past few days.
Looking forward to have this feature in CMake !

Le ven. 18 mars 2016 à 16:03, Brad King  a écrit :

> On 03/17/2016 11:23 AM, Charles Huet wrote:
> > I added a utility function 'ConvertToNinjaFolderRule' that
> > does the same thing as ConvertToNinjaPath, but makes relative
> > to the source dir, and adds the '/all' suffix.
>
> Great.  I've applied the patch with a few style changes and
> logic fixes.  I also added documentation and a test:
>
>  Ninja: Add `$subdir/all` targets
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ca575fe9
>
>  Ninja: Add test for `$subdir/all` targets
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=86c851e6
>
>  Help: Add notes for topic 'ninja-directory-targets'
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=133aed8f
>
> Please try out that version to make sure it still works for you.
>
> Thanks,
> -Brad
>
>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] [CMake 0016025]: Add support WINDOWS_EXPORT_ALL_SYMBOLS for executable exports lib

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://cmake.org/Bug/view.php?id=16025 
== 
Reported By:Yury Zhuravlev
Assigned To:
== 
Project:CMake
Issue ID:   16025
Category:   CMake
Reproducibility:always
Severity:   feature
Priority:   normal
Status: new
== 
Date Submitted: 2016-03-18 10:04 EDT
Last Modified:  2016-03-18 10:04 EDT
== 
Summary:Add support WINDOWS_EXPORT_ALL_SYMBOLS for
executable exports lib
Description: 
For access from DLL to mother programm we need create .lib by EXPORTS flag but
without /DEF we can't export symbols.

This code must work:
add_executable(prog1 blalba)
set_target_properties(prog1 PROPERTIES ENABLE_EXPORTS 1)
set_target_properties(prog1 PROPERTIES WINDOWS_EXPORT_ALL_SYMBOLS 1)

Now I use ugly perl script for gen .def file.

Thanks. 
PS for .dll's WINDOWS_EXPORT_ALL_SYMBOLS worked correct. 
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-03-18 10:04 Yury Zhuravlev 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] Patch to only consider build dependencies between files in the source directory

[Attila Krasznahorkay]

Hi Brad,

Attached is a new attempt. It seems to work correctly in my tests with the 
Makefile generator. (Which, to be fair, is the only generator that we use in 
production mode at the moment...)

Cheers,
Attila


0001-CMAKE_DEPENDS_IN_PROJECT_ONLY-feature-addition.patch
Description: Binary data


> On 15 Mar 2016, at 19:13, Brad King  wrote:
> 
> On 03/15/2016 10:48 AM, Attila Krasznahorkay wrote:
>> https://cmake.org/pipermail/cmake-developers/2015-December/027197.html
>> 
>> With the following patch, when setting the CMAKE_ONLY_IN_SOURCE_DEPENDENCIES
>> variable to 1/ON/TRUE, this file size goes down to just a few kilobytes.
>> Speeding up our build noticeably.
> 
> Thanks.  As Ben pointed out in the original thread the build tree should
> be included as well.  Perhaps a name like
> 
>  CMAKE_DEPENDS_IN_PROJECT_ONLY
> 
> could be used to indicate that it includes only dependencies in the project
> directories (source or build tree).
> 
>> As far as I can see, the "cmake -E cmake_depends" call is only used by
>> the Makefile generator at the moment. So I only taught that generator
>> about this new variable.
> 
> The Makefile generator is the only one for which CMake takes responsibility
> for implicit dependency scanning.
> 
>> I just didn't see what I should do in the Ninja generator for instance
>> to apply this setting. Even though I would be very interested in implementing
>> the feature in that generator as well.
> 
> The Ninja generator uses the compiler's information about dependencies
> as generated by options like `gcc -MD`.  Since that occurs along with
> the compilation there is little cost to including all dependencies
> except for stat during rebuilds.  See discussion here:
> 
>  https://cmake.org/Bug/view.php?id=14914
> 
> about the opposite use case (including system dependencies instead of
> excluding them).
> 
>> +  infoFileStream
>> +<< "set(CMAKE_ONLY_IN_SOURCE_DEPENDENCIES "
>> +<< ( this->Makefile->IsOn( "CMAKE_ONLY_IN_SOURCE_DEPENDENCIES" ) ?
>> + "1" : "0" )
>> +<< ")\n";
> 
> Rather than communicating this to the dependency scanning step and
> doing the filtering there, please look at applying the filter during
> generation of CMAKE__TARGET_INCLUDE_PATH.
> 
> Thanks,
> -Brad
> 

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Ninja and add_subdirectory EXCLUDE_FROM_ALL

[Brad King]

On 03/16/2016 04:59 AM, Charles Huet wrote:
> Sure, done.
> 
> If you have other ideas on how to improve this patch, I'll be happy to
> implement them.

Great.  Did you mean to attach a revised patch?

Thanks,
-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] Fwd: [CMake 0016022]: GenerateExportHeader DEFINE_NO_DEPRECATED define conflicts

[Andreas Schuh]

Hi,

regarding this issue report, I’ve just attached a patch 
 for the current 
HEAD of the master branch that fixes the issue. Please have a look and it would 
be great if somebody could apply it. It currently causes problems in particular 
for projects using VTK, which may need this patch to be applied as well, given 
that it ships its own copy of the GenerateExportHeader module.

Cheers,
Andreas

> Begin forwarded message:
> 
> From: Mantis Bug Tracker 
> Subject: [cmake-developers] [CMake 0016022]: GenerateExportHeader 
> DEFINE_NO_DEPRECATED define conflicts
> Date: 16 March 2016 at 21:28:00 GMT
> To: cmake-developers@cmake.org
> 
> 
> The following issue has been SUBMITTED. 
> == 
> https://cmake.org/Bug/view.php?id=16022 
> == 
> Reported By:Andreas Schuh
> Assigned To:
> == 
> Project:CMake
> Issue ID:   16022
> Category:   Modules
> Reproducibility:always
> Severity:   minor
> Priority:   normal
> Status: new
> == 
> Date Submitted: 2016-03-16 17:27 EDT
> Last Modified:  2016-03-16 17:28 EDT
> == 
> Summary:GenerateExportHeader DEFINE_NO_DEPRECATED define
> conflicts
> Description: 
> The header file generated by generate_export_header adds a
> 
>#define DEFINE_NO_DEPRECATED 0|1
> 
> macro which is used to decide whether or not to define the respective macro 
> with
> the desired library prefix and base name. But this macro has the same name for
> all libraries and is not undefined when it is no longer needed. In my project,
> this for example created a conflict with the VTK library which uses such
> generated header file which must of course be included in the public header
> files.
> 
> To solve this conflict, I am using now (temporarily) a custom
> exportheader.cmake.in template file by changing the
> _GENERATE_EXPORT_HEADER_MODULE_DIR path to a directory in my project after
> including the GenerateExportHeader module. Find the modified template file
> attached.
> 
> There is certainly a better fix for this bug.
> == 
> 
> Issue History 
> Date ModifiedUsername   FieldChange   
> == 
> 2016-03-16 17:27 Andreas Schuh  New Issue
> 2016-03-16 17:28 Andreas Schuh  File Added: exportheader.cmake.in 
>   
> 
> ==
> 
> -- 
> 
> Powered by www.kitware.com
> 
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
> 
> Kitware offers various services to support the CMake community. For more 
> information on each offering, please visit:
> 
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
> 
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
> 
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers