Re: [cmake-developers] Code style auto-formatting

2016-05-10 Thread Brad King
On 05/09/2016 03:29 PM, Paul Smith wrote:
> On Mon, 2016-05-09 at 14:17 -0400, Brad King wrote:
>>> Where does 79 come from?
>>
>> That has been CMake's limit for a long time.  Since we're changing the
>> style anyway we might as well go with the more common 80 chars
> 
> Not to say whether or not this should be changed, but FYI the 79 comes
> from this set of facts:
> 
>  * Traditional terminals are 80 chars wide
>  * Editors and viewers that do line-wrapping use the last character of
>the line to specify whether there was a wrap, otherwise you can't
>tell if the line is wrapped or there's a newline.

Thanks, Paul. Good explanation of the historical reason.  I tend to
agree, but I wonder why this has not caused any of the standard
styles clang-format provides (Mozilla, Google, LLVM, etc.) to adopt
79 characters instead of 80.  Maybe it is just that the width limit
is now more about supporting side-by-side diff views or multiple
terminal splits without using the entire monitor width for viewing
a source file with long lines.  It also helps avoid excessive eye
movement horizontally while reading code.  The difference between
79 and 80 characters for these purposes is negligible.

Only a small fraction of lines should end up near this limit so I
do not think readability will change much between 79 and 80 chars.
Therefore I propose that we go back to 79 characters for the above
reasons.  It will also help `git diff` views fit in 80 chars even
with the left `+/-` column.

This brings us to:

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

-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] Code style auto-formatting

2016-05-09 Thread Paul Smith
On Mon, 2016-05-09 at 14:17 -0400, Brad King wrote:
> > What is the rationale for "ColumnLimit: 79"? To make a line fit on old
> > school terminals, 80 should be OK. To make a diff or an email response
> > fit on old school terminals, two extra spaces are reserved. That leads
> > to a column limit of 78. Where does 79 come from?
> 
> That has been CMake's limit for a long time.  Since we're changing the
> style anyway we might as well go with the more common 80 chars that is
> default in the Mozilla style.

Not to say whether or not this should be changed, but FYI the 79 comes
from this set of facts:

 * Traditional terminals are 80 chars wide
 * Editors and viewers that do line-wrapping use the last character of
   the line to specify whether there was a wrap, otherwise you can't
   tell if the line is wrapped or there's a newline.

So a line that is exactly 80 characters long would look like this in
such a viewer:

this line...is 80 chars lon\
g
and this isn't


Hence the restriction to 79 chars to avoid that wrap.  Also, some kind
-of-broken terminals used to automatically scroll the window if you
wrote a character to the bottom-right-most character (line 24 / char
80).
-- 

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] Code style auto-formatting

2016-05-09 Thread Brad King
On 05/09/2016 01:48 PM, Daniel Pfeifer wrote:
> "AllowShortFunctionsOnASingleLine: Inline" is default in the Mozilla
> preset. This line can be removed.

Yes, thanks.

> What is your rationale for "IndentCaseLabels: false"? I find that
> indenting them increases readability when switch statements use
> hanging braces. If the opening "{" is on a separate line, indenting
> the labels does not improve readability that much.

I experimented with it and liked the reduced horizontal space usage,
especially given the column limit.  However I see you're right about
this case:

  switch (x) {
  case 1: {
  } break;
  default: {
  }
  }

versus

  switch (x) {
case 1: {
} break;
default: {
}
  }

We can drop that line.

> What is the rationale for "ColumnLimit: 79"? To make a line fit on old
> school terminals, 80 should be OK. To make a diff or an email response
> fit on old school terminals, two extra spaces are reserved. That leads
> to a column limit of 78. Where does 79 come from?

That has been CMake's limit for a long time.  Since we're changing the
style anyway we might as well go with the more common 80 chars that is
default in the Mozilla style.

This brings us to:

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

-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] Code style auto-formatting

2016-05-09 Thread Daniel Pfeifer
On Mon, May 9, 2016 at 11:14 AM, Brad King  wrote:
> On 05/02/2016 10:08 AM, Brad King wrote:
>> Next I'll look at the style updates themselves.
>
> I've made some more preparatory commits:
>
>  Isolate formatted streaming blocks with clang-format off/on
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=64b55203
>
>  Move comments off of class access specifier lines
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=85425a3e
>
>  Help clang-format wrap after braces on long initializer lists
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=afca3735
>
>  Remove `//--...` horizontal separator comments
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0ac18d40
>
> These changes improve the formatting output in some local
> experiments.
>
> With the earlier changes to the #include order we no longer need
> to use any custom `IncludeCategories`.
>
> Here is the `.clang-format` file I'd like to use:
>
>   ---
>   # This configuration requires clang-format 3.8 or higher.
>   BasedOnStyle: Mozilla
>   AlignOperands: false
>   AllowShortFunctionsOnASingleLine: Inline
>   AlwaysBreakAfterReturnType: None
>   AlwaysBreakAfterDefinitionReturnType: None
>   ColumnLimit: 79
>   IndentCaseLabels: false
>   Standard: Cpp03
>   ...
>

"AllowShortFunctionsOnASingleLine: Inline" is default in the Mozilla
preset. This line can be removed.

What is your rationale for "IndentCaseLabels: false"? I find that
indenting them increases readability when switch statements use
hanging braces. If the opening "{" is on a separate line, indenting
the labels does not improve readability that much.

What is the rationale for "ColumnLimit: 79"? To make a line fit on old
school terminals, 80 should be OK. To make a diff or an email response
fit on old school terminals, two extra spaces are reserved. That leads
to a column limit of 78. Where does 79 come from?
-- 

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] Code style auto-formatting

2016-05-09 Thread Daniel Pfeifer
On Mon, May 9, 2016 at 11:31 AM, Rolf Eike Beer  wrote:
> Am Montag, 9. Mai 2016, 13:14:17 schrieb Brad King:
>> On 05/02/2016 10:08 AM, Brad King wrote:
>> > Next I'll look at the style updates themselves.
>>
>> I've made some more preparatory commits:
>
> […]
>>  Remove `//--...` horizontal separator comments
>>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0ac18d40
>
> This one did not remove the additional newlines if there was a blank line
> before and after the marker.

This is not a problem. The empty lines will be removed by clang-format.
-- 

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] Code style auto-formatting

2016-05-09 Thread Rolf Eike Beer
Am Montag, 9. Mai 2016, 13:14:17 schrieb Brad King:
> On 05/02/2016 10:08 AM, Brad King wrote:
> > Next I'll look at the style updates themselves.
> 
> I've made some more preparatory commits:

[…]
>  Remove `//--...` horizontal separator comments
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0ac18d40

This one did not remove the additional newlines if there was a blank line 
before and after the marker.

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

Re: [cmake-developers] Code style auto-formatting

2016-05-09 Thread Brad King
On 05/02/2016 10:08 AM, Brad King wrote:
> Next I'll look at the style updates themselves.

I've made some more preparatory commits:

 Isolate formatted streaming blocks with clang-format off/on
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=64b55203

 Move comments off of class access specifier lines
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=85425a3e

 Help clang-format wrap after braces on long initializer lists
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=afca3735

 Remove `//--...` horizontal separator comments
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0ac18d40

These changes improve the formatting output in some local
experiments.

With the earlier changes to the #include order we no longer need
to use any custom `IncludeCategories`.

Here is the `.clang-format` file I'd like to use:

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

Plus the custom one for Cpp11 in Tests/CompileFeatures.

The next few weeks will be a good time to do a one-shot
style change commit because the feature freeze for the
CMake 3.6 release is June 1.  It is important to do sweeping
changes like this shortly before a release branch is created
because that way any fixes that must be backported to the
branch do not conflict with the style change.  Furthermore
most fixes needed to the previous release have already been
done.  If we don't do it now we will have to wait about
4 months for the next stable period.

If the above looks good I'll start an ANNOUNCE thread for
this to draw more attention to it.  While it will be possible
to script style updates while rebasing topics across this
change, it will be simpler if developers start new topics
after the style change.

-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] Code style auto-formatting

2016-05-02 Thread Brad King
On 04/28/2016 10:26 AM, Brad King wrote:
> Thanks!  I'll try that out myself when I get a chance.
> 
> Meanwhile I've applied these cleanups

I decided to get the include ordering and block organization
worked out so that we don't need the special case for
cmStandardIncludes.h ordering.  Also I've pre-formatted
the include ordering so that we can make the rest of the
style changes without affecting compilation.  Here are the
changes:

 Merge topic 'clang-format-include-order'
 https://cmake.org/gitweb?p=cmake.git;a=commit;h=067b21b6

Next I'll look at the style updates themselves.

-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] Code style auto-formatting

2016-04-28 Thread Brad King
On 04/27/2016 07:12 PM, Daniel Pfeifer wrote:
> It took a while, but i figured out .clang-format definitions (there
> are two required) and a script that, after applying, does not break
> compilation and unit tests.

Thanks!  I'll try that out myself when I get a chance.

> I have attached a patch that adds the .clang-format and two other
> patches that need to be applied before reformatting.

Meanwhile I've applied these cleanups:

 CursesDialog: add missing cmState include
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bb8fdcf6

 Tests: add blank line between includes in StringFileTest
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=29abee03

-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] Code style auto-formatting

2016-04-27 Thread Daniel Pfeifer
On Thu, Nov 19, 2015 at 3:26 PM, Brad King  wrote:
> On 11/19/2015 09:22 AM, Robert Dailey wrote:
>> Tonight I will do some testing and submit a patch + example files
>> converted to the style Brad suggested. We can fine-tune it as needed.
>
> Rather than a patch please work on a script to perform the conversion.
> Then at any time we can choose to run the script as the one-shot conversion
> and commit as a robot user.  Any sweeping patch would be too big to
> post to the list anyway.  Ideally the script should be simple enough
> to cut-n-paste into a shell so we can just record it in the commit
> message.
>
> See this commit for an example of this approach:
>
>  https://cmake.org/gitweb?p=cmake.git;a=commit;h=7bbaa428

It took a while, but i figured out .clang-format definitions (there
are two required) and a script that, after applying, does not break
compilation and unit tests.

The .clang-format for the root directory looks like this:

---
BasedOnStyle: Mozilla
AlignAfterOpenBracket: false
AlignOperands: false
AllowShortFunctionsOnASingleLine: None
AlwaysBreakAfterDefinitionReturnType: None
AlwaysBreakAfterReturnType: None
ColumnLimit: 79
ContinuationIndentWidth: 4
IncludeCategories:
 - Regex: 'cmStandardIncludes'
   Priority: -1
Standard: Cpp03
...

This is the script to perform the reformatting of most C/C++ source code:

git ls-files -z -- '*.c' '*.cc' '*.cpp' '*.cxx' '*.h' '*.hh' '*.hpp' '*.hxx' \
| egrep -z -v '(Lexer|Parser|ParserHelper)\.' \
| egrep -z -v '^(Utilities/(KW|cm).*/|Source/(kwsys|CursesDialog/form)/)' \
| egrep -z -v '^Tests/Module/GenerateExportHeader' \
| egrep -z -v '^Tests/RunCMake/CommandLine/cmake_depends/test_UTF-16LE.h' \
| xargs -0 clang-format -i

I have attached a patch that adds the .clang-format and two other
patches that need to be applied before reformatting.
I have pushed all those changes (including reformatting) to github:
https://github.com/purpleKarrot/CMake/commits/clang-format


Notes:

* Trying to reformat
Tests/RunCMake/CommandLine/cmake_depends/test_UTF-16LE.h makes
clang-format crash.

* Clang-Format dedents preprocessor directives. See also:
https://llvm.org/bugs/show_bug.cgi?id=17362

* I did not include '*.in' files in the list, because Clang-Format
does strange things to @VARIALES@.


Please feel free to add/remove options from the .clang-format files.
IncludeCategories and Standard should stay as they are.

cheers, Daniel
From 452087a4b9f05742aed38040ab8d9b970fd05719 Mon Sep 17 00:00:00 2001
From: Daniel Pfeifer 
Date: Wed, 27 Apr 2016 22:47:02 +0200
Subject: [PATCH 1/3] CursesDialog: add missing cmState include

---
 Source/CursesDialog/cmCursesMainForm.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Source/CursesDialog/cmCursesMainForm.h b/Source/CursesDialog/cmCursesMainForm.h
index 255c823..d194168 100644
--- a/Source/CursesDialog/cmCursesMainForm.h
+++ b/Source/CursesDialog/cmCursesMainForm.h
@@ -13,6 +13,7 @@
 #define cmCursesMainForm_h
 
 #include "../cmStandardIncludes.h"
+#include "../cmState.h"
 #include "cmCursesForm.h"
 #include "cmCursesStandardIncludes.h"
 
-- 
2.8.0

From de7ca8575286bf995a771f894bf5087698686482 Mon Sep 17 00:00:00 2001
From: Daniel Pfeifer 
Date: Wed, 27 Apr 2016 23:29:43 +0200
Subject: [PATCH 2/3] StringFileTest: add blank line between includes

This test generates a header file which is not self-contained.
Since Clang-Format reorders includes alphabetically, this makes the test
fail.  Add a blank line to introduce a logical separation between two
blocks of include files.
---
 Tests/StringFileTest/StringFile.cxx | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Tests/StringFileTest/StringFile.cxx b/Tests/StringFileTest/StringFile.cxx
index 9eba6bf..073e30c 100644
--- a/Tests/StringFileTest/StringFile.cxx
+++ b/Tests/StringFileTest/StringFile.cxx
@@ -1,5 +1,6 @@
 #include 
 #include 
+
 #include "OutputFile.h"
 
 int main(int, char*[])
-- 
2.8.0

From 8feb2d2efc1287048ca66305db222bb197dcba4d Mon Sep 17 00:00:00 2001
From: Daniel Pfeifer 
Date: Wed, 27 Apr 2016 20:31:23 +0200
Subject: [PATCH 3/3] add .clang-format configuration files

For most of the code, Standard must be set to Cpp03,
so that `A` is not rewritten as `A`.

For the code under Tests/CompileFeatures, Standard must be set to Cpp11,
so that `U"foo"` is not rewritten as `U "foo"`.

Priorize the "cmStandardIncludes.h" header,
so that it is always included first.
---
 .clang-format   | 14 ++
 Tests/CompileFeatures/.clang-format | 11 +++
 2 files changed, 25 insertions(+)
 create mode 100644 .clang-format
 create mode 100644 Tests/CompileFeatures/.clang-format

diff --git a/.clang-format b/.clang-format
new file mode 100644
index 000..4076bcd
--- /dev/null
+++ b/.clang-format
@@ -0,0 +1,14 @@
+---
+BasedOnStyle: Mozilla
+AlignAfterOpenBracket: false
+AlignOperands: false
+AllowShortFunctionsOnASingleLine: None

Re: [cmake-developers] Code style auto-formatting

2015-11-19 Thread Robert Dailey
On Wed, Nov 18, 2015 at 5:47 PM, Alan W. Irwin
 wrote:
> On 2015-11-17 16:44-0600 Robert Dailey wrote:
>
>> [...]Honestly all of this is a matter of taste, I don't expect
>> everyone to agree on every little detail. I think the goal should be
>> to strive for something a little more modern (determined by general
>> consensus in the open source community) and most importantly enforce
>> it. No matter what style you choose, consistency is what matters the
>> most.
>
>
> Well said.  We used similar principles in the PLplot case and the
> resulting code style consistency (implemented with uncrustify in that
> case) within that project has been quite beneficial.

Tonight I will do some testing and submit a patch + example files
converted to the style Brad suggested. We can fine-tune it as needed.
I'll probably format cmake.h / cmake.cxx as an example.

Note also that there is an extension for Visual Studio that lets you
run clang format. I've used this and it's pretty useful. The link
below (bottom of the page) has the link to download the plugin.

http://llvm.org/builds/
-- 

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] Code style auto-formatting

2015-11-19 Thread Brad King
On 11/19/2015 09:22 AM, Robert Dailey wrote:
> Tonight I will do some testing and submit a patch + example files
> converted to the style Brad suggested. We can fine-tune it as needed.

Rather than a patch please work on a script to perform the conversion.
Then at any time we can choose to run the script as the one-shot conversion
and commit as a robot user.  Any sweeping patch would be too big to
post to the list anyway.  Ideally the script should be simple enough
to cut-n-paste into a shell so we can just record it in the commit
message.

See this commit for an example of this approach:

 https://cmake.org/gitweb?p=cmake.git;a=commit;h=7bbaa428

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] Code style auto-formatting

2015-11-19 Thread Robert Dailey
On Thu, Nov 19, 2015 at 8:26 AM, Brad King  wrote:
> On 11/19/2015 09:22 AM, Robert Dailey wrote:
>> Tonight I will do some testing and submit a patch + example files
>> converted to the style Brad suggested. We can fine-tune it as needed.
>
> Rather than a patch please work on a script to perform the conversion.
> Then at any time we can choose to run the script as the one-shot conversion
> and commit as a robot user.  Any sweeping patch would be too big to
> post to the list anyway.  Ideally the script should be simple enough
> to cut-n-paste into a shell so we can just record it in the commit
> message.
>
> See this commit for an example of this approach:
>
>  https://cmake.org/gitweb?p=cmake.git;a=commit;h=7bbaa428

Sorry for the confusion, what I meant was a patch with just the clang
format file in it. I do not plan to perform any conversions in any
patch.
-- 

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] Code style auto-formatting

2015-11-18 Thread Brad King
On 11/17/2015 05:44 PM, Robert Dailey wrote:
> http://clang.llvm.org/docs/ClangFormatStyleOptions.html
> 
> Mozilla's standard looks reasonable.

I've been leaning toward that one too, with slight tweaks.
Perhaps:

  BasedOnStyle: Mozilla
  AlignOperands:false
  ColumnLimit:  79
  IndentCaseLabels: false

-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] Code style auto-formatting

2015-11-18 Thread Alan W. Irwin

On 2015-11-17 16:44-0600 Robert Dailey wrote:


[...]Honestly all of this is a matter of taste, I don't expect
everyone to agree on every little detail. I think the goal should be
to strive for something a little more modern (determined by general
consensus in the open source community) and most importantly enforce
it. No matter what style you choose, consistency is what matters the
most.


Well said.  We used similar principles in the PLplot case and the
resulting code style consistency (implemented with uncrustify in that
case) within that project has been quite beneficial.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__
--

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] Code style auto-formatting

2015-11-17 Thread Paul Smith
On Tue, 2015-11-17 at 08:14 +, Stuermer, Michael SP/HZA-ZSEP wrote:
> In short, there is no fully automated style checking. If someone would
> come up with a tool & configuration I would love to use this. So far I
> tested astyle and the C++ edition of ReSharper (unfortunately quite
> expensive).

We've used uncrustify with excellent results in the past, FWIW.

It is a major hassle though.  We did a complete code reformat with a
well-defined process, and then had all developers apply reformatting to
their personal branches using a particular set of steps to minimize the
insanity.

-- 

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] Code style auto-formatting

2015-11-17 Thread Stuermer, Michael SP/HZA-ZSEP


> -Original Message-
> From: Kislinskiy, Stefan [mailto:s.kislins...@dkfz-heidelberg.de]
> Sent: Tuesday, November 17, 2015 10:11 AM
> To: Stuermer, Michael SP/HZA-ZSEP; CMake Developers
> Subject: AW: [cmake-developers] Code style auto-formatting
> 
> Do you know ClangFormat[1]? Pretty popular choice these days. You just put
> a format description file into your repository (which can be based on popular
> styles + your exceptions to keep the file rather small). It can be integrated
> into many editors including the Visual Studio IDE. 
 
Sounds promising. For CMake a configuration file would be needed which changes 
the existing code as less as possible. If something like that exists and it is 
easy to handle I believe some developers might use it. Still someone would have 
to do the work of setting up/configuring everything :-) .

> You probably want to add a
> hook to your git repository to automatically format your code when
> committing. See the link for details.

Ok, this is only my opinion, but changing the actual  changeset automatically 
within a commit hook is one oft he worst things you can do with hook scripting. 
Style checking or refusal of badly styled code is ok.

> 
> Best regards,
> Stefan
> 
> [1] http://clang.llvm.org/docs/ClangFormat.html
> 
> 
> Von: cmake-developers [cmake-developers-boun...@cmake.org] im
> Auftrag von Stuermer, Michael  SP/HZA-ZSEP
> [michael.stuer...@schaeffler.com]
> Gesendet: Dienstag, 17. November 2015 09:14
> An: CMake Developers
> Betreff: Re: [cmake-developers] Code style auto-formatting
> 
> I asked something similar half a year ago:
> 
> https://cmake.org/pipermail/cmake-developers/2015-June/025498.html
> 
> In short, there is no fully automated style checking. If someone would come
> up with a tool & configuration I would love to use this. So far I tested 
> astyle
> and the C++ edition of ReSharper (unfortunately quite expensive).
> 
> The more complicated thing would be, that you have to run the formatter
> over all existing code and thus you would introduce a huge amount of
> meaningless changes. I believe (and partially understand) many developers
> here on the list wouldn't really like large cosmetic changes like this.
> 
> best regards,
> Michael
> 
> > -Original Message-
> > From: cmake-developers [mailto:cmake-developers-boun...@cmake.org]
> > On Behalf Of Robert Dailey
> > Sent: Tuesday, November 17, 2015 3:01 AM
> > To: CMake Developers
> > Subject: [cmake-developers] Code style auto-formatting
> >
> > IMHO, the code style in the CMake code base is incredibly
> > inconsistent, but even the consistent style that is there is a giant pain to
> follow by hand.
> >
> > I'm constantly fighting my tooling's auto formatting. I prefer to keep
> > my code additions similar to surrounding code. Do you use some tool
> > such as clang- format to auto format code? This will make it easier to
> > make my style more consistent after my work is completed.
> >
> > Thanks in advance.
> > --
> >
> > 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
-- 

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

Re: [cmake-developers] Code style auto-formatting

2015-11-17 Thread Robert Dailey
On Tue, Nov 17, 2015 at 3:35 PM, Brad King  wrote:
> Hi Folks,
>
> For reference, the current CMake indentation style is:
>
>  https://en.wikipedia.org/wiki/Indent_style#Whitesmiths_style
>
> but with 2 space indentation instead of 4 as shown on that page.
> The style was popular when CMake started (year 2000) but is not
> very widely used anymore.
>
> For Emacs, see attached file (that comes from VTK folks that also
> use the style.  For Vim one can use something like:
>
>  set tabstop=2 shiftwidth=2 expandtab
>  set cindent cinoptions={1s,l1,g0,c0,t0,(0,W1s
>
> Since the style is not very popular anymore I don't know whether
> other editors can be configured for it.  For this reason I've
> been thinking about proposing use of clang-format for a while.
> We could also consider switching to a more widely-used indentation
> style outright and using clang-format to define it formally.
>
> On 11/17/2015 04:29 PM, Daniel Pfeifer wrote:
>> On Tue, Nov 17, 2015 at 10:12 PM, Robert Dailey wrote:
>>> How did you guys want to approach reformatting inconsistently
>>> formatted source files?
>>
>> I would say: As a byproduct.
>>
>> Adding a .clang-format file to CMake would be greatly appreciated. It
>> can be used to ensure that refactorings and new contributions follow
>> exactly the predefined style. However, changing existing code simply
>> because it does not match the style is something that should be
>> refused.
>
> I think we could do a one-shot conversion of existing sources.  This
> was done in our CMakeLists.txt and *.cmake files a while ago to update
> capitalization style.  We recorded the commit as done by a robot user
> instead of a specific developer's name.  It is not that hard to
> re-invoke `git blame` to see past any blame poisoning such a commit
> might introduce.  For that cost, we gain consistency in the code
> and simplicity for patches.

So I'd like to propose first of all that we explore a new coding
standard. Let's make the changes we want to make. In the meantime, I
will reflect that discussion into a clang format file. I'll provide it
as an attachment here, along with some samples of conversions of
existing files in the code base so we can get an idea of how it looks.

I agree with Brad about a mass one time conversion. BTW you can
instruct git blame to ignore whitespace changes; this would
effectively ignore the "whitespace robot" commit entirely (so you
don't even have to use a robot user if you didn't want to, but it's
still a great idea and doesn't hurt).

To get some discussion going, take a look at the BasedOnStyle option
in clang format:
http://clang.llvm.org/docs/ClangFormatStyleOptions.html

There are a couple of predefined formats you could use here. Obviously
choosing one of those as a base and then fine-tuning it to your needs
would probably be the best approach. Mozilla's standard looks
reasonable. Honestly all of this is a matter of taste, I don't expect
everyone to agree on every little detail. I think the goal should be
to strive for something a little more modern (determined by general
consensus in the open source community) and most importantly enforce
it. No matter what style you choose, consistency is what matters the
most.
-- 

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] Code style auto-formatting

2015-11-17 Thread Kislinskiy, Stefan
Do you know ClangFormat[1]? Pretty popular choice these days. You just put a 
format description file into your repository (which can be based on popular 
styles + your exceptions to keep the file rather small). It can be integrated 
into many editors including the Visual Studio IDE. You probably want to add a 
hook to your git repository to automatically format your code when committing. 
See the link for details.

Best regards,
Stefan

[1] http://clang.llvm.org/docs/ClangFormat.html


Von: cmake-developers [cmake-developers-boun...@cmake.org] im Auftrag von 
Stuermer, Michael  SP/HZA-ZSEP [michael.stuer...@schaeffler.com]
Gesendet: Dienstag, 17. November 2015 09:14
An: CMake Developers
Betreff: Re: [cmake-developers] Code style auto-formatting

I asked something similar half a year ago:

https://cmake.org/pipermail/cmake-developers/2015-June/025498.html

In short, there is no fully automated style checking. If someone would come up 
with a tool & configuration I would love to use this. So far I tested astyle 
and the C++ edition of ReSharper (unfortunately quite expensive).

The more complicated thing would be, that you have to run the formatter over 
all existing code and thus you would introduce a huge amount of meaningless 
changes. I believe (and partially understand) many developers here on the list 
wouldn't really like large cosmetic changes like this.

best regards,
Michael

> -Original Message-
> From: cmake-developers [mailto:cmake-developers-boun...@cmake.org]
> On Behalf Of Robert Dailey
> Sent: Tuesday, November 17, 2015 3:01 AM
> To: CMake Developers
> Subject: [cmake-developers] Code style auto-formatting
>
> IMHO, the code style in the CMake code base is incredibly inconsistent, but
> even the consistent style that is there is a giant pain to follow by hand.
>
> I'm constantly fighting my tooling's auto formatting. I prefer to keep my code
> additions similar to surrounding code. Do you use some tool such as clang-
> format to auto format code? This will make it easier to make my style more
> consistent after my work is completed.
>
> Thanks in advance.
> --
>
> 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
-- 

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] Code style auto-formatting

2015-11-17 Thread Brad King
Hi Folks,

For reference, the current CMake indentation style is:

 https://en.wikipedia.org/wiki/Indent_style#Whitesmiths_style

but with 2 space indentation instead of 4 as shown on that page.
The style was popular when CMake started (year 2000) but is not
very widely used anymore.

For Emacs, see attached file (that comes from VTK folks that also
use the style.  For Vim one can use something like:

 set tabstop=2 shiftwidth=2 expandtab
 set cindent cinoptions={1s,l1,g0,c0,t0,(0,W1s

Since the style is not very popular anymore I don't know whether
other editors can be configured for it.  For this reason I've
been thinking about proposing use of clang-format for a while.
We could also consider switching to a more widely-used indentation
style outright and using clang-format to define it formally.

On 11/17/2015 04:29 PM, Daniel Pfeifer wrote:
> On Tue, Nov 17, 2015 at 10:12 PM, Robert Dailey wrote:
>> How did you guys want to approach reformatting inconsistently
>> formatted source files?
> 
> I would say: As a byproduct.
> 
> Adding a .clang-format file to CMake would be greatly appreciated. It
> can be used to ensure that refactorings and new contributions follow
> exactly the predefined style. However, changing existing code simply
> because it does not match the style is something that should be
> refused.

I think we could do a one-shot conversion of existing sources.  This
was done in our CMakeLists.txt and *.cmake files a while ago to update
capitalization style.  We recorded the commit as done by a robot user
instead of a specific developer's name.  It is not that hard to
re-invoke `git blame` to see past any blame poisoning such a commit
might introduce.  For that cost, we gain consistency in the code
and simplicity for patches.

-Brad

(require 'cc-mode)

; Indent code within block by c-basic-offset only if in column 0
(defun vtk-c-defun-block-intro (dummy)
  (save-excursion
(back-to-indentation)
(if (= (save-excursion (re-search-backward "{" 1) (current-column)) 0)
	c-basic-offset 0)))

; Don't indent code inside a namespace.
(defun vtk-c-innamespace (dummy)
  (save-excursion
(back-to-indentation)
(if (= (save-excursion (re-search-backward "{" 1) (current-column)) 0)
0 c-basic-offset)))

; Hold the VTK indentation style.
(defvar vtk-c-style
  '((c-backslash-column . 78)
(c-basic-offset . 2)
(c-comment-only-line-offset . (0 . 0))
(c-offsets-alist . ((substatement-open  . +)
(statement-block-intro  . 0)
(statement-case-open. +)
(case-label . 0)
(defun-block-intro vtk-c-defun-block-intro)
(statement-block-intro vtk-c-defun-block-intro)
(innamespace   vtk-c-innamespace)
))
(c-tab-always-indent . t)
)
  "VTK Indentation Style")

(c-add-style "vtk" vtk-c-style)

(provide 'vtk-c-style)
-- 

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] Code style auto-formatting

2015-11-17 Thread Daniel Pfeifer
On Tue, Nov 17, 2015 at 10:12 PM, Robert Dailey
 wrote:
> On Tue, Nov 17, 2015 at 6:57 AM, Paul Smith  wrote:
>> On Tue, 2015-11-17 at 08:14 +, Stuermer, Michael SP/HZA-ZSEP wrote:
>>> In short, there is no fully automated style checking. If someone would
>>> come up with a tool & configuration I would love to use this. So far I
>>> tested astyle and the C++ edition of ReSharper (unfortunately quite
>>> expensive).
>>
>> We've used uncrustify with excellent results in the past, FWIW.
>>
>> It is a major hassle though.  We did a complete code reformat with a
>> well-defined process, and then had all developers apply reformatting to
>> their personal branches using a particular set of steps to minimize the
>> insanity.
>>
>
> I'm willing to assist with a clang format file, I've worked with them
> in the past. This means contributions will likely come with multiple
> patch files, some containing only whitespace fixups per the clang
> format.
>
> How did you guys want to approach reformatting inconsistently
> formatted source files?

I would say: As a byproduct.

Adding a .clang-format file to CMake would be greatly appreciated. It
can be used to ensure that refactorings and new contributions follow
exactly the predefined style. However, changing existing code simply
because it does not match the style is something that should be
refused.

git-clang-format can fix the formatting of staged hunks without
changing the rest of the files.

-- Daniel
-- 

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] Code style auto-formatting

2015-11-17 Thread Robert Dailey
On Tue, Nov 17, 2015 at 6:57 AM, Paul Smith  wrote:
> On Tue, 2015-11-17 at 08:14 +, Stuermer, Michael SP/HZA-ZSEP wrote:
>> In short, there is no fully automated style checking. If someone would
>> come up with a tool & configuration I would love to use this. So far I
>> tested astyle and the C++ edition of ReSharper (unfortunately quite
>> expensive).
>
> We've used uncrustify with excellent results in the past, FWIW.
>
> It is a major hassle though.  We did a complete code reformat with a
> well-defined process, and then had all developers apply reformatting to
> their personal branches using a particular set of steps to minimize the
> insanity.
>

I'm willing to assist with a clang format file, I've worked with them
in the past. This means contributions will likely come with multiple
patch files, some containing only whitespace fixups per the clang
format.

How did you guys want to approach reformatting inconsistently
formatted source files?

Git has plenty of options to ignore whitespace in different ways, so
it's really a non-issue as far as auditability of logs and diffs go.
-- 

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] Code style auto-formatting

2015-11-16 Thread Robert Dailey
IMHO, the code style in the CMake code base is incredibly
inconsistent, but even the consistent style that is there is a giant
pain to follow by hand.

I'm constantly fighting my tooling's auto formatting. I prefer to keep
my code additions similar to surrounding code. Do you use some tool
such as clang-format to auto format code? This will make it easier to
make my style more consistent after my work is completed.

Thanks in advance.
-- 

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