[Cmake-commits] CMake branch, master, updated. v3.5.0-268-gbbab373

[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  bbab373b00b8e85b6574232031d8cd23010f65c6 (commit)
  from  33594f20fa22c7aea62051f199004e3d4d89c971 (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=bbab373b00b8e85b6574232031d8cd23010f65c6
commit bbab373b00b8e85b6574232031d8cd23010f65c6
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Mon Mar 21 00:01:04 2016 -0400
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Mon Mar 21 00:01:04 2016 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index bab9222..11dff2b 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 5)
-set(CMake_VERSION_PATCH 20160320)
+set(CMake_VERSION_PATCH 20160321)
 #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

Re: [CMake] How to suppress valgrind errors reported by NightlyMemCheck ?

[Aaron Boxer]

Hi Xavier,


On Sun, Mar 20, 2016 at 1:50 PM, Xavier Besseron 
wrote:

> Hi Aaron,
>
> I don't know if that's what you're looking for,
> but you can try to set Valgrind options using an environment variable or
> a cmake variable
>
> set(VALGRIND_OPTS "--suppressions=/path/to/your_suppression_file.supp")
>
>
> or
>
>
> export VALGRIND_OPTS="--suppressions=/path/to/your_suppression_file.supp"
>
>
Excellent, thanks for your help. This worked for me.

Aaron





>
>
> Best regards,
>
> Xavier
>
> On Sun, Mar 20, 2016 at 6:14 PM, Aaron Boxer  wrote:
>
>> My program links to libstdc++. It turns out there is a well-known false
>> positive
>> from valgrind regarding libstdc++ memory pools.
>>
>> http://valgrind.org/docs/manual/faq.html#faq.reports
>>
>> How may I suppress this error when running ctest -D NightlyMemCheck  ?
>>
>> Thanks,
>> Aaron
>>
>
>
>
> --
> Dr Xavier BESSERON
> Research associate
> FSTC, University of Luxembourg
> Campus Kirchberg, Office E-007
> Phone: +352 46 66 44 5418
> http://luxdem.uni.lu/
>
>
> --
>
> 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

Re: [CMake] find_package REQUIRED ignores OPTIONAL_COMPONENTS

[Alexander Stein]

On Tuesday 08 March 2016, 10:00:00 wrote Nicholas Braden:
> Jakob, I don't think there is any confusion about what REQUIRED means.
> Whether or not REQUIRED is provided, the list of OPTIONAL_COMPONENTS
> should not be required under any circumstances. The example error
> message seems pretty clear to me that the expected behavior and actual
> behavior are different. I went and looked at the source code of the
> find module:
> 
> https://github.com/Kitware/CMake/blob/master/Modules/FindQt4.cmake
> 
> It seems that there is no check whatsoever for
> Qt4_FIND_REQUIRED_, so the find module just blindly assumes
> that all components are required.
> 
> More info: 
> https://cmake.org/cmake/help/latest/manual/cmake-developer.7.html#find-modules
> 
> To me this seems like a bug in the find module.

Yep, FindQt4.cmake doesn't support OPTIONAL_COMPONENTS which seems only to work 
if FIND_PACKAGE_HANDLE_STANDARD_ARGS is called with HANDLE_COMPONENTS passed. 
This is not the case and does not work. I guess due to different naming scheme 
used for components. AFAICS they have to be e.g. Qt4_QtCore_FOUND, but not 
QT_QTCORE_FOUND.

Best regards,
Alexander

-- 

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-developers] [CMake 0016026]: CMake provides no reliable variable for 'the file a function is declared in'

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://public.kitware.com/Bug/view.php?id=16026 
== 
Reported By:Stephen Kelly
Assigned To:
== 
Project:CMake
Issue ID:   16026
Category:   (No Category)
Reproducibility:have not tried
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2016-03-20 19:35 CET
Last Modified:  2016-03-20 19:35 CET
== 
Summary:CMake provides no reliable variable for 'the file a
function is declared in'
Description: 

Given

  $ cat cmake/thefunc.cmake 

  set(somevar "${CMAKE_CURRENT_LIST_DIR}")

  function(thefunc)
message("somevar: ${somevar}")
message("listdir: ${CMAKE_CURRENT_LIST_DIR}")
  endfunction()

  $ cat dir1/CMakeLists.txt 

  include(thefunc)

  thefunc()

  include(GenerateExportHeader)

  $ cat CMakeLists.txt

  cmake_minimum_required(VERSION 2.8.12)

  project(ttt CXX)

  list(APPEND CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/cmake)

  add_subdirectory(dir1)

  thefunc()

  if (COMMAND generate_export_header)
add_library(foo foo.cpp)
generate_export_header(foo)
  endif()

the build output is

  somevar: /home/stephen/dev/src/playground/cmake/cmake
  listdir: /home/stephen/dev/src/playground/cmake/dir1
  somevar: 
  listdir: /home/stephen/dev/src/playground/cmake
  CMake Error: File /exportheader.cmake.in does not exist.
  CMake Error at
/home/stephen/dev/prefix/qtbase/kde/share/cmake-3.5/Modules/GenerateExportHeader.cmake:362
(configure_file):
configure_file Problem configuring file
  Call Stack (most recent call first):
   
/home/stephen/dev/prefix/qtbase/kde/share/cmake-3.5/Modules/GenerateExportHeader.cmake:378
(_do_generate_export_header)
CMakeLists.txt:14 (generate_export_header)


  -- Configuring incomplete, errors occurred!


That is: CMake doesn't provide a way to determine the file a macro or function
is defined in. The workaround is to determine that outside of the function/macro
scope. However, that workaround breaks down because the variable and the
function/macro do not follow the same scoping rules. The function/macro is
available 'globally' after definition, so users can make the mistake of trying
to use it in a scope which does not contain the `include()`.

This affects at least the GenerateExportHeader module and perhaps other modules
shipped with cmake.

One workaround is to check the existence of the variable in the function:

 https://git.reviewboard.kde.org/r/127432/diff/1

Another would be to use a global property instead of a variable for the
workaround.

A better solution may be for cmake to provide the 'path of the file this code
resides in' in a variable. 

== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-03-20 19:35 Stephen Kelly  New Issue
==

-- 

Powered by www.kitware.com

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

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

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

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

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

[Cmake-commits] CMake branch, next, updated. v3.5.0-517-gbd79937

[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  bd7993730e2f96e8899a1670ccfe71744e1f5c90 (commit)
   via  9cdb37e9175b2e3c6367bc4863fda0404cb1c3a2 (commit)
   via  1bcdc4db1bcfc75cf9813bc279840b975e74892d (commit)
   via  b7eb7e0f78f37b6a7dfc6f9f300286472b7f3499 (commit)
   via  66d146431d62ac6c2ff83fcb504638cfd88248a7 (commit)
   via  9e5f914d86581958a1ae9c2df8ca67e6ba11a83f (commit)
   via  908259084f139187af202aaf5c39052804d8969e (commit)
  from  7cd44969f80853ae4e26c428192bd7364e7ef94e (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=bd7993730e2f96e8899a1670ccfe71744e1f5c90
commit bd7993730e2f96e8899a1670ccfe71744e1f5c90
Merge: 7cd4496 9cdb37e
Author: Brad King 
AuthorDate: Fri Mar 18 09:44:13 2016 -0400
Commit: Brad King 
CommitDate: Fri Mar 18 09:44:13 2016 -0400

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

[CMake] How to suppress valgrind errors reported by NightlyMemCheck ?

[Aaron Boxer]

My program links to libstdc++. It turns out there is a well-known false
positive
from valgrind regarding libstdc++ memory pools.

http://valgrind.org/docs/manual/faq.html#faq.reports

How may I suppress this error when running ctest -D NightlyMemCheck  ?

Thanks,
Aaron
-- 

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_USE_PTHREADS_INIT cleanup

[Aaron Boxer]

On Sun, Mar 20, 2016 at 8:46 AM, Aaron Boxer  wrote:

> I recently added pthreads to my cmake program.
> When I run valgrind, I get a "blocks still reachable" warning,
> coming from dl_init.
>
> I suspect that pthreads is not cleaning up properly. Is there a way
> of ensuring that the shared library for pthreads gets cleaned up correctly
> via cmake?
>
> i.e. a matching CLEANUP to got with the INIT call ?
>


Turns out it isn't pthreads library.
-- 

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, next, updated. v3.5.0-472-g50c0287

[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  50c0287ee22e19da6a6c4fb5c9e5ed752e717073 (commit)
   via  3144857e1eed83e038699942568869bfce461d4d (commit)
  from  03405388a88dd8a4c35c7bce8c7a3ff66978ea31 (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=50c0287ee22e19da6a6c4fb5c9e5ed752e717073
commit 50c0287ee22e19da6a6c4fb5c9e5ed752e717073
Merge: 0340538 3144857
Author: Brad King 
AuthorDate: Wed Mar 16 09:03:49 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Wed Mar 16 09:03:49 2016 -0400

Merge topic 'use-GetCMakeRoot' into next

3144857e Avoid depending on CMAKE_ROOT cache entry internally (#16015)


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3144857e1eed83e038699942568869bfce461d4d
commit 3144857e1eed83e038699942568869bfce461d4d
Author: Brad King 
AuthorDate: Mon Mar 14 10:38:19 2016 -0400
Commit: Brad King 
CommitDate: Wed Mar 16 09:03:26 2016 -0400

Avoid depending on CMAKE_ROOT cache entry internally (#16015)

Use cmSystemTools::GetCMakeRoot() which always knows the location of our
resources.  Do not depend on CMAKE_ROOT because the user could unset it
from the cache.

diff --git a/Source/cmCreateTestSourceList.cxx 
b/Source/cmCreateTestSourceList.cxx
index 54c27d6..e670991 100644
--- a/Source/cmCreateTestSourceList.cxx
+++ b/Source/cmCreateTestSourceList.cxx
@@ -78,8 +78,7 @@ bool cmCreateTestSourceList
   driver += *i;
   ++i;
 
-  std::string configFile =
-this->Makefile->GetRequiredDefinition("CMAKE_ROOT");
+  std::string configFile = cmSystemTools::GetCMakeRoot();
 
   configFile += "/Templates/TestDriver.cxx.in";
   // Create the test driver file
diff --git a/Source/cmExtraCodeBlocksGenerator.cxx 
b/Source/cmExtraCodeBlocksGenerator.cxx
index ed0c69c..476d3ac 100644
--- a/Source/cmExtraCodeBlocksGenerator.cxx
+++ b/Source/cmExtraCodeBlocksGenerator.cxx
@@ -259,13 +259,12 @@ void cmExtraCodeBlocksGenerator
   }
 
 // Convert
-const char* cmakeRoot = mf->GetDefinition("CMAKE_ROOT");
 for (std::vector::const_iterator jt = listFiles.begin();
  jt != listFiles.end();
  ++jt)
   {
   // don't put cmake's own files into the project (#12110):
-  if (jt->find(cmakeRoot) == 0)
+  if (jt->find(cmSystemTools::GetCMakeRoot()) == 0)
 {
 continue;
 }
diff --git a/Source/cmGeneratorTarget.cxx b/Source/cmGeneratorTarget.cxx
index ff12320..d7c2782 100644
--- a/Source/cmGeneratorTarget.cxx
+++ b/Source/cmGeneratorTarget.cxx
@@ -3909,8 +3909,7 @@ void checkPropertyConsistency(cmGeneratorTarget const* 
depender,
 
   std::vector props;
   cmSystemTools::ExpandListArgument(prop, props);
-  std::string pdir =
-dependee->Target->GetMakefile()->GetRequiredDefinition("CMAKE_ROOT");
+  std::string pdir = cmSystemTools::GetCMakeRoot();
   pdir += "/Help/prop_tgt/";
 
   for(std::vector::iterator pi = props.begin();
diff --git a/Source/cmGlobalGenerator.cxx b/Source/cmGlobalGenerator.cxx
index c628406..1d0ade4 100644
--- a/Source/cmGlobalGenerator.cxx
+++ b/Source/cmGlobalGenerator.cxx
@@ -820,7 +820,7 @@ 
cmGlobalGenerator::EnableLanguage(std::vectorconst& languages,
   // Now load files that can override any settings on the platform or for
   // the project First load the project compatibility file if it is in
   // cmake
-  std::string projectCompatibility = mf->GetDefinition("CMAKE_ROOT");
+  std::string projectCompatibility = cmSystemTools::GetCMakeRoot();
   projectCompatibility += "/Modules/";
   projectCompatibility += mf->GetSafeDefinition("PROJECT_NAME");
   projectCompatibility += "Compatibility.cmake";
diff --git a/Source/cmGlobalVisualStudioGenerator.cxx 
b/Source/cmGlobalVisualStudioGenerator.cxx
index 6a1aa29..00bb511 100644
--- a/Source/cmGlobalVisualStudioGenerator.cxx
+++ b/Source/cmGlobalVisualStudioGenerator.cxx
@@ -184,12 +184,11 @@ void RegisterVisualStudioMacros(const std::string& 
macrosFile,
 //
 void cmGlobalVisualStudioGenerator::ConfigureCMakeVisualStudioMacros()
 {
-  cmMakefile* mf = this->LocalGenerators[0]->GetMakefile();
   std::string dir = this->GetUserMacrosDirectory();
 
   if (dir != "")
 {
-std::string src = mf->GetRequiredDefinition("CMAKE_ROOT");
+std::string src = cmSystemTools::GetCMakeRoot();
 src += "/Templates/" CMAKE_VSMACROS_FILENAME;
 
 std::string dst = dir + "/CMakeMacros/" CMAKE_VSMACROS_FILENAME;
diff --git a/Source/cmMakefile.cxx 

Re: [cmake-developers] Patch to only consider build dependencies between files in the source directory

[David Cole via cmake-developers]

Brad's point with "/" or null terminator was that the directory name
**must** be the directory itself, or a sub-directory of the one in
question.

i.e.

if it's "my/src"

then it should either be exactly "my/src" or "my/src/someSubDir" , not
"my/srcSiblingDir"




On Fri, Mar 18, 2016 at 11:52 AM, Attila Krasznahorkay
 wrote:
> Hi Brad,
>
>>> +  // If it's an absolute path, check if it starts with the source
>>> +  // direcotory:
>>> +  return ( ( path.find( SourceDir ) != 0 ) &&
>>> +   ( path.find( BinaryDir ) != 0 ) );
>>
>> Please look at using strncmp and a check that the following character
>> is a nul terminator or '/'.  Otherwise an external location with
>> a common prefix may be mistaken for part of the project.
>
> Not sure what scenario you have in mind here. :-/ std::string::find should 
> only return 0 if the source directory path or binary directory path is what 
> the evaluated path begins with. Why should we worry what the path continues 
> with?
>
> I was wondering about possibly using strncmp, but thought that 
> performance-wise std::string::find should be fine as well here.
>
> I'm not at all against changing the code, I just don't understand yet what 
> setup the current code would not handle correctly.
>
>> Also please add documentation in a
>>
>>  Help/variable/CMAKE_DEPENDS_IN_PROJECT_ONLY.rst
>>
>> file and update Help/manual/cmake-variables.7.rst to reference it.
>
> Will do. Was just not sure where to add this documentation.
>
> Cheers,
> Attila
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more 
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Using CMake generated ninja file as a subninja file

[Nicolas Desprès]

On Wed, Mar 9, 2016 at 9:41 PM, Ben Boeckel  wrote:

> On Tue, Mar 08, 2016 at 12:36:31 +0100, Nicolas Desprès wrote:
> > Did you have a chance to review my patches?
>
> So I looked at it today, and it looks good overall. A few niggles:
>
Thanks

>
> +inline bool cmEndsWith(const std::string& str, const std::string& what)
> +{
> +  assert(str.size() >= what.size());
>
> Probably better to just "return false;" if this would fire. Better than
> crashing if something in a release would have hit this.
>
>
Ok.


> +  return str.compare(str.size() - what.size(), what.size(), what) == 0;
> +}
> +
> +inline void cmStripSuffixIfExists(std::string* str,
> +  const std::string& suffix)
> +{
> +  assert(str != NULL);
>
> Why not just use a reference rather than a pointer?
>

I don't like to use non-const reference argument because the caller may not
expect its variable to be modified since it not passed it by address.
Anyway, reference argument are used in other places in the source code so
it does not matter.


>
> +  if (cmEndsWith(*str, suffix))
> +str->resize(str->size() - suffix.size());
>
> Missing braces.
>

Ok.


>
> -std::string cmGlobalNinjaGenerator::ConvertToNinjaPath(const std::string&
> path)
> +static void EnsureTrailingSlash(std::string* path)
> +{
> +  assert(path != NULL);
>
> Same thing: why not a reference?
>
Done.

>
> +  if (path->empty())
> +return;
> +  std::string::value_type last = (*path)[path->size()-1];
> +#ifdef _WIN32
> +  if (last != '\\')
> +*path += '\\';
> +#else
> +  if (last != '/')
> +*path += '/';
> +#endif
>
> Missing braces in the if statements here.
>
>
Ok.


> -  cmGlobalNinjaGenerator::WriteDefault(os,
> -   outputs,
> -   "Make the all target the
> default.");
> +  if (!this->HasOutputPathPrefix())
> +cmGlobalNinjaGenerator::WriteDefault(os,
> + outputs,
> + "Make the all target the
> default.");
>
> Missing braces.
>
Ok.

>
> +void
> +cmGlobalNinjaGenerator::StripNinjaOutputPathPrefixAsSuffix(std::string*
> path)
> +{
> +  assert(path != NULL);
>
> More pointers :) .
>
Ok.

>
> +  if (path->empty())
> +return;
>
> And braces.
>
Ok.

The fixes are that commit:
https://github.com/nicolasdespres/CMake/commit/3fa749a19847898fcbb5635a273b0d02707dd4bd


> As for the tests:
>
> +  file(WRITE "${top_build_ninja}" "\
> +subninja sub/build.ninja
> +default sub/all
> +")
>
> I think adding the (documented) bit:
>
> +rule RERUN
> +  command = true
> +  description = Testing regeneration
> +  generator = 1
> +
> +build build.ninja: RERUN || sub/build.ninja
> +  pool = console
>
> here and testing that if the CMakeLists.txt is touched that CMake reruns
> would be worth it. It seems to work here, so keeping it working would be
> great.
>

I guess that test should exist on the super-generator side. But it is
probably safer to test it here too.

The fix is in that commit:
https://github.com/nicolasdespres/CMake/commit/13f341588bc6ee1cb0ec5dce8f44602f5d066ca9

Tell me if you prefer I squash all the commits together before you review.

Thanks,

-- 
Nicolas Desprès
-- 

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] CMAKE_USE_PTHREADS_INIT cleanup

[Aaron Boxer]

I recently added pthreads to my cmake program.
When I run valgrind, I get a "blocks still reachable" warning,
coming from dl_init.

I suspect that pthreads is not cleaning up properly. Is there a way
of ensuring that the shared library for pthreads gets cleaned up correctly
via cmake?

i.e. a matching CLEANUP to got with the INIT call ?

Thanks,
Aaron
-- 

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.5.0-238-gf5eda70

[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  f5eda7069027790a73f2e7f72d81bd5c0db46eae (commit)
   via  a22f9967252eecbbd00c9adc1f07ecab9f15e53e (commit)
  from  7fff134735d774a27b3d2fb5ddb16f5b9f9bbeb6 (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=f5eda7069027790a73f2e7f72d81bd5c0db46eae
commit f5eda7069027790a73f2e7f72d81bd5c0db46eae
Merge: 7fff134 a22f996
Author: Brad King 
AuthorDate: Wed Mar 16 09:08:01 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Wed Mar 16 09:08:01 2016 -0400

Merge topic 'vs-remote-directory'

a22f9967 VS: Optionally generate remote directory for WinCE projects


---

Summary of changes:
 Help/manual/cmake-properties.7.rst|1 +
 Help/prop_tgt/DEPLOYMENT_REMOTE_DIRECTORY.rst |   18 +
 Help/release/dev/vs-remote-directory.rst  |7 +++
 Source/cmLocalVisualStudio7Generator.cxx  |   26 +
 Source/cmLocalVisualStudio7Generator.h|3 +++
 5 files changed, 55 insertions(+)
 create mode 100644 Help/prop_tgt/DEPLOYMENT_REMOTE_DIRECTORY.rst
 create mode 100644 Help/release/dev/vs-remote-directory.rst


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