Re: [cmake-developers] [ANNOUNCE] CMake C++ coding style transition

2016-05-12 Thread Daniel Pfeifer 
On Thu, May 12, 2016 at 7:58 AM, Brad King  wrote:
> Hi Folks,
>
> As discussed previously on the developer list:
>
>  Code style auto-formatting
>  http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/14969
>  
> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/14969/focus=15001
>  
> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/14969/focus=16307
>  
> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/14969/focus=16358
>
> we've decided to change the C++ coding style within CMake to use a
> more modern style that can be automatically formatted.  We chose a
> style defined by clang-format:
>
>  ---
>  # This configuration requires clang-format 3.8 or higher.
>  BasedOnStyle: Mozilla
>  AlignOperands: false
>  AlwaysBreakAfterReturnType: None
>  AlwaysBreakAfterDefinitionReturnType: None
>  ColumnLimit: 79
>  Standard: Cpp03
>  ...
>
> A simple example of the layout is:
>
>  bool foo(int a, int b)
>  {
>if (a < b) {
>  return true;
>} else {
>  return false;
>}
>  }

In a next step, we can use clang-tidy to clean up the above to:

bool foo(int a, int b)
{
  return a < b;
}

:-)
-- 

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

2016-05-12 Thread Brad King 
On 05/12/2016 02:16 PM, Nicolas Desprès wrote:
> All done. Thank you for taking a look.
> https://github.com/nicolasdespres/CMake/commits/ninja-output-path-prefix

The RunCMake.NinjaOutputPathPrefix test fails for me when I have
the CMake source and build trees in a directory with a space in
the path.  Also, please move these test cases over to the
Tests/RunCMake/Ninja directory.  You should be able to just append
the RunCMakeTest.cmake content.

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] [PATCH] FindBoost does not detect absence of header file

2016-05-12 Thread Roger Leigh 

On 11/05/2016 19:43, rle...@codelibre.net wrote:

On 2016-05-11 19:30, Chuck Atkins wrote:

I guess it doesn't really matter but for the libraries that don't have
a single include header, should you be using these instead:

* container/container_fwd.hpp
* exception/all.hpp
* filesystem.hpp
* math_fwd.hpp (instead of math/quaternion.hpp)
* system/config.hpp
* type_erasure/config.hpp

They're "common" or "central" headers for the libraries instead of
specific headers.


Thanks for taking a look and making the suggestions.  I'll certainly
update some of these.  However, note that for some of these (e.g.
exception, filesystem), that common header didn't exist in earlier
releases and so was deliberately not used; in these cases I picked a
common header which is present in *all* Boost releases, back to 1.33
except for components which were introduced in later releases.
filesystem.hpp was introduced after the initial release with filesytem,
likewise exception/all.hpp for exception.


I have made the suggested changes above where this was possible, and 
merged the boost-component-headers branch into next for testing.



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] Using CMake generated ninja file as a subninja file

2016-05-12 Thread Nicolas Desprès 
On Thu, May 12, 2016 at 3:16 PM, Brad King  wrote:

> On 05/12/2016 06:16 AM, Nicolas Desprès wrote:
> > Brad has just sent a notification email about an upcoming feature freeze.
> > Do you think we could have this feature merged before?
>
> I'll take a look.  Please rebase on 'master' to resolve conflicts
> and also reconcile with the ConvertToNinjaFolderRule logic that was
> added.  Also please squash your fixup commits.
>
>
All done. Thank you for taking a look.
https://github.com/nicolasdespres/CMake/commits/ninja-output-path-prefix

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

Re: [cmake-developers] [Patch] FindPkgConfig: optionally create imported target for the found libraries

2016-05-12 Thread Brad King 
On 05/12/2016 12:48 PM, Rolf Eike Beer wrote:
> Good point. I have changed this accordingly and pushed it to next. There are 
> no tests yet, so maybe not immediately merge it to next but wait for the 
> weekend or so.

Okay, thanks.  Please also add a Help/release/dev/FindPkgConfig-targets.rst
file with a release note for the feature.

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] [Patch] FindPkgConfig: optionally create imported target for the found libraries

2016-05-12 Thread Rolf Eike Beer 
Am Donnerstag, 12. Mai 2016, 09:53:06 schrieb Brad King:
> On 05/12/2016 09:34 AM, Rolf Eike Beer wrote:
> > find_library(${_prefix}-${CMAKE_MATCH_1}
> > 
> >   NAMES ${CMAKE_MATCH_1}
> >   ${_find_opts})
> > 
> > list(APPEND _libs "${${_prefix}-${CMAKE_MATCH_1}}")
> 
> Generally I try to store the CMAKE_MATCH_ values in other variables
> as soon as possible and then use those other variables.  Otherwise
> refactoring may cause their values to change and break existing logic.

Good point. I have changed this accordingly and pushed it to next. There are 
no tests yet, so maybe not immediately merge it to next but wait for the 
weekend or so.

Greetings,

Eike

signature.asc
Description: This is a digitally signed message part.
-- 

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] [ANNOUNCE] CMake C++ coding style transition

2016-05-12 Thread Brad King 
Hi Folks,

As discussed previously on the developer list:

 Code style auto-formatting
 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/14969
 
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/14969/focus=15001
 
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/14969/focus=16307
 
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/14969/focus=16358

we've decided to change the C++ coding style within CMake to use a
more modern style that can be automatically formatted.  We chose a
style defined by clang-format:

 ---
 # This configuration requires clang-format 3.8 or higher.
 BasedOnStyle: Mozilla
 AlignOperands: false
 AlwaysBreakAfterReturnType: None
 AlwaysBreakAfterDefinitionReturnType: None
 ColumnLimit: 79
 Standard: Cpp03
 ...

A simple example of the layout is:

 bool foo(int a, int b)
 {
   if (a < b) {
 return true;
   } else {
 return false;
   }
 }

This style is much more common than our old Whitesmiths-like style and
will be easier to maintain in many editors.  Also the clang-format tool
can be used to maintain the format.

The transition will be implemented as a one-shot automated style conversion
recorded as a commit by "Kitware Robot".  The use of this author will call
out the transition in `git blame` output that reaches it.  I plan to perform
the final conversion sometime before the 3.6 release freeze so that fixes
for the release do not have to be backported to the old style.

For those of you with open topics it should be possible to rebase them
across the style transition automatically.  I will include an empty commit
preceding the transition to aid with this.  Its commit message will explain
what to do.  I can help with the process for anyone that has trouble.

For reference, I've temporarily published an example topic performing the
transition here:

 https://github.com/bradking/CMake/tree/clang-format-test

-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] FindPkgConfig: optionally create imported target for the found libraries

2016-05-12 Thread Brad King 
On 05/12/2016 09:34 AM, Rolf Eike Beer wrote:
> find_library(${_prefix}-${CMAKE_MATCH_1}
>   NAMES ${CMAKE_MATCH_1}
>   ${_find_opts})
> list(APPEND _libs "${${_prefix}-${CMAKE_MATCH_1}}")

Generally I try to store the CMAKE_MATCH_ values in other variables
as soon as possible and then use those other variables.  Otherwise
refactoring may cause their values to change and break existing logic.

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] [Patch] FindPkgConfig: optionally create imported target for the found libraries

2016-05-12 Thread Rolf Eike Beer 

Am 2016-05-12 14:59, schrieb Brad King:

On 05/11/2016 05:52 PM, Rolf Eike Beer wrote:
It has always nagged me that the FindPkgConfig module requires people 
to use
link_directories(). Now I created a new optional mode for 
pkg_check_modules()
and pkg_search_modules() which will search the absolute paths of the 
libraries
that are returned by pkg-config, and create an imported target from 
that
information that also contains defines and include directories. It 
restricts
searching to the directories returned by pkg-config, if none are given 
the
normal search rules are used. I have manually tested this and it seems 
to
work. Please have a look and tell me if I have missed something before 
I put

this into next.


Great!  I've long wanted to see this done.


+if (flag MATCHES "^-l(.*)")
+  set(_pkg_search "${CMAKE_MATCH_1}")
+else()
+  continue()
+endif()
+
+find_library(${_prefix}-${CMAKE_MATCH_1}
+ NAMES ${CMAKE_MATCH_1}
+ ${_find_opts})
+list(APPEND _libs "${${_prefix}-${CMAKE_MATCH_1}}")


Shouldn't these latter ${CMAKE_MATCH_1} references use ${_pkg_search} 
instead?


The whole _pkg_search thing can go away, it's from an earlier version of 
the patch. This should work the same:


if (NOT flag MATCHES "^-l(.*)")
  continue()
endif()

find_library(${_prefix}-${CMAKE_MATCH_1}
 NAMES ${CMAKE_MATCH_1}
 ${_find_opts})
list(APPEND _libs "${${_prefix}-${CMAKE_MATCH_1}}")

Eike
--

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

2016-05-12 Thread Brad King 
On 05/12/2016 06:16 AM, Nicolas Desprès wrote:
> Brad has just sent a notification email about an upcoming feature freeze.
> Do you think we could have this feature merged before?

I'll take a look.  Please rebase on 'master' to resolve conflicts
and also reconcile with the ConvertToNinjaFolderRule logic that was
added.  Also please squash your fixup commits.

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] [Patch] FindPkgConfig: optionally create imported target for the found libraries

2016-05-12 Thread Brad King 
On 05/11/2016 05:52 PM, Rolf Eike Beer wrote:
> It has always nagged me that the FindPkgConfig module requires people to use 
> link_directories(). Now I created a new optional mode for pkg_check_modules() 
> and pkg_search_modules() which will search the absolute paths of the 
> libraries 
> that are returned by pkg-config, and create an imported target from that 
> information that also contains defines and include directories. It restricts 
> searching to the directories returned by pkg-config, if none are given the 
> normal search rules are used. I have manually tested this and it seems to 
> work. Please have a look and tell me if I have missed something before I put 
> this into next.

Great!  I've long wanted to see this done.

> +if (flag MATCHES "^-l(.*)")
> +  set(_pkg_search "${CMAKE_MATCH_1}")
> +else()
> +  continue()
> +endif()
> +
> +find_library(${_prefix}-${CMAKE_MATCH_1}
> + NAMES ${CMAKE_MATCH_1}
> + ${_find_opts})
> +list(APPEND _libs "${${_prefix}-${CMAKE_MATCH_1}}")

Shouldn't these latter ${CMAKE_MATCH_1} references use ${_pkg_search} instead?

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] Using CMake generated ninja file as a subninja file

2016-05-12 Thread Nicolas Desprès 
Hi Ben,

Brad has just sent a notification email about an upcoming feature freeze.
Do you think we could have this feature merged before?

Regards,
Nicolas

On Sun, Mar 20, 2016 at 1:47 PM, Nicolas Desprès 
wrote:

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



-- 
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-developers] [CMake 0016101]: ADD_SUBDIRECTORY with EXCLUDE_FROM_ALL fails to include target dependencies(XCode Generator)

2016-05-12 Thread Mantis Bug Tracker 

The following issue has been SUBMITTED. 
== 
https://cmake.org/Bug/view.php?id=16101 
== 
Reported By:Robert Bielik
Assigned To:
== 
Project:CMake
Issue ID:   16101
Category:   CMake
Reproducibility:always
Severity:   block
Priority:   normal
Status: new
== 
Date Submitted: 2016-05-12 04:07 EDT
Last Modified:  2016-05-12 04:07 EDT
== 
Summary:ADD_SUBDIRECTORY with EXCLUDE_FROM_ALL fails to
include target dependencies(XCode Generator)
Description: 
If the main target executable depends on targets that are in a subdirectory,
using EXCLUDE_FROM_ALL in ADD_SUBDIRECTORY fails to include the target
dependencies, leading to linking errors.

>From documentation: 
"Note that inter-target dependencies supercede this exclusion. If a target built
by the parent project depends on a target in the subdirectory, the dependee
target will be included in the parent project build system to satisfy the
dependency"

This works fine for MSYS, Unix and Visual Studio generators, but NOT XCode.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-05-12 04:07 Robert Bielik  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