[Cmake-commits] CMake branch, next, updated. v3.4.0-1550-g523ccb5

[Gregor Jasny via Cmake-commits]

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, next has been updated
   via  523ccb5cf99486b8951bec2505c677310eee710a (commit)
   via  6e81fe754311f879d384d66cdade128afdff7313 (commit)
  from  48f4880a3d252fa8fd86896d55c88ee90a3a04af (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=523ccb5cf99486b8951bec2505c677310eee710a
commit 523ccb5cf99486b8951bec2505c677310eee710a
Merge: 48f4880 6e81fe7
Author: Gregor Jasny 
AuthorDate: Mon Nov 30 16:09:03 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Nov 30 16:09:03 2015 -0500

Merge topic 'regex-explorer' into next

6e81fe75 cmake-gui: Add regex explorer window


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6e81fe754311f879d384d66cdade128afdff7313
commit 6e81fe754311f879d384d66cdade128afdff7313
Author: Gregor Jasny 
AuthorDate: Wed Nov 18 22:40:59 2015 +0100
Commit: Gregor Jasny 
CommitDate: Mon Nov 30 22:08:39 2015 +0100

cmake-gui: Add regex explorer window

diff --git a/Help/release/dev/regex-explorer.rst 
b/Help/release/dev/regex-explorer.rst
new file mode 100644
index 000..5c7ae3a
--- /dev/null
+++ b/Help/release/dev/regex-explorer.rst
@@ -0,0 +1,6 @@
+regex-explorer
+--
+
+* The Qt base CMake GUI got a Regular Expression Explorer which could be used 
to
+  create and evaluate regular expressions in real-time. The explorer window
+  is available via the ``Tools``menu.
diff --git a/Source/QtDialog/CMakeLists.txt b/Source/QtDialog/CMakeLists.txt
index 66fd18b..cad11f5 100644
--- a/Source/QtDialog/CMakeLists.txt
+++ b/Source/QtDialog/CMakeLists.txt
@@ -113,12 +113,15 @@ set(SRCS
   QCMakeCacheView.h
   QCMakeWidgets.cxx
   QCMakeWidgets.h
+  RegexExplorer.cxx
+  RegexExplorer.h
   )
 QT4_WRAP_UI(UI_SRCS
   CMakeSetupDialog.ui
   Compilers.ui
   CrossCompiler.ui
   AddCacheEntry.ui
+  RegexExplorer.ui
   )
 QT4_WRAP_CPP(MOC_SRCS
   AddCacheEntry.h
@@ -128,6 +131,7 @@ QT4_WRAP_CPP(MOC_SRCS
   QCMake.h
   QCMakeCacheView.h
   QCMakeWidgets.h
+  RegexExplorer.h
   )
 QT4_ADD_RESOURCES(RC_SRCS CMakeSetup.qrc)
 
diff --git a/Source/QtDialog/CMakeSetupDialog.cxx 
b/Source/QtDialog/CMakeSetupDialog.cxx
index 748dd7d..2b12834 100644
--- a/Source/QtDialog/CMakeSetupDialog.cxx
+++ b/Source/QtDialog/CMakeSetupDialog.cxx
@@ -33,6 +33,7 @@
 #include "QCMakeCacheView.h"
 #include "AddCacheEntry.h"
 #include "FirstConfigure.h"
+#include "RegexExplorer.h"
 #include "cmSystemTools.h"
 #include "cmVersion.h"
 
@@ -125,6 +126,9 @@ CMakeSetupDialog::CMakeSetupDialog()
this, SLOT(doInstallForCommandLine()));
 #endif
   ToolsMenu->addSeparator();
+  ToolsMenu->addAction(tr("Regular Expression Explorer..."),
+   this, SLOT(doRegexExplorerDialog()));
+  ToolsMenu->addSeparator();
   ToolsMenu->addAction(tr(" in Output..."),
this, SLOT(doOutputFindDialog()),
QKeySequence::Find);
@@ -1272,6 +1276,12 @@ void CMakeSetupDialog::doOutputFindDialog()
 }
 }
 
+void CMakeSetupDialog::doRegexExplorerDialog()
+{
+  RegexExplorer dialog(this);
+  dialog.exec();
+}
+
 void CMakeSetupDialog::doOutputFindPrev()
 {
   doOutputFindNext(false);
diff --git a/Source/QtDialog/CMakeSetupDialog.h 
b/Source/QtDialog/CMakeSetupDialog.h
index 1b26c64..bfd2bc9 100644
--- a/Source/QtDialog/CMakeSetupDialog.h
+++ b/Source/QtDialog/CMakeSetupDialog.h
@@ -82,6 +82,7 @@ protected slots:
   void doOutputFindNext(bool directionForward = true);
   void doOutputFindPrev();
   void doOutputErrorNext();
+  void doRegexExplorerDialog();
 
 protected:
 
diff --git a/Source/QtDialog/RegexExplorer.cxx 
b/Source/QtDialog/RegexExplorer.cxx
new file mode 100644
index 000..b583d70
--- /dev/null
+++ b/Source/QtDialog/RegexExplorer.cxx
@@ -0,0 +1,166 @@
+/*
+  CMake - Cross Platform Makefile Generator
+  Copyright 2015 Kitware, Inc., Gregor Jasny
+
+  Distributed under the OSI-approved BSD License (the "License");
+  see accompanying file Copyright.txt for details.
+
+  This software is distributed WITHOUT ANY WARRANTY; without even the
+  implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+  See the License for more information.
+*/
+
+#include "RegexExplorer.h"
+
+RegexExplorer::RegexExplorer(QWidget* p) : m_matched(false)
+{
+  this->setupUi(this);
+
+  for(int i = 1; i < cmsys::RegularExpression::NSUBEXP; ++i)
+{
+

[Cmake-commits] CMake branch, next, updated. v3.4.0-1548-g48f4880

[Gregor Jasny via Cmake-commits]

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, next has been updated
   via  48f4880a3d252fa8fd86896d55c88ee90a3a04af (commit)
   via  a31c85da5ed82d913eeb71ebbbd4d51af4625380 (commit)
  from  d5dcfed6747cda9f835988bd3d02ec4b4864fc54 (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=48f4880a3d252fa8fd86896d55c88ee90a3a04af
commit 48f4880a3d252fa8fd86896d55c88ee90a3a04af
Merge: d5dcfed a31c85d
Author: Gregor Jasny 
AuthorDate: Mon Nov 30 16:06:58 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Nov 30 16:06:58 2015 -0500

Merge topic 'regex-explorer' into next

a31c85da fixup! cmake-gui: Add regex explorer window


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a31c85da5ed82d913eeb71ebbbd4d51af4625380
commit a31c85da5ed82d913eeb71ebbbd4d51af4625380
Author: Gregor Jasny 
AuthorDate: Mon Nov 30 22:02:44 2015 +0100
Commit: Gregor Jasny 
CommitDate: Mon Nov 30 22:02:44 2015 +0100

fixup! cmake-gui: Add regex explorer window

diff --git a/Source/QtDialog/RegexExplorer.cxx 
b/Source/QtDialog/RegexExplorer.cxx
index 04fb5fb..b583d70 100644
--- a/Source/QtDialog/RegexExplorer.cxx
+++ b/Source/QtDialog/RegexExplorer.cxx
@@ -41,7 +41,9 @@ void RegexExplorer::on_regularExpression_textChanged(const 
QString& text)
 #else
   m_regex = text.toStdString();
 #endif
-  bool validExpression = m_regexParser.compile(m_regex);
+
+  bool validExpression =
+stripEscapes(m_regex) && m_regexParser.compile(m_regex);
   if(!validExpression)
 {
 m_regexParser.set_invalid();
@@ -115,3 +117,50 @@ void RegexExplorer::clearMatch()
   match0->clear();
   matchN->clear();
 }
+
+bool RegexExplorer::stripEscapes(std::string& source)
+{
+  const char* in = source.c_str();
+
+  std::string result;
+  result.reserve(source.size());
+
+  for(char inc = *in; inc != '\0'; inc = *++in)
+{
+if(inc == '\\')
+  {
+  char nextc = in[1];
+  if(nextc == 't')
+{
+result.append(1, '\t');
+in++;
+}
+  else if(nextc == 'n')
+{
+result.append(1, '\n');
+in++;
+}
+  else if(nextc == 't')
+{
+result.append(1, '\t');
+in++;
+}
+  else if(isalnum(nextc) || nextc == '\0')
+{
+return false;
+}
+  else
+{
+result.append(1, nextc);
+in++;
+}
+  }
+else
+  {
+result.append(1, inc);
+  }
+}
+
+source = result;
+return true;
+}
diff --git a/Source/QtDialog/RegexExplorer.h b/Source/QtDialog/RegexExplorer.h
index b758a08..2ac9c3e 100644
--- a/Source/QtDialog/RegexExplorer.h
+++ b/Source/QtDialog/RegexExplorer.h
@@ -35,6 +35,7 @@ private slots:
 
 private:
   static void setStatusColor(QWidget* widget, bool successful);
+  static bool stripEscapes(std::string& regex);
 
   void clearMatch();
 

---

Summary of changes:
 Source/QtDialog/RegexExplorer.cxx |   51 -
 Source/QtDialog/RegexExplorer.h   |1 +
 2 files changed, 51 insertions(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[cmake-developers] [CMake 0015867]: Meta-projects generated for Visual Studio 2013 solutions are always multi-byte

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://cmake.org/Bug/view.php?id=15867 
== 
Reported By:Marcel Beister
Assigned To:
== 
Project:CMake
Issue ID:   15867
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2015-11-30 05:17 EST
Last Modified:  2015-11-30 05:17 EST
== 
Summary:Meta-projects generated for Visual Studio 2013
solutions are always multi-byte
Description: 
Expected Behavior:
If "add_definitions(-D_UNICODE -DUNICODE)" was added to the CMakeList.txt, all
project files for Visual Studio solutions should be marked as unicode.

Real Behavior:
While the behavior is as expected in Visual Studio 2008, at least Visual Studio
2013 does not show the expected behavior and sets meta projects (e.g.
ZERO_CHECK) to multi-byte.

Problem:
Starting with Visual Studio 2013, MFC with multi-byte character set is marked
deprecated and no longer possible without installing additional software.


Steps to Reproduce: 
* Create a simple CMake project
* Add "add_definitions(-D_UNICODE -DUNICODE)" to the CMakeList.txt
* Generate a Visual Studio 2013 solution
* Open the generate solution with Visual Studio
* Verify the character set of meta projects (e.g. ZERO_CHECK)

Additional Information: 
http://stackoverflow.com/questions/22011610/how-do-i-set-unicode-as-character-set-in-the-all-build-and-zero-check-visual-stu?lq=1
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-11-30 05:17 Marcel Beister 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-commits] CMake branch, next, updated. v3.4.0-1534-gaad2a58

[Brad King]

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, next has been updated
   via  aad2a58ff2946212d9d6f6de24a5b756fb482701 (commit)
   via  3c6a3668760ba48dde33f20de08dc6e16cfe7ab3 (commit)
   via  31b013b14ad3bf4838f4ba327b5392018f4853b6 (commit)
  from  d8d7bbdb520b7a9b5d9be900a45d9c9559122179 (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=aad2a58ff2946212d9d6f6de24a5b756fb482701
commit aad2a58ff2946212d9d6f6de24a5b756fb482701
Merge: d8d7bbd 3c6a366
Author: Brad King 
AuthorDate: Mon Nov 30 11:22:18 2015 -0500
Commit: Brad King 
CommitDate: Mon Nov 30 11:22:18 2015 -0500

Merge branch 'master' into next


---

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
http://public.kitware.com/mailman/listinfo/cmake-commits

Re: [cmake-developers] [PATCH] Add NIOS2 CPU support

[Marek Vasut]

On Monday, November 30, 2015 at 04:40:55 PM, Brad King wrote:
> On 11/26/2015 03:48 PM, Marek Vasut wrote:
> > Add necessary bits to support the NIOS2 little-endian CPU.
> 
> Thanks.  I split the KWSys part out to send to its upstream here:
> 
>  http://review.source.kitware.com/20445
> 
> Once integrated there it will be merged to CMake.
> 
> The KWIML change I've integrated here:
> 
>  KWIML: Teach ABI.h that NIOS2 CPU is little-endian
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=eec87ec8

I see, thank you!

Best regards,
Marek Vasut
-- 

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] Qt4Macros generate resources with same file name

[Joseph Shen]

Yes, I found that. Thanks for the view, I will work an more acceptable
patch later this week.

Have a nice day~~

On Mon, Nov 30, 2015, 11:48 PM Clinton Stimpson 
wrote:

> On Tuesday, November 24, 2015 11:01:27 AM Joseph Shen wrote:
> > Dear CMake developers:
> >
> > Please view attached small patch that try to fix Qt4Macros generate
> > resources with same file name error.
> >
> > Right now, in the CMake main branch, using cmake with Qt4 library
> > add resources project can be done like this:
> >
> >  qt4_add_resources(app_source_res res_a.qrc)
> >  qt4_add_resources(app_source_res res_b.qrc)
> >
> > and above two line added two resource file, but if we try to add resource
> > file with same name, a very subtle error will happen: only one file will
> > be compile the as resources, and the other was totally ignored.
> >
> > In some big projects, using the same file name as resource file name
> > can be very common, especially when we using multi cmake files try
> > to make the whole project into small ones, in each cmake files someone
> > maybe just using the same resources file name like res.qrc which is
> > located in the sub module resources folder.
> >
> >qt4_add_resources(app_source_res res.qrc)
> >
> > so, if they try to do this, and in the last add ${app_source_res} to the
> > dependency list using:
> >
> >   add_executable(project_name ${app_source_res} ...)
> >
> > but in reality they just add one resources file, but CMake do not report
> > any error or warning.
> >
> > From the source of Qt4Macros we can see:
> >
> > line 211:   get_filename_component(outfilename ${it} NAME_WE)
> > line 244:   ARGS ${rcc_options} -name ${outfilename} -o ${outfile}
> ${infile}
> >
> >
> > became we just using NAME_WE as the output file, if two files with same
> > file name, one will overwrite the other, and this is the reason why the
> > error
> > will happen.
> >
> > To fix this, I view the whole Qt4Macros source file, find a function
> > QT4_MAKE_OUTPUT_FILE already exist to do something just what we
> > need. so I work out a patch add two line code and remove two, and it
> works
> > good to me, and I think this might fix the problem.
> >
> > Please view this patch, thanks :)
>
>
> Back on list with a more concrete example, and also to prevent others from
> merging this patch, because I don't think this patch should be accepted.
> The
> random string breaks using the Q_INIT_RESOURCE() macro.
>
>
> For example:
> ===
> project(qrc)
>
> find_package(Qt4)
> include(${QT_USE_FILE})
>
> qt4_add_resources(qrc_srcs ${CMAKE_CURRENT_SOURCE_DIR}/my.qrc)
>
> add_library(qrc STATIC ${qrc_srcs})
>
> add_executable(main main.cpp)
> target_link_libraries(main qrc)
> 
>
> main.cpp has:
> int main()
> {
>   Q_INIT_RESOURCE(my);
> }
>
> With the patch applied, I now get the link error:
>
> main.cpp:(.text+0x5): undefined reference to `qInitResources_my()'
>
> "my" comes from the basename of my.qrc, and is the name used for the
> resource.
> With CMake generating a random name, there would be no way to reference
> that
> name when calling Q_INIT_RESOURCE.
>
> I would prefer allowing the caller to pass in an alternate -name option for
> rcc, as I said in my first review.  With that, the caller would be able to
> pass
> a random string.
>
> Clint
>
>
-- 

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-commits] CMake branch, master, updated. v3.4.0-619-g3c6a366

[Brad King]

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  3c6a3668760ba48dde33f20de08dc6e16cfe7ab3 (commit)
   via  9342a4c2033ce7bb6845afd3625ac9c195a8e22d (commit)
   via  5f860ebb67e86e0aa407e26ddf79652f73742211 (commit)
   via  f21dc4a81c05c79b873c9918f6fe8aff4bf02133 (commit)
   via  bc1d3a8a8783848016ef12044a02a28b620c41a0 (commit)
   via  85fe26b5f742b704b51a7e15b4806366feab3a23 (commit)
   via  518d6b22f6705c4747c713031587705641540364 (commit)
   via  32edac6fddfbe91e47b34506cda855232d5a9e2c (commit)
   via  0fa7f143a08b62459900bd811c2c0674562bb8be (commit)
   via  d85c9176ae15f4fb203e501d777cfce8304bf256 (commit)
   via  8e1be7bf688dc282408aa0403e9896fa5a142ec4 (commit)
  from  31b013b14ad3bf4838f4ba327b5392018f4853b6 (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=3c6a3668760ba48dde33f20de08dc6e16cfe7ab3
commit 3c6a3668760ba48dde33f20de08dc6e16cfe7ab3
Merge: 31b013b 9342a4c
Author: Brad King 
AuthorDate: Mon Nov 30 11:22:10 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Nov 30 11:22:10 2015 -0500

Merge topic 'reduce-cmState-accumulation-for-master'

9342a4c2 Merge branch 'reduce-cmState-accumulation' into 
reduce-cmState-accumulation-for-master
5f860ebb cmState: Avoid accumulating snapshot storage for short-lived scopes
f21dc4a8 cmState: Avoid accumulating policy stack storage for short-lived 
scopes
bc1d3a8a cmListFileCache: Implement cmListFileBacktrace ctor/dtor 
out-of-line
85fe26b5 cmLinkedTree: Add Pop method
518d6b22 cmLinkedTree: Rename 'Extend' method to 'Push'
32edac6f cmState: Enforce policy scope balancing around variable scopes
0fa7f143 cmLocalGenerator: Use ScopePushPop RAII class to manage local 
variable scopes
d85c9176 cmMakefile: Remove unused PolicyPushPop interfaces
8e1be7bf cmMakefile: Clarify purpose of method that pops a scope snapshot


---

Summary of changes:
 Source/cmLinkedTree.h   |   33 +---
 Source/cmListFileCache.cxx  |   15 
 Source/cmListFileCache.h|6 +--
 Source/cmLocalGenerator.cxx |6 +--
 Source/cmMakefile.cxx   |   28 ++
 Source/cmMakefile.h |8 +---
 Source/cmState.cxx  |   90 ---
 Source/cmState.h|1 +
 8 files changed, 121 insertions(+), 66 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

Re: [cmake-developers] [PATCH] FindBoost: Add imported targets

[Brad King]

On 11/30/2015 11:26 AM, rle...@codelibre.net wrote:
> I have improved the parsing speed somewhat and added some progress
> diagnostics to inform the user what's happening to compensate for the time
> it takes to process the dependencies.  It's still slower than I'd ideally
> like, but it's a bit better.  If there's any way to make it even faster
> I'd be interested.  I think what's there is technically correct though.

I'm sorry I didn't have a chance to look at this sooner.

Parsing dependencies out of the header files is far too heavy-weight
for a find module.  We should memorize the known dependencies as
is done for other find modules that provide imported targets.  If
that is not tractable then the FindBoost module is the wrong place
to solve this problem.

FWIW, I think effort would be better spent working with Boost
folks to get cmake package files provided.  They don't have to
build with CMake to do this.  Qt5 for example builds without
CMake but still provides CMake package files.

-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-commits] CMake branch, next, updated. v3.4.0-1536-ga2d81f6

[Brad King]

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, next has been updated
   via  a2d81f68df75eba057b47b96a7dcab81bee75ece (commit)
   via  565661ea6680b27fcb8b433c4bef94a0bd1dd2ca (commit)
  from  aad2a58ff2946212d9d6f6de24a5b756fb482701 (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=a2d81f68df75eba057b47b96a7dcab81bee75ece
commit a2d81f68df75eba057b47b96a7dcab81bee75ece
Merge: aad2a58 565661e
Author: Brad King 
AuthorDate: Mon Nov 30 11:53:07 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Nov 30 11:53:07 2015 -0500

Merge topic 'cpack-dmg-multilanguage-sla' into next

565661ea CPack/DragNDrop: Allow single license for multiple languages


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=565661ea6680b27fcb8b433c4bef94a0bd1dd2ca
commit 565661ea6680b27fcb8b433c4bef94a0bd1dd2ca
Author: Simon Levermann 
AuthorDate: Tue Nov 24 16:17:53 2015 +0100
Commit: Brad King 
CommitDate: Mon Nov 30 11:52:31 2015 -0500

CPack/DragNDrop: Allow single license for multiple languages

When both CPACK_DMG_SLA_DIR and CPACK_RESOURCE_FILE_LICENSE are defined,
use the license file for all languages instead of looking for a license
file for each language.  Also expand the documentation on the SLA
variables.

diff --git a/Modules/CPackDMG.cmake b/Modules/CPackDMG.cmake
index 6b5af7e..e34f8cd 100644
--- a/Modules/CPackDMG.cmake
+++ b/Modules/CPackDMG.cmake
@@ -49,11 +49,29 @@
 # .. variable:: CPACK_DMG_SLA_DIR
 #
 #   Directory where license and menu files for different languages are stored.
+#   Setting this causes CPack to look for a ``.menu.txt`` and
+#   ``.license.txt`` file for every language defined in
+#   ``CPACK_DMG_SLA_LANGUAGES``. If both this variable and
+#   ``CPACK_RESOURCE_FILE_LICENSE`` are set, CPack will only look for the menu
+#   files and use the same license file for all languages.
 #
 # .. variable:: CPACK_DMG_SLA_LANGUAGES
 #
 #   Languages for which a license agreement is provided when mounting the
-#   generated DMG.
+#   generated DMG. A menu file consists of 9 lines of text. The first line is
+#   is the name of the language itself, uppercase, in English (e.g. German).
+#   The other lines are translations of the following strings:
+#
+#   - Agree
+#   - Disagree
+#   - Print
+#   - Save...
+#   - You agree to the terms of the License Agreement when you click the
+# "Agree" button.
+#   - Software License Agreement
+#   - This text cannot be saved. The disk may be full or locked, or the file
+# may be locked.
+#   - Unable to print. Make sure you have selected a printer.
 #
 #   For every language in this list, CPack will try to find files
 #   ``.menu.txt`` and ``.license.txt`` in the directory
diff --git a/Source/CPack/cmCPackDragNDropGenerator.cxx 
b/Source/CPack/cmCPackDragNDropGenerator.cxx
index b5df2d0..31665da 100644
--- a/Source/CPack/cmCPackDragNDropGenerator.cxx
+++ b/Source/CPack/cmCPackDragNDropGenerator.cxx
@@ -131,10 +131,11 @@ int cmCPackDragNDropGenerator::InitializeInternal()
   if(!license_file.empty() &&
  (license_file.find("CPack.GenericLicense.txt") == std::string::npos))
 {
-cmCPackLogger(cmCPackLog::LOG_WARNING,
+cmCPackLogger(cmCPackLog::LOG_OUTPUT,
   "Both CPACK_DMG_SLA_DIR and CPACK_RESOURCE_FILE_LICENSE specified, "
-  "defaulting to CPACK_DMG_SLA_DIR"
+  "using CPACK_RESOURCE_FILE_LICENSE as a license for all languages."
   << std::endl);
+singleLicense = true;
 }
   }
 if(!this->IsSet("CPACK_DMG_SLA_LANGUAGES"))
@@ -166,7 +167,7 @@ int cmCPackDragNDropGenerator::InitializeInternal()
 for(size_t i = 0; i < languages.size(); ++i)
   {
   std::string license = slaDirectory + "/" + languages[i] + ".license.txt";
-  if (!cmSystemTools::FileExists(license))
+  if (!singleLicense && !cmSystemTools::FileExists(license))
 {
 cmCPackLogger(cmCPackLog::LOG_ERROR,
   "Missing license file " << languages[i] << ".license.txt"
@@ -366,7 +367,7 @@ int cmCPackDragNDropGenerator::CreateDMG(const std::string& 
src_dir,
 
   // use sla_dir if both sla_dir and license_file are set
   if(!cpack_license_file.empty() &&
- !slaDirectory.empty())
+ !slaDirectory.empty() && !singleLicense)
 {
 cpack_license_file = "";
 }
@@ -699,7 +700,14 @@ int cmCPackDragNDropGenerator::CreateDMG(const 
std::string& src_dir,
   {
   for(size_t i = 0; i < languages.size(); ++i)
 {
-

Re: [cmake-developers] [PATCH] FindBoost: Add imported targets

[rleigh]

> On 11/30/2015 11:26 AM, rle...@codelibre.net wrote:
>> I have improved the parsing speed somewhat and added some progress
>> diagnostics to inform the user what's happening to compensate for the
>> time
>> it takes to process the dependencies.  It's still slower than I'd
>> ideally
>> like, but it's a bit better.  If there's any way to make it even faster
>> I'd be interested.  I think what's there is technically correct though.
>
> I'm sorry I didn't have a chance to look at this sooner.
>
> Parsing dependencies out of the header files is far too heavy-weight
> for a find module.  We should memorize the known dependencies as
> is done for other find modules that provide imported targets.  If
> that is not tractable then the FindBoost module is the wrong place
> to solve this problem.

I do worry about the maintenance burden of hardcoding the information in
the script.  But if that's what's required I can look at doing this.

How should this cater for dependency changes between boost releases?
How far back in time does this dependency information need to go?

I can certainly write a script to manually trawl the headers for this
information, as done in this patch, and then embed that in FindBoost.cmake
(or put it in an ancillary script--might be easier to cater for multiple
versions this way?).

> FWIW, I think effort would be better spent working with Boost
> folks to get cmake package files provided.  They don't have to
> build with CMake to do this.  Qt5 for example builds without
> CMake but still provides CMake package files.

I already did some work towards this goal five years ago:

  https://svn.boost.org/trac/boost/ticket/1094

See the attached patches.  This was a proof of concept to introspect the
headers for generation of pkg-config files during the boost build (it uses
the compiler to dump the dependencies directly), but it could be trivially
updated for cmake configuration generation.  If I had any clue regarding
bjam internals, it would have been completed years ago, but I don't have
the expertise to integrate it to complete the task.

If there's anyone at all here who understands bjam, your help here would
be greatly appreciated by many people!


Regards,
Roger

-- 

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] [CPackDMG][Patch] Enable use of single license for multiple languages

[Brad King]

On 11/26/2015 08:00 AM, Levermann, Simon wrote:
> since license texts are often not translated into other languages, this
> patch enables the CPack DragnDrop generator to use a single license
> file for all languages instead of having to keep a copy of the same
> file around under multiple different names.

Applied with minor tweaks, thanks:

 CPack/DragNDrop: Allow single license for multiple languages
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=565661ea

-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] Qt4Macros generate resources with same file name

[Clinton Stimpson]

On Tuesday, November 24, 2015 11:01:27 AM Joseph Shen wrote:
> Dear CMake developers:
> 
> Please view attached small patch that try to fix Qt4Macros generate
> resources with same file name error.
> 
> Right now, in the CMake main branch, using cmake with Qt4 library
> add resources project can be done like this:
> 
>  qt4_add_resources(app_source_res res_a.qrc)
>  qt4_add_resources(app_source_res res_b.qrc)
> 
> and above two line added two resource file, but if we try to add resource
> file with same name, a very subtle error will happen: only one file will
> be compile the as resources, and the other was totally ignored.
> 
> In some big projects, using the same file name as resource file name
> can be very common, especially when we using multi cmake files try
> to make the whole project into small ones, in each cmake files someone
> maybe just using the same resources file name like res.qrc which is
> located in the sub module resources folder.
> 
>qt4_add_resources(app_source_res res.qrc)
> 
> so, if they try to do this, and in the last add ${app_source_res} to the
> dependency list using:
> 
>   add_executable(project_name ${app_source_res} ...)
> 
> but in reality they just add one resources file, but CMake do not report
> any error or warning.
> 
> From the source of Qt4Macros we can see:
> 
> line 211:   get_filename_component(outfilename ${it} NAME_WE)
> line 244:   ARGS ${rcc_options} -name ${outfilename} -o ${outfile} ${infile}
> 
> 
> became we just using NAME_WE as the output file, if two files with same
> file name, one will overwrite the other, and this is the reason why the
> error
> will happen.
> 
> To fix this, I view the whole Qt4Macros source file, find a function
> QT4_MAKE_OUTPUT_FILE already exist to do something just what we
> need. so I work out a patch add two line code and remove two, and it works
> good to me, and I think this might fix the problem.
> 
> Please view this patch, thanks :)


Back on list with a more concrete example, and also to prevent others from 
merging this patch, because I don't think this patch should be accepted.  The 
random string breaks using the Q_INIT_RESOURCE() macro.


For example:
===
project(qrc)

find_package(Qt4)
include(${QT_USE_FILE})

qt4_add_resources(qrc_srcs ${CMAKE_CURRENT_SOURCE_DIR}/my.qrc)

add_library(qrc STATIC ${qrc_srcs})

add_executable(main main.cpp)
target_link_libraries(main qrc)


main.cpp has:
int main()
{
  Q_INIT_RESOURCE(my);
}

With the patch applied, I now get the link error:

main.cpp:(.text+0x5): undefined reference to `qInitResources_my()'

"my" comes from the basename of my.qrc, and is the name used for the resource.
With CMake generating a random name, there would be no way to reference that 
name when calling Q_INIT_RESOURCE.

I would prefer allowing the caller to pass in an alternate -name option for 
rcc, as I said in my first review.  With that, the caller would be able to pass 
a random string.

Clint

-- 

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-commits] CMake branch, next, updated. v3.4.0-1531-gd8d7bbd

[Brad King]

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, next has been updated
   via  d8d7bbdb520b7a9b5d9be900a45d9c9559122179 (commit)
   via  58c1840a193d8cc5e0fca3e8300b6f9d93c3aeb1 (commit)
   via  eec87ec8a77550af5b39b95bead1d4be6a802637 (commit)
  from  f3123711dfcaea5e1e340e4b0203f23e8e5fc3d9 (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=d8d7bbdb520b7a9b5d9be900a45d9c9559122179
commit d8d7bbdb520b7a9b5d9be900a45d9c9559122179
Merge: f312371 58c1840
Author: Brad King 
AuthorDate: Mon Nov 30 10:21:40 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Nov 30 10:21:40 2015 -0500

Merge topic 'update-kwiml' into next

58c1840a Merge branch 'upstream-kwiml' into update-kwiml
eec87ec8 KWIML: Teach ABI.h that NIOS2 CPU is little-endian


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=58c1840a193d8cc5e0fca3e8300b6f9d93c3aeb1
commit 58c1840a193d8cc5e0fca3e8300b6f9d93c3aeb1
Merge: 99533c8 eec87ec
Author: Brad King 
AuthorDate: Mon Nov 30 10:18:24 2015 -0500
Commit: Brad King 
CommitDate: Mon Nov 30 10:18:24 2015 -0500

Merge branch 'upstream-kwiml' into update-kwiml


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=eec87ec8a77550af5b39b95bead1d4be6a802637
commit eec87ec8a77550af5b39b95bead1d4be6a802637
Author: Marek Vasut 
AuthorDate: Thu Nov 26 21:48:00 2015 +0100
Commit: Brad King 
CommitDate: Mon Nov 30 10:17:11 2015 -0500

KWIML: Teach ABI.h that NIOS2 CPU is little-endian

Signed-off-by: Marek Vasut 
Cc: Ley Foon Tan 
Cc: Thomas Chou 
Cc: Walter Goossens 

diff --git a/ABI.h.in b/ABI.h.in
index 6300ada..87b6e96 100644
--- a/ABI.h.in
+++ b/ABI.h.in
@@ -398,6 +398,10 @@ suppression macro @KWIML@_ABI_NO_VERIFY was defined.
 #elif defined(__mips) || defined(__mips__) || defined(__MIPS__)
 # define @KWIML@_ABI_ENDIAN_ID @KWIML@_ABI_ENDIAN_ID_BIG
 
+/* NIOS2 */
+#elif defined(__NIOS2__) || defined(__NIOS2) || defined(__nios2__)
+# define @KWIML@_ABI_ENDIAN_ID @KWIML@_ABI_ENDIAN_ID_LITTLE
+
 /* OpenRISC 1000 */
 #elif defined(__or1k__)
 # define @KWIML@_ABI_ENDIAN_ID @KWIML@_ABI_ENDIAN_ID_BIG

---

Summary of changes:
 Utilities/KWIML/ABI.h.in |4 
 1 file changed, 4 insertions(+)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

Re: [cmake-developers] [PATCH] Fix building on musl-libc

[Brad King]

On 11/25/2015 11:15 PM, Kylie McClain wrote:
> Hi, this is a really short patch that fixes building cmake on musl-libc.
>  #if defined( _MSC_VER )
>  typedef unsigned short mode_t;
> +#else
> +#include 
>  #endif

Thanks.  Does  work here instead?  It should provide mode_t:

 http://pubs.opengroup.org/onlinepubs/009696699/basedefs/sys/types.h.html

-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] Obtaining header file dependencies of a source file manually

[Brad King]

On 11/30/2015 01:56 PM, Dan Liew wrote:
> It doesn't look completely impossible. For Ninja, it looks like it has
> some support for compiler generated dependency files [2]

Yes, it may be possible for Ninja.

> There is an alternative which I suggested in the post. Have CMake
> determine the dependencies of the files passed to ``IMPLICIT_DEPENDS``
> at configure time and spit that into the build files of the generator
> (that would work for any generator). Then have any changes made to the
> files passed to ``IMPLICIT_DEPENDS`` trigger a reconfigure so that the
> dependencies can be recomputed.

Perhaps, but after regenerating the project the build tool will not
re-load the build files and start building again.  That will take
an additional invocation.  The number of iterations required is
bounded only by the depth of dependency chains.

It may be much easier to pack all this inside a separate
configure/build process using ExternalProject.

-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] [cmake-developers] Obtaining header file dependencies of a source file manually

[Brad King]

On 11/30/2015 01:56 PM, Dan Liew wrote:
> It doesn't look completely impossible. For Ninja, it looks like it has
> some support for compiler generated dependency files [2]

Yes, it may be possible for Ninja.

> There is an alternative which I suggested in the post. Have CMake
> determine the dependencies of the files passed to ``IMPLICIT_DEPENDS``
> at configure time and spit that into the build files of the generator
> (that would work for any generator). Then have any changes made to the
> files passed to ``IMPLICIT_DEPENDS`` trigger a reconfigure so that the
> dependencies can be recomputed.

Perhaps, but after regenerating the project the build tool will not
re-load the build files and start building again.  That will take
an additional invocation.  The number of iterations required is
bounded only by the depth of dependency chains.

It may be much easier to pack all this inside a separate
configure/build process using ExternalProject.

-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

Re: [cmake-developers] [CMake] Obtaining header file dependencies of a source file manually

[Dan Liew]

On 30 November 2015 at 18:35, Brad King  wrote:
> On 11/30/2015 01:32 PM, Dan Liew wrote:
>> It works but only for makefile generators... That's an annoying
>> limitation. I'll file a feature request to get this implemented for
>> other generators.
>
> It happens to work for Makefile generators because it was easy to
> implement since those generators already do their own scanning.
> For other generators it is not possible to implement.

Well I found the open issue [1]. It's been open for a while.

It doesn't look completely impossible. For Ninja, it looks like it has
some support for compiler
generated dependency files [2]. Incorporating that into
``add_custom_command()`` would require
an extra call to the host compiler to generate the dependencies when
the custom command is invoked.

For other generators that are Makefile or Ninja based I guess that
approach wouldn't work.

There is an alternative which I suggested in the post. Have CMake
determine the dependencies of the files passed to ``IMPLICIT_DEPENDS``
at configure
time and spit that into the build files of the generator (that would
work for any generator). Then have any changes made to the files
passed to ``IMPLICIT_DEPENDS``
trigger a reconfigure so that the dependencies can be recomputed. For
Makefiles you can don't need to do this and can take the "fast path"
instead.

[1] https://cmake.org/Bug/view.php?id=13234
[2] https://ninja-build.org/manual.html#_depfile

Dan.
-- 

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] [cmake-developers] Obtaining header file dependencies of a source file manually

[Dan Liew]

On 30 November 2015 at 18:35, Brad King  wrote:
> On 11/30/2015 01:32 PM, Dan Liew wrote:
>> It works but only for makefile generators... That's an annoying
>> limitation. I'll file a feature request to get this implemented for
>> other generators.
>
> It happens to work for Makefile generators because it was easy to
> implement since those generators already do their own scanning.
> For other generators it is not possible to implement.

Well I found the open issue [1]. It's been open for a while.

It doesn't look completely impossible. For Ninja, it looks like it has
some support for compiler
generated dependency files [2]. Incorporating that into
``add_custom_command()`` would require
an extra call to the host compiler to generate the dependencies when
the custom command is invoked.

For other generators that are Makefile or Ninja based I guess that
approach wouldn't work.

There is an alternative which I suggested in the post. Have CMake
determine the dependencies of the files passed to ``IMPLICIT_DEPENDS``
at configure
time and spit that into the build files of the generator (that would
work for any generator). Then have any changes made to the files
passed to ``IMPLICIT_DEPENDS``
trigger a reconfigure so that the dependencies can be recomputed. For
Makefiles you can don't need to do this and can take the "fast path"
instead.

[1] https://cmake.org/Bug/view.php?id=13234
[2] https://ninja-build.org/manual.html#_depfile

Dan.
-- 

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

Re: [CMake] [cmake-developers] Obtaining header file dependencies of a source file manually

[Dan Liew]

> For other generators that are Makefile or Ninja based I guess that
> approach wouldn't work.

Sorry that should read

For other generators that **aren't** Makefile or Ninja based I guess
that approach wouldn't work.
-- 

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

Re: [cmake-developers] Add CXX_STANDARD support for Intel C++ compilers

[Levi Morrison]

On Mon, Nov 30, 2015 at 11:33 AM, Brad King  wrote:
> On 11/30/2015 01:18 PM, Levi Morrison wrote:
>> My latest patch is attached. All tests seem to be working for me on
>> the compiler versions I have access to. Can you check it for any
>> glaring errors?
>
> Good.  This hunk:
>
>> +  if (NOT CMAKE_CXX_COMPILER_FORCED)
>> +if (NOT CMAKE_CXX_STANDARD_COMPUTED_DEFAULT)
>> +  set(CMAKE_CXX_STANDARD_DEFAULT 98)
>> +else()
>> +  set(CMAKE_CXX_STANDARD_DEFAULT ${CMAKE_CXX_STANDARD_COMPUTED_DEFAULT})
>> +endif()
>> +  endif()
>
> still needs to be revised to account for recent changes:
>
>  Project: Guess default standard dialect if compiler was forced (#15852)
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=441dba80
>
> If CMAKE_CXX_COMPILER_FORCED is set then we now fall back to a guess.
> Otherwise it is an error for CMAKE_CXX_STANDARD_COMPUTED_DEFAULT to
> not be set.
>
> Thanks,
> -Brad
>

Hmm. This was done already. Seems I just miscopied the patch again. I
don't know how many times I'll make this mistake before I quit doing
it :D.


0001-Add-CXX_STANDARD-support-to-Intel-C-compilers.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] Add command line options for deprecation message control

[Michael Scott]

Great, I've changed the nullptr references to NULL instead.

Cheers,
Michael
>From 02016a44d1f6f571b96c54a0008c37e2e1fa3b7d Mon Sep 17 00:00:00 2001
From: Michael Scott 
Date: Sun, 1 Nov 2015 16:05:15 +
Subject: [PATCH 1/8] Tests: Revise message in RunCMake.CommandLine -Wdev case

Use more prose-like capitalization.
---
 Tests/RunCMake/CommandLine/Wdev-stderr.txt | 2 +-
 Tests/RunCMake/CommandLine/Wdev.cmake  | 2 +-
 Tests/RunCMake/CommandLine/Wno-dev.cmake   | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/Tests/RunCMake/CommandLine/Wdev-stderr.txt b/Tests/RunCMake/CommandLine/Wdev-stderr.txt
index 92c1d23..88cfb3a 100644
--- a/Tests/RunCMake/CommandLine/Wdev-stderr.txt
+++ b/Tests/RunCMake/CommandLine/Wdev-stderr.txt
@@ -1,5 +1,5 @@
 ^CMake Warning \(dev\) at Wdev.cmake:1 \(message\):
-  Some Author Warning
+  Some author warning
 Call Stack \(most recent call first\):
   CMakeLists.txt:3 \(include\)
 This warning is for project developers.  Use -Wno-dev to suppress it.
diff --git a/Tests/RunCMake/CommandLine/Wdev.cmake b/Tests/RunCMake/CommandLine/Wdev.cmake
index e5026ef..756f31e 100644
--- a/Tests/RunCMake/CommandLine/Wdev.cmake
+++ b/Tests/RunCMake/CommandLine/Wdev.cmake
@@ -1,4 +1,4 @@
-message(AUTHOR_WARNING "Some Author Warning")
+message(AUTHOR_WARNING "Some author warning")
 
 # with -Wdev this will also cause an AUTHOR_WARNING message, checks that
 # messages issued outside of the message command, by other CMake commands, also
diff --git a/Tests/RunCMake/CommandLine/Wno-dev.cmake b/Tests/RunCMake/CommandLine/Wno-dev.cmake
index d81b858..802b435 100644
--- a/Tests/RunCMake/CommandLine/Wno-dev.cmake
+++ b/Tests/RunCMake/CommandLine/Wno-dev.cmake
@@ -1,4 +1,4 @@
-message(AUTHOR_WARNING "Some Author Warning")
+message(AUTHOR_WARNING "Some author warning")
 
 # without -Wno-dev this will also cause an AUTHOR_WARNING message, checks that
 # messages issued outside of the message command, by other CMake commands, also
-- 
2.5.0

>From 10801dab11c8e81ac351f725c37e30555f7febcf Mon Sep 17 00:00:00 2001
From: Michael Scott 
Date: Sun, 8 Nov 2015 12:20:47 +
Subject: [PATCH 2/8] Make message suppression more consistent.

Make the message suppression more consistent, by adding a check
for the message related CMake variables in cmake::IssueMessage,
which allows callers of IssueMessage other than the message
command to behave as expected. Also added a check for
CMAKE_SUPPRESS_DEVELOPER_WARNINGS in the message command to
mirror the deprecated message type behaviour.

Added a 'force' flag to the cmake::IssueMessage method, to
make the message suppression consistent, when setting the
message related CMake variables directly in a CMake file.

Expand message command tests to cover the AUTHOR_WARNING message
type as well.
---
 Source/cmMakefile.cxx |  8 +--
 Source/cmMakefile.h   |  3 +-
 Source/cmMessageCommand.cxx   | 12 -
 Source/cmake.cxx  | 70 ++-
 Source/cmake.h| 12 -
 Tests/RunCMake/message/nomessage.cmake|  4 ++
 Tests/RunCMake/message/warnmessage-stderr.txt | 11 -
 Tests/RunCMake/message/warnmessage.cmake  |  6 ++-
 8 files changed, 102 insertions(+), 24 deletions(-)

diff --git a/Source/cmMakefile.cxx b/Source/cmMakefile.cxx
index a1f143a..fd93a41 100644
--- a/Source/cmMakefile.cxx
+++ b/Source/cmMakefile.cxx
@@ -130,7 +130,8 @@ cmMakefile::~cmMakefile()
 
 //
 void cmMakefile::IssueMessage(cmake::MessageType t,
-  std::string const& text) const
+  std::string const& text,
+  bool force) const
 {
   // Collect context information.
   if(!this->ExecutionStatusStack.empty())
@@ -139,7 +140,8 @@ void cmMakefile::IssueMessage(cmake::MessageType t,
   {
   this->ExecutionStatusStack.back()->SetNestedError(true);
   }
-this->GetCMakeInstance()->IssueMessage(t, text, this->GetBacktrace());
+this->GetCMakeInstance()->IssueMessage(t, text, this->GetBacktrace(),
+   force);
 }
   else
 {
@@ -154,7 +156,7 @@ void cmMakefile::IssueMessage(cmake::MessageType t,
   lfc.FilePath = converter.Convert(lfc.FilePath, cmOutputConverter::HOME);
   }
 lfc.Line = 0;
-this->GetCMakeInstance()->IssueMessage(t, text, lfc);
+this->GetCMakeInstance()->IssueMessage(t, text, lfc, force);
 }
 }
 
diff --git a/Source/cmMakefile.h b/Source/cmMakefile.h
index 4215b72..e89f772 100644
--- a/Source/cmMakefile.h
+++ b/Source/cmMakefile.h
@@ -719,7 +719,8 @@ public:
   };
 
   void IssueMessage(cmake::MessageType t,
-std::string const& text) const;
+std::string const& text,
+bool 

[Cmake-commits] CMake branch, next, updated. v3.4.0-1538-g4ef2913

[Brad King]

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, next has been updated
   via  4ef291346729d0807a9a0f92b42b517941cf9809 (commit)
   via  0d8d36d0dc8f89116bf8b5a6f11bb367db2c23c0 (commit)
  from  a2d81f68df75eba057b47b96a7dcab81bee75ece (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=4ef291346729d0807a9a0f92b42b517941cf9809
commit 4ef291346729d0807a9a0f92b42b517941cf9809
Merge: a2d81f6 0d8d36d
Author: Brad King 
AuthorDate: Mon Nov 30 12:56:52 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Nov 30 12:56:52 2015 -0500

Merge topic 'cpack-dmg-multilanguage-sla' into next

0d8d36d0 fixup! CPack/DragNDrop: Allow single license for multiple languages


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0d8d36d0dc8f89116bf8b5a6f11bb367db2c23c0
commit 0d8d36d0dc8f89116bf8b5a6f11bb367db2c23c0
Author: Brad King 
AuthorDate: Mon Nov 30 12:50:25 2015 -0500
Commit: Brad King 
CommitDate: Mon Nov 30 12:50:25 2015 -0500

fixup! CPack/DragNDrop: Allow single license for multiple languages

diff --git a/Source/CPack/cmCPackDragNDropGenerator.cxx 
b/Source/CPack/cmCPackDragNDropGenerator.cxx
index 31665da..1a694ea 100644
--- a/Source/CPack/cmCPackDragNDropGenerator.cxx
+++ b/Source/CPack/cmCPackDragNDropGenerator.cxx
@@ -69,6 +69,7 @@ static const char* SLASTREnglish =
 
 //--
 cmCPackDragNDropGenerator::cmCPackDragNDropGenerator()
+  : singleLicense(false)
 {
   // default to one package file for components
   this->componentPackageMethod = ONE_PACKAGE;
diff --git a/Source/CPack/cmCPackDragNDropGenerator.h 
b/Source/CPack/cmCPackDragNDropGenerator.h
index 92ec845..b5e5ffe 100644
--- a/Source/CPack/cmCPackDragNDropGenerator.h
+++ b/Source/CPack/cmCPackDragNDropGenerator.h
@@ -48,7 +48,7 @@ protected:
 
 private:
   std::string slaDirectory;
-  bool singleLicense = false;
+  bool singleLicense;
 
   void WriteLicense(cmGeneratedFileStream& outputStream, int licenseNumber,
 std::string licenseLanguage, std::string licenseFile = "");

---

Summary of changes:
 Source/CPack/cmCPackDragNDropGenerator.cxx |1 +
 Source/CPack/cmCPackDragNDropGenerator.h   |2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

Re: [CMake] [cmake-developers] Obtaining header file dependencies of a source file manually

[Dan Liew]

Hi Michael,

> Not going into detail as I'm typing on the phone, but this really sounds
> like a case where a "SuperBuild"
> (http://www.kitware.com/media/html/BuildingExternalProjectsWithCMake2.8.html)
> can help you to simplify things a lot.

Thanks for the suggestion but this certainly is not a case where a
"SuperBuild" would help. CMake does not know how to configure a
compiler that can produce LLVM Bitcode so using a "SuperBuild" is not
going to help.

Dan.
-- 

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

Re: [cmake-developers] Add CXX_STANDARD support for Intel C++ compilers

[Brad King]

On 11/30/2015 01:18 PM, Levi Morrison wrote:
> My latest patch is attached. All tests seem to be working for me on
> the compiler versions I have access to. Can you check it for any
> glaring errors?

Good.  This hunk:

> +  if (NOT CMAKE_CXX_COMPILER_FORCED)
> +if (NOT CMAKE_CXX_STANDARD_COMPUTED_DEFAULT)
> +  set(CMAKE_CXX_STANDARD_DEFAULT 98)
> +else()
> +  set(CMAKE_CXX_STANDARD_DEFAULT ${CMAKE_CXX_STANDARD_COMPUTED_DEFAULT})
> +endif()
> +  endif()

still needs to be revised to account for recent changes:

 Project: Guess default standard dialect if compiler was forced (#15852)
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=441dba80

If CMAKE_CXX_COMPILER_FORCED is set then we now fall back to a guess.
Otherwise it is an error for CMAKE_CXX_STANDARD_COMPUTED_DEFAULT to
not be set.

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] Obtaining header file dependencies of a source file manually

[Dan Liew]

Hi Michael,

> Not going into detail as I'm typing on the phone, but this really sounds
> like a case where a "SuperBuild"
> (http://www.kitware.com/media/html/BuildingExternalProjectsWithCMake2.8.html)
> can help you to simplify things a lot.

Thanks for the suggestion but this certainly is not a case where a
"SuperBuild" would help. CMake does not know how to configure a
compiler that can produce LLVM Bitcode so using a "SuperBuild" is not
going to help.

Dan.
-- 

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] Obtaining header file dependencies of a source file manually

[Dan Liew]

Hi,

On 30 November 2015 at 18:03, Dan Liew  wrote:
> Hi,
>
> On 30 November 2015 at 08:09, Petr Kmoch  wrote:
>> Hi Dan,
>>
>> you could look into the IMPLICIT_DEPENDS argument of add_custom_command:
>> https://cmake.org/cmake/help/latest/command/add_custom_command.html
>>
>> I don't have direct experience with it, but it looks like it could do what
>> you're looking for.
>
> Oh. That sounds exactly like what I'm looking for!

It works but only for makefile generators... That's an annoying
limitation. I'll file a feature request to get this implemented for
other generators.

Dan.
-- 

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] [cmake-developers] Obtaining header file dependencies of a source file manually

[Brad King]

On 11/30/2015 01:32 PM, Dan Liew wrote:
> It works but only for makefile generators... That's an annoying
> limitation. I'll file a feature request to get this implemented for
> other generators.

It happens to work for Makefile generators because it was easy to
implement since those generators already do their own scanning.
For other generators it is not possible to implement.

-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

Re: [cmake-developers] [PATCH] FindBoost: Add imported targets

[Brad King]

On 11/30/2015 11:54 AM, rle...@codelibre.net wrote:
> I do worry about the maintenance burden of hardcoding the information in
> the script.

I do too.  We already have to update the script for each Boost release.
This is among the reasons the work is better integrated with upstream
Boost instead.

> How should this cater for dependency changes between boost releases?
> How far back in time does this dependency information need to go?

One would need to fill out tables per version and then detect the
version to populate the info.  Just don't provide imported targets
if the version does not have dependency info available.  If someone
needs it they can run something to fill out the tables for their
version and submit a patch.

> I already did some work towards this goal five years ago:
> 
>   https://svn.boost.org/trac/boost/ticket/1094
> 
> See the attached patches.  This was a proof of concept to introspect the
> headers for generation of pkg-config files during the boost build (it uses
> the compiler to dump the dependencies directly), but it could be trivially
> updated for cmake configuration generation.  If I had any clue regarding
> bjam internals, it would have been completed years ago, but I don't have
> the expertise to integrate it to complete the task.
> 
> If there's anyone at all here who understands bjam, your help here would
> be greatly appreciated by many people!

I'm not familiar with bjam or Boost Build v2 enough to help.  However,
once this work is done the problem will be solved and mostly free of
maintenance moving forward.  In the long run, figuring it out there
will be less work than maintaining a huge amount of information in
FindBoost.

-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] [cmake-developers] Obtaining header file dependencies of a source file manually

[Dan Liew]

Hi,

On 30 November 2015 at 08:09, Petr Kmoch  wrote:
> Hi Dan,
>
> you could look into the IMPLICIT_DEPENDS argument of add_custom_command:
> https://cmake.org/cmake/help/latest/command/add_custom_command.html
>
> I don't have direct experience with it, but it looks like it could do what
> you're looking for.

Oh. That sounds exactly like what I'm looking for!

Thanks,
Dan.
-- 

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

Re: [cmake-developers] Obtaining header file dependencies of a source file manually

[Dan Liew]

Hi,

On 30 November 2015 at 08:09, Petr Kmoch  wrote:
> Hi Dan,
>
> you could look into the IMPLICIT_DEPENDS argument of add_custom_command:
> https://cmake.org/cmake/help/latest/command/add_custom_command.html
>
> I don't have direct experience with it, but it looks like it could do what
> you're looking for.

Oh. That sounds exactly like what I'm looking for!

Thanks,
Dan.
-- 

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] Add command line options for deprecation message control

[Brad King]

On 11/29/2015 08:48 AM, Michael Scott wrote:
> I've gone back and redone the patches with the suggestions you made

Thanks.  This is in pretty good shape now I think.  However, I see
use of `nullptr`.  Please revise to use only C++98 constructs.

-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-commits] CMake branch, release, updated. v3.4.0-35-gf8deadc

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, release has been updated
   via  f8deadc16d03233ecb92b4d05a9e9f0d6c9f56aa (commit)
   via  5f860ebb67e86e0aa407e26ddf79652f73742211 (commit)
   via  f21dc4a81c05c79b873c9918f6fe8aff4bf02133 (commit)
   via  bc1d3a8a8783848016ef12044a02a28b620c41a0 (commit)
   via  85fe26b5f742b704b51a7e15b4806366feab3a23 (commit)
   via  518d6b22f6705c4747c713031587705641540364 (commit)
   via  9ecf8a14fb4a12178a7bb97a87dee3fada3204d5 (commit)
   via  32edac6fddfbe91e47b34506cda855232d5a9e2c (commit)
   via  0fa7f143a08b62459900bd811c2c0674562bb8be (commit)
   via  d85c9176ae15f4fb203e501d777cfce8304bf256 (commit)
   via  8e1be7bf688dc282408aa0403e9896fa5a142ec4 (commit)
   via  62126b67e0048800a833d3c4ea86d2307f1a4a06 (commit)
   via  2e28c619f8997a2b86c72b53659be371ff10a790 (commit)
   via  b219ff94acf0b6c934c35e2ce42dfbf99580f1e8 (commit)
   via  378185fb7f672113257502ef96cf7106c22dd39f (commit)
   via  c25d642de38730cdb6627a2c2d47f85e8c470974 (commit)
   via  010c5959864a10f4b83907fb058006e118dd740d (commit)
   via  5e3045a749b34fb87c876af9a42ee190d722bada (commit)
   via  9682de566e264c53018cccd05465f2c5d91ccf73 (commit)
  from  e3dfa3506c0589cb4c3e91107e560c2495cdc257 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
---

Summary of changes:
 Modules/CMakeCCompiler.cmake.in|1 -
 Modules/CMakeCInformation.cmake|4 -
 Modules/CMakeCXXCompiler.cmake.in  |1 -
 Modules/CMakeCXXInformation.cmake  |4 -
 Modules/CMakeDetermineCompilerId.cmake |8 --
 Modules/CMakeFortranCompiler.cmake.in  |1 -
 Modules/CMakeFortranInformation.cmake  |4 -
 Source/cmLinkedTree.h  |   33 +--
 Source/cmListFileCache.cxx |   15 +++
 Source/cmListFileCache.h   |6 +-
 Source/cmLocalGenerator.cxx|6 +-
 Source/cmMakefile.cxx  |   28 +++---
 Source/cmMakefile.h|8 +-
 Source/cmState.cxx |   96 +---
 Source/cmState.h   |1 +
 .../NotClosed-result.txt}  |0
 Tests/RunCMake/PolicyScope/NotClosed-stderr.txt|4 +
 Tests/RunCMake/PolicyScope/NotClosed.cmake |1 +
 .../NotOpened-result.txt}  |0
 Tests/RunCMake/PolicyScope/NotOpened-stderr.txt|4 +
 Tests/RunCMake/PolicyScope/NotOpened.cmake |1 +
 Tests/RunCMake/PolicyScope/RunCMakeTest.cmake  |2 +
 .../RunCMake/add_subdirectory/Function-stdout.txt  |   10 ++
 Tests/RunCMake/add_subdirectory/Function.cmake |   17 
 .../add_subdirectory/Function/CMakeLists.txt   |5 +
 Tests/RunCMake/add_subdirectory/RunCMakeTest.cmake |1 +
 .../PolicyPop-result.txt}  |0
 Tests/RunCMake/find_package/PolicyPop-stderr.txt   |5 +
 Tests/RunCMake/find_package/PolicyPop.cmake|1 +
 .../find_package/PolicyPop/PolicyPopConfig.cmake   |0
 .../PolicyPop/PolicyPopConfigVersion.cmake |3 +
 .../PolicyPush-result.txt} |0
 Tests/RunCMake/find_package/PolicyPush-stderr.txt  |5 +
 Tests/RunCMake/find_package/PolicyPush.cmake   |1 +
 .../find_package/PolicyPush/PolicyPushConfig.cmake |0
 .../PolicyPush/PolicyPushConfigVersion.cmake   |3 +
 Tests/RunCMake/find_package/RunCMakeTest.cmake |2 +
 37 files changed, 190 insertions(+), 91 deletions(-)
 copy Tests/RunCMake/{CMP0004/CMP0004-NEW-result.txt => 
PolicyScope/NotClosed-result.txt} (100%)
 create mode 100644 Tests/RunCMake/PolicyScope/NotClosed-stderr.txt
 create mode 100644 Tests/RunCMake/PolicyScope/NotClosed.cmake
 copy Tests/RunCMake/{CMP0004/CMP0004-NEW-result.txt => 
PolicyScope/NotOpened-result.txt} (100%)
 create mode 100644 Tests/RunCMake/PolicyScope/NotOpened-stderr.txt
 create mode 100644 Tests/RunCMake/PolicyScope/NotOpened.cmake
 create mode 100644 Tests/RunCMake/add_subdirectory/Function-stdout.txt
 create mode 100644 Tests/RunCMake/add_subdirectory/Function.cmake
 create mode 100644 Tests/RunCMake/add_subdirectory/Function/CMakeLists.txt
 copy Tests/RunCMake/{CMP0004/CMP0004-NEW-result.txt => 
find_package/PolicyPop-result.txt} (100%)
 create mode 100644 Tests/RunCMake/find_package/PolicyPop-stderr.txt
 create mode 100644 

[Cmake-commits] CMake branch, master, updated. v3.4.0-624-g2218962

[Brad King]

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  2218962dbdc7f552a076978a0393433091aa35c4 (commit)
   via  f8deadc16d03233ecb92b4d05a9e9f0d6c9f56aa (commit)
   via  9ecf8a14fb4a12178a7bb97a87dee3fada3204d5 (commit)
   via  c25d642de38730cdb6627a2c2d47f85e8c470974 (commit)
   via  5e3045a749b34fb87c876af9a42ee190d722bada (commit)
  from  3c6a3668760ba48dde33f20de08dc6e16cfe7ab3 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
---

Summary of changes:


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, next, updated. v3.4.0-1544-g1d0b45a

[Brad King]

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, next has been updated
   via  1d0b45af79dee7fbf4ca3cc88b5da61654e57ba0 (commit)
   via  2218962dbdc7f552a076978a0393433091aa35c4 (commit)
   via  f8deadc16d03233ecb92b4d05a9e9f0d6c9f56aa (commit)
   via  9ecf8a14fb4a12178a7bb97a87dee3fada3204d5 (commit)
   via  c25d642de38730cdb6627a2c2d47f85e8c470974 (commit)
   via  5e3045a749b34fb87c876af9a42ee190d722bada (commit)
  from  4ef291346729d0807a9a0f92b42b517941cf9809 (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=1d0b45af79dee7fbf4ca3cc88b5da61654e57ba0
commit 1d0b45af79dee7fbf4ca3cc88b5da61654e57ba0
Merge: 4ef2913 2218962
Author: Brad King 
AuthorDate: Mon Nov 30 13:12:02 2015 -0500
Commit: Brad King 
CommitDate: Mon Nov 30 13:12:02 2015 -0500

Merge branch 'master' into next


---

Summary of changes:


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, next, updated. v3.4.0-1546-gd5dcfed

[Brad King]

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, next has been updated
   via  d5dcfed6747cda9f835988bd3d02ec4b4864fc54 (commit)
   via  117d49b8b7671b7ad2901de444da725eda8ea8cc (commit)
  from  1d0b45af79dee7fbf4ca3cc88b5da61654e57ba0 (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=d5dcfed6747cda9f835988bd3d02ec4b4864fc54
commit d5dcfed6747cda9f835988bd3d02ec4b4864fc54
Merge: 1d0b45a 117d49b
Author: Brad King 
AuthorDate: Mon Nov 30 14:59:41 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Nov 30 14:59:41 2015 -0500

Merge topic 'intel-compiler-features' into next

117d49b8 Features: Record standards and features for Intel C++ on UNIX


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=117d49b8b7671b7ad2901de444da725eda8ea8cc
commit 117d49b8b7671b7ad2901de444da725eda8ea8cc
Author: Levi Morrison 
AuthorDate: Mon Nov 16 09:19:30 2015 -0700
Commit: Brad King 
CommitDate: Mon Nov 30 14:38:38 2015 -0500

Features: Record standards and features for Intel C++ on UNIX

diff --git a/Help/release/dev/intel-compiler-features.rst 
b/Help/release/dev/intel-compiler-features.rst
new file mode 100644
index 000..f154dc9
--- /dev/null
+++ b/Help/release/dev/intel-compiler-features.rst
@@ -0,0 +1,6 @@
+intel-compiler-features
+---
+
+* The :manual:`Compile Features ` functionality
+  is now aware of features supported by Intel C++ compilers versions 12.1
+  through 16.0 on UNIX platforms.
diff --git a/Modules/Compiler/Intel-CXX-FeatureTests.cmake 
b/Modules/Compiler/Intel-CXX-FeatureTests.cmake
new file mode 100644
index 000..95792b0
--- /dev/null
+++ b/Modules/Compiler/Intel-CXX-FeatureTests.cmake
@@ -0,0 +1,90 @@
+# References:
+#   - 
https://software.intel.com/en-us/articles/c0x-features-supported-by-intel-c-compiler
+#   - 
https://software.intel.com/en-us/articles/c14-features-supported-by-intel-c-compiler
+
+# these are not implemented in any version at time of writing
+#set(_cmake_feature_test_cxx_variable_templates "${Intel15_CXX14}")
+#set(_cmake_feature_test_cxx_relaxed_constexpr "${Intel15_CXX14}")
+
+# unknown if this is implemented
+#set(_cmake_feature_test_cxx_aggregate_default_initializers "${Intel15_CXX14}")
+
+set(DETECT_CXX11 "((__cplusplus >= 201103L) ||  defined(__INTEL_CXX11_MODE__) 
|| defined(__GXX_EXPERIMENTAL_CXX0X__))")
+set(DETECT_CXX14 "((__cplusplus >= 201103L) && 
!defined(__INTEL_CXX11_MODE__))")
+
+set(Intel16_CXX14 "__ICC >= 1600 && ${DETECT_CXX14}")
+set(_cmake_feature_test_cxx_contextual_conversions "${Intel16_CXX14}")
+set(_cmake_feature_test_cxx_generic_lambdas "${Intel16_CXX14}")
+set(_cmake_feature_test_cxx_digit_separators "${Intel16_CXX14}")
+# This test is supposed to work in Intel 14 but the compiler has a bug
+# in versions 14 and 15::
+# https://software.intel.com/en-us/forums/intel-c-compiler/topic/600514
+set(_cmake_feature_test_cxx_generalized_initializers "${Intel16_CXX14}")
+
+set(Intel15_CXX14 "__ICC >= 1500 && ${DETECT_CXX14}")
+set(_cmake_feature_test_cxx_decltype_auto "${Intel15_CXX14}")
+set(_cmake_feature_test_cxx_lambda_init_captures "${Intel15_CXX14}")
+set(_cmake_feature_test_cxx_attribute_deprecated "${Intel15_CXX14}")
+set(_cmake_feature_test_cxx_return_type_deduction "${Intel15_CXX14}")
+
+set(Intel15_CXX11 "__ICC >= 1500 && ${DETECT_CXX11}")
+set(_cmake_feature_test_cxx_alignas "${Intel15_CXX11}")
+set(_cmake_feature_test_cxx_alignof "${Intel15_CXX11}")
+set(_cmake_feature_test_cxx_inheriting_constructors "${Intel15_CXX11}")
+set(_cmake_feature_test_cxx_user_literals "${Intel15_CXX11}")
+set(_cmake_feature_test_cxx_thread_local "${Intel15_CXX11}")
+
+set(Intel14_CXX11 "${DETECT_CXX11} && (__ICC > 1400 || (__ICC == 1400 && 
__INTEL_COMPILER_UPDATE >= 2))")
+# Documented as 12.0+ but in testing it only works on 14.0.2+
+set(_cmake_feature_test_cxx_decltype_incomplete_return_types 
"${Intel14_CXX11}")
+
+set(Intel14_CXX11 "__ICC >= 1400 && ${DETECT_CXX11}")
+set(_cmake_feature_test_cxx_delegating_constructors "${Intel14_CXX11}")
+set(_cmake_feature_test_cxx_constexpr "${Intel14_CXX11}")
+set(_cmake_feature_test_cxx_sizeof_member "${Intel14_CXX11}")
+set(_cmake_feature_test_cxx_strong_enums "${Intel14_CXX11}")
+set(_cmake_feature_test_cxx_reference_qualified_functions "${Intel14_CXX11}")
+set(_cmake_feature_test_cxx_raw_string_literals "${Intel14_CXX11}")
+set(_cmake_feature_test_cxx_unicode_literals "${Intel14_CXX11}")
+set(_cmake_feature_test_cxx_inline_namespaces "${Intel14_CXX11}")

Re: [CMake] [cmake-developers] Obtaining header file dependencies of a source file manually

[Michael Wild]

On Mon, Nov 30, 2015 at 7:01 PM, Dan Liew  wrote:
> Hi Michael,
>
>> Not going into detail as I'm typing on the phone, but this really sounds
>> like a case where a "SuperBuild"
>> (http://www.kitware.com/media/html/BuildingExternalProjectsWithCMake2.8.html)
>> can help you to simplify things a lot.
>
> Thanks for the suggestion but this certainly is not a case where a
> "SuperBuild" would help. CMake does not know how to configure a
> compiler that can produce LLVM Bitcode so using a "SuperBuild" is not
> going to help.
>
> Dan.


Hi Dan

I fail to see why that should not work. Producing LLVM bitcode from
C++ with Clang is just adding -emit-llvm flag, right? So, why can't
the SuperBuild configure the child build to use Clang and this flag?
And Bob's your uncle...

Michael
-- 

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

Re: [cmake-developers] Obtaining header file dependencies of a source file manually

[Michael Wild]

On Mon, Nov 30, 2015 at 7:01 PM, Dan Liew  wrote:
> Hi Michael,
>
>> Not going into detail as I'm typing on the phone, but this really sounds
>> like a case where a "SuperBuild"
>> (http://www.kitware.com/media/html/BuildingExternalProjectsWithCMake2.8.html)
>> can help you to simplify things a lot.
>
> Thanks for the suggestion but this certainly is not a case where a
> "SuperBuild" would help. CMake does not know how to configure a
> compiler that can produce LLVM Bitcode so using a "SuperBuild" is not
> going to help.
>
> Dan.


Hi Dan

I fail to see why that should not work. Producing LLVM bitcode from
C++ with Clang is just adding -emit-llvm flag, right? So, why can't
the SuperBuild configure the child build to use Clang and this flag?
And Bob's your uncle...

Michael
-- 

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] Best way to handle application data path for local run vs. installation

[Alexander Neundorf]

On Monday, November 30, 2015 16:13:03 Ruslan Baratov via CMake 
wrote:
> On 30-Nov-15 09:10, Dmitry Marakasov wrote:
> > Hi!
> > 
...
> > The best solution would be for cmake to fix path in executable file
> > right after installation, something similar to what cmake does with
> > rpaths.
> 
> I doubt there is a general way to patch data section with string in
> executable. At least with different size and in safe manner. For 
example
> Clang is smart enough to figure out 'strlen' of literal string at
> compile time, so changing string affects logic and hence is 
dangerous.
> And rpaths unlike data is designed to be modifiable 

Not really. CMake has extra code to make sure the build rpath is as long 
as the install rpath will be, so it can be patched in later.

> (e.g. see
> install_name_tool for OS X) so it's okay to hack it back and forth.
> 
> Second thought is that when you hardcode path in executable you 
make it
> non-relocatable. 

E.g. on Linux $ORIGIN could be used in the RPATH.

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

Re: [CMake] Best way to handle application data path for local run vs. installation

[Ruslan Baratov via CMake]

On 01-Dec-15 03:51, Alexander Neundorf wrote:


On Monday, November 30, 2015 16:13:03 Ruslan Baratov via CMake wrote:

> On 30-Nov-15 09:10, Dmitry Marakasov wrote:

> > Hi!

> >

...

> > The best solution would be for cmake to fix path in executable file

> > right after installation, something similar to what cmake does with

> > rpaths.

>

> I doubt there is a general way to patch data section with string in

> executable. At least with different size and in safe manner. For example

> Clang is smart enough to figure out 'strlen' of literal string at

> compile time, so changing string affects logic and hence is dangerous.

> And rpaths unlike data is designed to be modifiable

Not really. CMake has extra code to make sure the build rpath is as 
long as the install rpath will be, so it can be patched in later.



Well, that's exactly what I said - RPATH can be patched.


> (e.g. see

> install_name_tool for OS X) so it's okay to hack it back and forth.

>

> Second thought is that when you hardcode path in executable you make it

> non-relocatable.

E.g. on Linux $ORIGIN could be used in the RPATH.

Alex

It's not about RPATH, it's about string literal with path in C++ code. 
E.g. if you have:

const char* resources = "/usr/share/foo"

and installing your package to "/home/username/tools" then executable 
will not find resources since there is no files in "/usr/share/foo"


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

Re: [CMake] Best way to handle application data path for local run vs. installation

[Daniel Schepler]

For what it's worth, what we do here is have the executable search for a file 
named paths.cfg in the same directory it's located in, and read settings from 
that file to get the paths to load resources from.  Then our CMake system is 
set up to create one paths.cfg when building, and another when installing.  Of 
course, we use Qt which makes it easy both to get the executable location 
directory (which you mentioned you don't want to do), and to read a 
configuration file.  Also, our installation is designed to be in a 
self-contained directory, e.g. /opt/Scalable/product; but in an installation to 
system directories, you wouldn't want to clutter /usr/bin with a paths.cfg 
file, so you would probably want to have a hard-coded system directory fallback 
compiled in to use if paths.cfg doesn't exist.

A possible hack that just occurred to me: maybe you could make use of the 
different RPATH by compiling a simple path configuration "plugin" - the 
executable would try to dlopen("mypaths.so") and if that's found call functions 
in the plugin to get the paths.  The plugin would only be compiled in the build 
directory, and not installed.  Of course, that would be totally non-portable to 
Windows.
-- 
Daniel Schepler

From: CMake [cmake-boun...@cmake.org] on behalf of Dmitry Marakasov 
[amd...@amdmi3.ru]
Sent: Sunday, November 29, 2015 6:10 PM
To: cmake@cmake.org
Subject: [CMake] Best way to handle application data path for local run vs. 
installation

Hi!

This question bugs me for a long time so I though maybe someone has
a solution. I have a project which includes an application and some
data for it. An application needs to know path to its data files, so
I pass it via compiler definition: ADD_DEFINITIONS(-DDATADIR="...")

The problem is that this path is different based on whether I want to
run the application from build directory:

ADD_DEFINITIONS(-DDATADIR="${PROJECT_SOURCE_DIR}/data")

or want to install it systemwide:

ADD_DEFINITIONS(-DDATADIR="${CMAKE_INSTALL_PREFIX}/share/myapp")

I want my project to both run from build directory and to be
installable systemwide, without the need to rebuild or specify extra
options.

- I don't want to make an applications search for its data relative
  to executable path
  - There's no cross-platform way to get an executable path
  - This will break when executable is moved or hardlinked
- I don't want to try both paths, as this is error prone, as installed
  executable may pick data files from repository or vice versa
- I don't want to make user specify additional cmake flags like
  -DSYSTEMWIDE_INSTALLATION or -DRUN_LOCALLY.
- I don't want to use any wrapper scripts
- I don't want to build two executables

The best solution would be for cmake to fix path in executable file
right after installation, something similar to what cmake does with
rpaths. Or there could be a cross-platform way for executable to know
whether it was installed which I've missed.

Any ideas?

--
Dmitry Marakasov   .   55B5 0596 FF1E 8D84 5F56  9510 D35A 80DD F9D2 F77D
amd...@amdmi3.ru  ..:  jabber: amd...@jabber.ru  http://amdmi3.ru
--

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

-- 

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

[Cmake-commits] CMake branch, master, updated. v3.4.0-625-ga6f5281

[Kitware Robot]

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  a6f5281419c59b433f248b41972530242172a124 (commit)
  from  2218962dbdc7f552a076978a0393433091aa35c4 (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=a6f5281419c59b433f248b41972530242172a124
commit a6f5281419c59b433f248b41972530242172a124
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Tue Dec 1 00:01:08 2015 -0500
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Tue Dec 1 00:01:08 2015 -0500

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 0f9b810..993d72c 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,5 +1,5 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 4)
-set(CMake_VERSION_PATCH 20151130)
+set(CMake_VERSION_PATCH 20151201)
 #set(CMake_VERSION_RC 1)

---

Summary of changes:
 Source/CMakeVersion.cmake |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[cmake-developers] Fwd: [PATCH] Fix building on musl-libc

[Kylie McClain]

On Mon, Nov 30, 2015 at 10:40 AM, Brad King  wrote:
> Does  work here instead?

Yes, appears to work just fine.

(sorry for any duplicate messages, meant to send this message to
the mailing list as well, not just to 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 0015868]: Property INSTALL_NAME_DIR is completely ignored

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://cmake.org/Bug/view.php?id=15868 
== 
Reported By:Lucas Christian
Assigned To:
== 
Project:CMake
Issue ID:   15868
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2015-11-30 22:58 EST
Last Modified:  2015-11-30 22:58 EST
== 
Summary:Property INSTALL_NAME_DIR is completely ignored
Description: 
CMake ignores the INSTALL_NAME_DIR property unless the following properties are
set:
- BUILD_WITH_INSTALL_RPATH is TRUE
- SKIP_RPATH is FALSE
- SKIP_INSTALL_RPATH is FALSE

In some cases, users may wish to use INSTALL_NAME_DIR without having any
intention of using any path-related features.  For example, I may want my
executables to link to libraries encoding the absolute path "/usr/local/lib" in
the executable for each library.  This has nothing to do with rpath.

In both the build tree and install destination, the emitted library name is
"@rpath/mylib.dylib" despite explicitly setting INSTALL_NAME_DIR otherwise. 
Enabling BUILD_WITH_INSTALL_RPATH does cause the correct path to be emitted, but
this requirement is not obvious, and likely unintentional.

Steps to Reproduce: 
Produce a simple CMake file that builds an executable against a shared library. 
Set these to install into /usr/local root.

Include set(CMAKE_INSTALL_NAME_DIR "/usr/local/lib")

Additional Information: 
Cursory examination of the CMake source code suggests this issue may be rooted
in "cmGeneratorTarget.cxx", likely the code for generating install_path is
getting short-circuited by some additional checks on the rpath* properties.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-11-30 22:58 Lucas ChristianNew 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] [cmake-developers] Obtaining header file dependencies of a source file manually

[Petr Kmoch]

Hi Dan,

you could look into the IMPLICIT_DEPENDS argument of add_custom_command:
https://cmake.org/cmake/help/latest/command/add_custom_command.html

I don't have direct experience with it, but it looks like it could do what
you're looking for.

Petr

On Sun, Nov 29, 2015 at 10:47 AM, Dan Liew  wrote:

> Hi,
>
> # TL;DR
>
> I need a way of determining the header file dependencies of a source
> file and inform CMake about them. CMake doesn't do this automatically
> because I'm using custom commands for the compilation step so CMake
> doesn't do it's usual magic of automatically inferring source file
> header dependencies. This is because this part of the compilation step
> requires a separate C++ compiler (completely independent from the one
> that CMake detects at configure time).
>
> Is there a way of doing this that will also regenerate the
> dependencies if the source file changes?
>
> # Long version
>
> A C++ project that I work on [1] is (amongst other things) a compiler.
> In order to compile applications it needs to link in a supporting
> runtime that is compiled to LLVM bitcode which is linked into the
> applications it compiles.
>
> The supporting runtime is written in C++ and compiled with Clang. The
> compilation of the runtime is currently achieved using
> ``add_custom_command()`` and so I am not using CMake's in built
> support for detecting header file dependencies. The reason for doing
> it this way is because the LLVM bitcode compiler (i.e. Clang) **is
> not** the same compiler as the host C++ compiler for the project. For
> example the host code might be built with MSVC but the supporting
> runtime is **always** built with Clang.
>
> To see this concretely take a look at [2].
>
> The build works correctly if you build from a clean build directory.
> It does not work correctly if you perform a rebuild and change one of
> the header files that the supporting runtime depends on. This is
> because CMake doesn't know that the runtime source files depend on the
> header files and so doesn't rebuild the relevant source files.
>
> I can obviously tell CMake about these manually (adding more entries
> under ``DEPENDS`` in the ``add_custom_command()`` invocation) but this
> is very cumbersome.
>
> What I really need is a way to
>
> * Automatically infer the dependencies of a source file and tell CMake
> about them
> * Have the dependencies automatically regenerated if the source file
> changes (someone could add or remove a header file include).
>
> In a simple Makefile build system this typically achieved by doing
> something like this:
>
> ```
> all:: $(SRCS:.cpp:.o)
>
> SRCS := foo.cpp bar.cpp
>
> # Include SRC file dependencies generated by the compiler if they exist
> -include $(SRCs:.cpp=.d)
>
> %.o : %.cpp
>   $(CXX) -c $< -o $@ -MP -MMD -MF $*.d
> ```
>
> Note the ``-M*`` flags get the compiler when it runs to generate
> additional makefile rules that will get included next time a build
> happens.
>
> I don't really know how to do the same thing with CMake. One idea is
> at configure time invoke Clang with the ``-MP -MMD -MF`` flags on each
> runtime source file, extract the dependencies then pass them to
> ``DEPENDS`` in ``add_custom_command()``. If I wanted the dependencies
> regenerated if the runtime source file changes then I would need to
> somehow get CMake to reconfigure every time this happens.
>
> I don't like this idea very much due to
>
> * Having to invoke Clang manually to determine the dependencies. CMake
> already knows how to determine source file dependencies, but this
> functionality (AFAIK) isn't exposed to me.
>
> * Reconfiguring every time one of the runtime source file changes is
> annoying (configuring can be slow sometimes).
>
> Does anyone have any other ideas? CMake obviously knows how to do all
> this stuff already for source files being compiled for the detected
> host C++ compiler, I just don't know how to get at this logic for
> source files that need to be built with a second independent C++
> compiler.
>
> [1] https://github.com/halide/Halide
> [2] https://github.com/halide/Halide/blob/master/src/CMakeLists.txt#L140
>
> Thanks,
> Dan.
> --
>
> 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 

Re: [CMake] Best way to handle application data path for local run vs. installation

[Dmitry Marakasov]

* Ruslan Baratov (ruslan_bara...@yahoo.com) wrote:

> > - I don't want to make an applications search for its data relative
> >to executable path
> >- There's no cross-platform way to get an executable path
> It's tricky but not impossible. Might be helpful:
> * http://stackoverflow.com/a/1024937/2288008
> * 
> https://github.com/Kitware/CMake/blob/31b013b14ad3bf4838f4ba327b5392018f4853b6/Source/cmSystemTools.cxx#L2227
>  
> (see exe_dir)

I know how it is done - I've patched numberless applications which
only used /proc to work on FreeBSD, and that's why I absolutely
don't want to go this way.

Also this doesn't solve the problem of moving binary around without
moving data.

> >- This will break when executable is moved or hardlinked
> > - I don't want to try both paths, as this is error prone, as installed
> >executable may pick data files from repository or vice versa
> > - I don't want to make user specify additional cmake flags like
> >-DSYSTEMWIDE_INSTALLATION or -DRUN_LOCALLY.
> > - I don't want to use any wrapper scripts
> > - I don't want to build two executables
> ...
> 
> > The best solution would be for cmake to fix path in executable file
> > right after installation, something similar to what cmake does with
> > rpaths.
> I doubt there is a general way to patch data section with string in 
> executable. At least with different size and in safe manner. For example 
> Clang is smart enough to figure out 'strlen' of literal string at 
> compile time, so changing string affects logic and hence is dangerous. 

I know that changing data is tricky, but I though more of something
like having both paths compiled in and switching by changing a
constant length data.

> And rpaths unlike data is designed to be modifiable (e.g. see 
> install_name_tool for OS X) so it's okay to hack it back and forth.
> 
> Second thought is that when you hardcode path in executable you make it 
> non-relocatable. E.g. it's not possible to pack it to .dmg installer so 
> user can unpack it wherever he wants.

Hmm, I didn't think of that, probably some other systems may need
this as well.

Though I just understood that this problem is different than the one
of making cmake produce executable suitable for both inplace run
and installation: even if I produce a relocatable binary, I /still/
needs different (relative) paths to data for inplace/systemwide
cases.

Anyway for now, I did some research and solved the problem of inplace
vs. systemwide compilation in a way that I find acceptable.

I check for CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT to basically
know whether a user has explicitly specified CMAKE_INSTALL_PREFIX.
If user specified install prefix, I prepare for systemwide install,
otherwise I prepare for inplace run.

https://github.com/AMDmi3/hoverboard-sdl/blob/0.4.0/CMakeLists.txt

This doesn't support inplace and systemwide /at the same time/, but
still supports either of them cleanly, doesn't require extra actions
from user and behaves sensibly by default.

-- 
Dmitry Marakasov   .   55B5 0596 FF1E 8D84 5F56  9510 D35A 80DD F9D2 F77D
amd...@amdmi3.ru  ..:  jabber: amd...@jabber.ru  http://amdmi3.ru
-- 

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

Re: [CMake] Best way to handle application data path for local run vs. installation

[Bill Somerville]

On 30/11/2015 02:10, Dmitry Marakasov wrote:

Hi!

This question bugs me for a long time so I though maybe someone has
a solution. I have a project which includes an application and some
data for it. An application needs to know path to its data files, so
I pass it via compiler definition: ADD_DEFINITIONS(-DDATADIR="...")

The problem is that this path is different based on whether I want to
run the application from build directory:

ADD_DEFINITIONS(-DDATADIR="${PROJECT_SOURCE_DIR}/data")

or want to install it systemwide:

ADD_DEFINITIONS(-DDATADIR="${CMAKE_INSTALL_PREFIX}/share/myapp")

I want my project to both run from build directory and to be
installable systemwide, without the need to rebuild or specify extra
options.

- I don't want to make an applications search for its data relative
   to executable path
   - There's no cross-platform way to get an executable path
   - This will break when executable is moved or hardlinked
- I don't want to try both paths, as this is error prone, as installed
   executable may pick data files from repository or vice versa
- I don't want to make user specify additional cmake flags like
   -DSYSTEMWIDE_INSTALLATION or -DRUN_LOCALLY.
- I don't want to use any wrapper scripts
- I don't want to build two executables

The best solution would be for cmake to fix path in executable file
right after installation, something similar to what cmake does with
rpaths. Or there could be a cross-platform way for executable to know
whether it was installed which I've missed.

Any ideas?

How about reading the path from a configuration file. The default when 
there is no configuration file can be a relative path in the build tree. 
Use an 'install(CODE ...)' command to write a configuration file to be 
shipped with the executable that contains the path to use when 
installed. Application reads configuration file if it is there and uses 
contents to determine the path to the data.


Regards
Bill.
--

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

[CMake] Custom command concurrency

[Attila Krasznahorkay]

Dear All,

I'm running into a new issue with my custom commands. :-(

I have a project with many subdirectories. Where most subdirectories generate 
some files during the build. Some of which need to be merged into a single file 
at the end of the build.

In my current implementation the subdirectories declare both a custom command 
and a custom target for generating these files. So that the merge command in 
the main directory could depend on the custom targets of the subdirectories. 
(As the merge command can't depend on the generated files themselves directly.)

Now, the merge command is not the only use using these generated files. They 
are also used inside the subdirectories in order to build some libraries. And 
now the problem comes. Apparently CMake / GNU Make doesn't make sure that the 
generation command would only run once. Attached is a simple example. When 
running make in single-process mode, things happen as I would expect them to.

Scanning dependencies of target SubdirTarget
[ 33%] Generating partialFile.txt
[ 33%] Built target SubdirTarget
Scanning dependencies of target MergeTarget
[ 66%] Generating merged.txt
[ 66%] Built target MergeTarget
Scanning dependencies of target CompileSubdirTarget
[100%] Built target CompileSubdirTarget

But when I use multiple build processes, I get:

Scanning dependencies of target SubdirTarget
Scanning dependencies of target CompileSubdirTarget
[ 66%] Generating partialFile.txt
[ 66%] Generating partialFile.txt
[ 66%] Built target CompileSubdirTarget
[ 66%] Built target SubdirTarget
Scanning dependencies of target MergeTarget
[100%] Generating merged.txt
[100%] Built target MergeTarget

So, the file generation gets triggered twice at the same time. Of course in 
this simple example this wouldn't matter. But the generator that I use in real 
life can't handle this. As it creates some temporary files as it runs, which 
interfere with each other. So I come out with a corrupt output file.

Does anyone have any suggestions? I would really need to be able to make sure 
that this custom command would not be executed multiple times. And most of all, 
not multiple times at once.

Cheers,
Attila

P.S. It seems that the Ninja generator is a bit better in this respect. But of 
course it's not an option to not have my project work correctly with the 
Makefile generator.



custom_command_concurrency.tar.bz2
Description: BZip2 compressed 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

Re: [CMake] Best way to handle application data path for local run vs. installation

[Ruslan Baratov via CMake]

On 30-Nov-15 09:10, Dmitry Marakasov wrote:

Hi!

This question bugs me for a long time so I though maybe someone has
a solution. I have a project which includes an application and some
data for it. An application needs to know path to its data files, so
I pass it via compiler definition: ADD_DEFINITIONS(-DDATADIR="...")

The problem is that this path is different based on whether I want to
run the application from build directory:

ADD_DEFINITIONS(-DDATADIR="${PROJECT_SOURCE_DIR}/data")

or want to install it systemwide:

ADD_DEFINITIONS(-DDATADIR="${CMAKE_INSTALL_PREFIX}/share/myapp")

I want my project to both run from build directory and to be
installable systemwide, without the need to rebuild or specify extra
options.

- I don't want to make an applications search for its data relative
   to executable path
   - There's no cross-platform way to get an executable path

It's tricky but not impossible. Might be helpful:
* http://stackoverflow.com/a/1024937/2288008
* 
https://github.com/Kitware/CMake/blob/31b013b14ad3bf4838f4ba327b5392018f4853b6/Source/cmSystemTools.cxx#L2227 
(see exe_dir)



   - This will break when executable is moved or hardlinked
- I don't want to try both paths, as this is error prone, as installed
   executable may pick data files from repository or vice versa
- I don't want to make user specify additional cmake flags like
   -DSYSTEMWIDE_INSTALLATION or -DRUN_LOCALLY.
- I don't want to use any wrapper scripts
- I don't want to build two executables

...


The best solution would be for cmake to fix path in executable file
right after installation, something similar to what cmake does with
rpaths.
I doubt there is a general way to patch data section with string in 
executable. At least with different size and in safe manner. For example 
Clang is smart enough to figure out 'strlen' of literal string at 
compile time, so changing string affects logic and hence is dangerous. 
And rpaths unlike data is designed to be modifiable (e.g. see 
install_name_tool for OS X) so it's okay to hack it back and forth.


Second thought is that when you hardcode path in executable you make it 
non-relocatable. E.g. it's not possible to pack it to .dmg installer so 
user can unpack it wherever he wants.



  Or there could be a cross-platform way for executable to know
whether it was installed which I've missed.

Any ideas?


...

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

Re: [CMake] [cmake-developers] Obtaining header file dependencies of a source file manually

[iosif neitzke]

What does output_required_files() [0] do, and is it applicable here?

[0] https://cmake.org/cmake/help/v3.4/command/output_required_files.html

On Mon, Nov 30, 2015 at 2:09 AM, Petr Kmoch  wrote:
> Hi Dan,
>
> you could look into the IMPLICIT_DEPENDS argument of add_custom_command:
> https://cmake.org/cmake/help/latest/command/add_custom_command.html
>
> I don't have direct experience with it, but it looks like it could do what
> you're looking for.
>
> Petr
>
> On Sun, Nov 29, 2015 at 10:47 AM, Dan Liew  wrote:
>>
>> Hi,
>>
>> # TL;DR
>>
>> I need a way of determining the header file dependencies of a source
>> file and inform CMake about them. CMake doesn't do this automatically
>> because I'm using custom commands for the compilation step so CMake
>> doesn't do it's usual magic of automatically inferring source file
>> header dependencies. This is because this part of the compilation step
>> requires a separate C++ compiler (completely independent from the one
>> that CMake detects at configure time).
>>
>> Is there a way of doing this that will also regenerate the
>> dependencies if the source file changes?
>>
>> # Long version
>>
>> A C++ project that I work on [1] is (amongst other things) a compiler.
>> In order to compile applications it needs to link in a supporting
>> runtime that is compiled to LLVM bitcode which is linked into the
>> applications it compiles.
>>
>> The supporting runtime is written in C++ and compiled with Clang. The
>> compilation of the runtime is currently achieved using
>> ``add_custom_command()`` and so I am not using CMake's in built
>> support for detecting header file dependencies. The reason for doing
>> it this way is because the LLVM bitcode compiler (i.e. Clang) **is
>> not** the same compiler as the host C++ compiler for the project. For
>> example the host code might be built with MSVC but the supporting
>> runtime is **always** built with Clang.
>>
>> To see this concretely take a look at [2].
>>
>> The build works correctly if you build from a clean build directory.
>> It does not work correctly if you perform a rebuild and change one of
>> the header files that the supporting runtime depends on. This is
>> because CMake doesn't know that the runtime source files depend on the
>> header files and so doesn't rebuild the relevant source files.
>>
>> I can obviously tell CMake about these manually (adding more entries
>> under ``DEPENDS`` in the ``add_custom_command()`` invocation) but this
>> is very cumbersome.
>>
>> What I really need is a way to
>>
>> * Automatically infer the dependencies of a source file and tell CMake
>> about them
>> * Have the dependencies automatically regenerated if the source file
>> changes (someone could add or remove a header file include).
>>
>> In a simple Makefile build system this typically achieved by doing
>> something like this:
>>
>> ```
>> all:: $(SRCS:.cpp:.o)
>>
>> SRCS := foo.cpp bar.cpp
>>
>> # Include SRC file dependencies generated by the compiler if they exist
>> -include $(SRCs:.cpp=.d)
>>
>> %.o : %.cpp
>>   $(CXX) -c $< -o $@ -MP -MMD -MF $*.d
>> ```
>>
>> Note the ``-M*`` flags get the compiler when it runs to generate
>> additional makefile rules that will get included next time a build
>> happens.
>>
>> I don't really know how to do the same thing with CMake. One idea is
>> at configure time invoke Clang with the ``-MP -MMD -MF`` flags on each
>> runtime source file, extract the dependencies then pass them to
>> ``DEPENDS`` in ``add_custom_command()``. If I wanted the dependencies
>> regenerated if the runtime source file changes then I would need to
>> somehow get CMake to reconfigure every time this happens.
>>
>> I don't like this idea very much due to
>>
>> * Having to invoke Clang manually to determine the dependencies. CMake
>> already knows how to determine source file dependencies, but this
>> functionality (AFAIK) isn't exposed to me.
>>
>> * Reconfiguring every time one of the runtime source file changes is
>> annoying (configuring can be slow sometimes).
>>
>> Does anyone have any other ideas? CMake obviously knows how to do all
>> this stuff already for source files being compiled for the detected
>> host C++ compiler, I just don't know how to get at this logic for
>> source files that need to be built with a second independent C++
>> compiler.
>>
>> [1] https://github.com/halide/Halide
>> [2] https://github.com/halide/Halide/blob/master/src/CMakeLists.txt#L140
>>
>> Thanks,
>> Dan.
>> --
>>
>> 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 

Re: [CMake] [cmake-developers] Obtaining header file dependencies of a source file manually

[Petr Kmoch]

On Mon, Nov 30, 2015 at 2:04 PM, iosif neitzke <
iosif.neitzke+cm...@gmail.com> wrote:

> What does output_required_files() [0] do, and is it applicable here?
>
> [0] https://cmake.org/cmake/help/v3.4/command/output_required_files.html


First and foremost, it introduces deprecated behaviour into your code. The
very first line in the docs you link to says that it was deprecated in
CMake 3.0 and is this scheduled for removal. It should not be used in new
code.

Petr
-- 

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