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

[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] Add CXX_STANDARD support for Intel C++ compilers

[Brad King]

On 11/16/2015 03:14 PM, Levi Morrison wrote:
> It seems my attachments are getting scrubbed or something? 

It was just that one message that was missing one.  This one worked.

>> How did you test these?  For full testing we need the CMake test
>> suite to pass with the Intel compilers.  In particular, tests with
>> 'CompileFeatures' in their name cover this functionality.
> 
> I was able to build and use (or not use as appropriately) C++11 and
> C++14 for a given project I already have.

Good start.

> What is the proper way to do run the test suite for a given compiler?

One can run the entire test suite like this:

 export CC=icc CXX=icpc
 mkdir CMake-intel-tests && cd CMake-intel-tests
 cmake ../CMake -DCMake_TEST_EXTERNAL_CMAKE="/path/to/main/CMake-build/bin"
 make
 ctest

Or on the last step run just specific tests:

 ctest -R CompileFeatures -V

I just tried the patch locally.  While these tests do pass, the compile
features are not actually recorded.  What is missing is a file called

 Modules/Compiler/Intel-CXX-FeatureTests.cmake

that records how to use the preprocessor to test for the version of the
compiler that adds each feature.  See these for some examples:

 Modules/Compiler/GNU-CXX-FeatureTests.cmake
 Modules/Compiler/MSVC-CXX-FeatureTests.cmake

Then the Tests/CompileFeatures/CMakeLists.txt file also needs to be
updated to enable testing for versions of the Intel compiler that are
expected to work.

Building the feature table may not be a trivial task.  It is one of
the reasons no one has added support yet.  If you have access to
versions 12, 13, 14, 15, then running the test suite with each of
those will help verify the table correctness.

-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

[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. 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:

[cmake-developers] FindGTest.cmake and CMP0064

[David Chen]

We’ve been getting a warning from FindGTest.cmake about CMP0064 when building SimpleITK.  The warning occurs at lines 127, 129 and 131 when the variable ${test_type} is equal to “TEST”.  With CMP0064 this TEST could be interpreted as commands in the if() and elseif() statements unless the policy is set to OLD.I’ve attached a patch for your consideration that re-writes those statements.  I have changed the STREQUAL comparisons to regex MATCHES comparisons.  This change removes the possibility of “TEST” being the first word inside the parentheses.

0001-Refactored-if-statements-for-TEST.patch
Description: Binary data

David T. Chen, PhD                      [MSC contractor]mailto:dc...@mail.nih.gov               http://lhncbc.nlm.nih.gov/personnel/david-chenphone:301.435.3264                      iphone:301.524.3174Office of High Performance Computing and CommunicationsNational Library of Medicine

-- 

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] User may now specify toolset through CMake GUI

[Brad King]

On 11/16/2015 10:52 PM, Robert Dailey wrote:
> I also forgot to mention that this patch is based on the 'next'
> branch. Originally it was based on 'master' but I rebased it to
> 'next'. Let me know if this is correct. I'm assuming the master branch
> is used for maintenance releases only and would not be appropriate for
> such a change.

Actually 'release' is for maintenance, 'master' is for development,
and 'next' is for testing.  Patches should be based on 'master' as
mentioned in CONTRIBUTING.rst.  In this case I was able to apply
the patch cleanly to 'master' anyway.

Applied with a few tweaks:

 cmake-gui: Add option to specify generator toolset
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2b958a20

The dialog box option works for me with VS and Xcode generators.

Thanks,
-Brad

-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] [CMake 0015848]: Generalize RESOURCE target property to by used by all Bundles (not only by FRAMEWORK)

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://public.kitware.com/Bug/view.php?id=15848 
== 
Reported By:gang65
Assigned To:
== 
Project:CMake
Issue ID:   15848
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2015-11-17 09:54 EST
Last Modified:  2015-11-17 09:54 EST
== 
Summary:Generalize RESOURCE target property to by used by
all Bundles (not only by FRAMEWORK)
Description: 
Currently RESOURCE target property is used only for FRAMEWORK
https://cmake.org/cmake/help/v3.4/prop_tgt/RESOURCE.html

It will be great to reuse such property for all bundles:
https://developer.apple.com/library/mac/documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html

The basic structure of a Mac app:
MyApp.app/
   Contents/
  Info.plist
  MacOS/
  Resources

It could be also be used for iOS Frameworks:

Bundle structure of an iOS application (flat structure):
MyApp.app
   MyApp
   MyAppIcon.png
   MySearchIcon.png
   Info.plist
   Default.png
   MainWindow.nib
   Settings.bundle
   MySettingsIcon.png

Steps to Reproduce: 
What needs to be done:
- Implement such solution for Application Bundle and Core Foundation Bundle
- Add unit tests
- Update documentation

Additional Information: 
I would like to be volunteer for that task, if there will be agreement about
such solution
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-11-17 09:54 gang65 New Issue
==

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] FindGTest.cmake and CMP0064

[Rolf Eike Beer]

Am 17.11.2015 17:08, schrieb David Chen:

We’ve been getting a warning from FindGTest.cmake about CMP0064 when
building SimpleITK.  The warning occurs at lines 127, 129 and 131 when
the variable ${test_type} is equal to “TEST”.  With CMP0064 this TEST
could be interpreted as commands in the if() and elseif() statements
unless the policy is set to OLD.

I’ve attached a patch for your consideration that re-writes those
statements.  I have changed the STREQUAL comparisons to regex MATCHES
comparisons.  This change removes the possibility of “TEST” being the
first word inside the parentheses.


The correct fix would probably to just remove the dereference, i.e. 
change


  if(${test_type} STREQUAL "TEST_P")

to

  if(test_type STREQUAL "TEST_P")

Greetings,

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] CMake 3.40, CMAKE_C_STANDARD_COMPUTED_DEFAULT and LTO

[Brad King]

On 11/17/2015 11:03 AM, Setze Post wrote:
> First ever upstreamed upstreamed mail from me, please gently inform me
> if I took the wrong route here.
> Running Gentoo Linux x86_64 and compiling with LTO enabled in C*FLAGS,
> the configuration stage seems to fail compiling CMake 3.4.0 as described
> here: https://bugs.gentoo.org/show_bug.cgi?id=565744
> Compiling CMake without LTO worked flawlessly, however, the same problem
> seems to always occur when compiling other packages using CMake with LTO
> enabled for those packages. I managed to fix the issue for my local
> machines applying a patch I wrote, available here:
> https://bugs.gentoo.org/attachment.cgi?id=416970
> However, I am not very knowledgeable about C, configure/compile tool
> chains and CMake, so I imagine something totally unrelated might be
> going on here just as well.

Thanks!  You've come to the right place and the proposed change
is correct.  I've applied it here:

 Make C and C++ default dialect detection robust to advanced optimizations
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=716a09b9

I've also queued it for merge to 'release' for inclusion in 3.4.1.

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] Add CXX_STANDARD support for Intel C++ compilers

[Levi Morrison]

On Tue, Nov 17, 2015 at 6:50 AM, Brad King  wrote:

> On 11/16/2015 03:14 PM, Levi Morrison wrote:
> > It seems my attachments are getting scrubbed or something?
>
> It was just that one message that was missing one.  This one worked.
>
> >> How did you test these?  For full testing we need the CMake test
> >> suite to pass with the Intel compilers.  In particular, tests with
> >> 'CompileFeatures' in their name cover this functionality.
> >
> > I was able to build and use (or not use as appropriately) C++11 and
> > C++14 for a given project I already have.
>
> Good start.
>
> > What is the proper way to do run the test suite for a given compiler?
>
> One can run the entire test suite like this:
>
>  export CC=icc CXX=icpc
>  mkdir CMake-intel-tests && cd CMake-intel-tests
>  cmake ../CMake -DCMake_TEST_EXTERNAL_CMAKE="/path/to/main/CMake-build/bin"
>  make
>

:D Funnily enough

>  ctest
>
> Or on the last step run just specific tests:
>
>  ctest -R CompileFeatures -V
>
> I just tried the patch locally.  While these tests do pass, the compile
> features are not actually recorded.  What is missing is a file called
>
>  Modules/Compiler/Intel-CXX-FeatureTests.cmake
>
> that records how to use the preprocessor to test for the version of the
> compiler that adds each feature.  See these for some examples:
>
>  Modules/Compiler/GNU-CXX-FeatureTests.cmake
>  Modules/Compiler/MSVC-CXX-FeatureTests.cmake
>
> Then the Tests/CompileFeatures/CMakeLists.txt file also needs to be
> updated to enable testing for versions of the Intel compiler that are
> expected to work.
>
> Building the feature table may not be a trivial task.  It is one of
> the reasons no one has added support yet.  If you have access to
> versions 12, 13, 14, 15, then running the test suite with each of
> those will help verify the table correctness.
>
> -Brad
>
>
I have updated Modules/Compiler/Intel-CXX-FeatureTests.cmake. It took a
while :D

I'm not sure how to edit Tests/CompileFeatures/CMakeLists.txt, though. I
don't even know what half of this file is trying to accomplish. It seems
like it is pure duplication of work; these checks are saying
EXPECT_C_STATIC_ASSERT=1 if some compiler conditions are true but I already
encoded that information in Intel-CXX-FeatureTests.cmake, didn't I?

In any case, it seems I still need to update something because after
editing that file I am unable to use `target_compile_features(sometarget
PRIVATE cxx_nullptr)`, etc. I get the message:

CMake Error at CMakeLists.txt:7 (target_compile_features):

  target_compile_features no known features for CXX compiler

  "Intel"

  version 15.0.3.20150407.
-- 

Powered by www.kitware.com

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

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

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

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

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

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

[Levi Morrison]

On Tue, Nov 17, 2015 at 11:13 AM, Levi Morrison 
wrote:

> On Tue, Nov 17, 2015 at 6:50 AM, Brad King  wrote:
>
>> On 11/16/2015 03:14 PM, Levi Morrison wrote:
>> > It seems my attachments are getting scrubbed or something?
>>
>> It was just that one message that was missing one.  This one worked.
>>
>> >> How did you test these?  For full testing we need the CMake test
>> >> suite to pass with the Intel compilers.  In particular, tests with
>> >> 'CompileFeatures' in their name cover this functionality.
>> >
>> > I was able to build and use (or not use as appropriately) C++11 and
>> > C++14 for a given project I already have.
>>
>> Good start.
>>
>> > What is the proper way to do run the test suite for a given compiler?
>>
>> One can run the entire test suite like this:
>>
>>  export CC=icc CXX=icpc
>>  mkdir CMake-intel-tests && cd CMake-intel-tests
>>  cmake ../CMake
>> -DCMake_TEST_EXTERNAL_CMAKE="/path/to/main/CMake-build/bin"
>>  make
>>
>
> :D Funnily enough
>

Oops, didn't finish that phrase. Can't remember what it was supposed to say
anymore. Guess it wasn't that funny.
-- 

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

[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] Add CXX_STANDARD support for Intel C++ compilers

[Brad King]

On 11/17/2015 03:23 PM, Levi Morrison wrote:
> Attached is the patch.

Thanks.  In the CompileFeatures test output one can see

Detecting CXX compile features - failed

Then in Tests/CompileFeatures/CMakeFiles/CMakeError.log one can see
the error:

.../Tests/CompileFeatures/CMakeFiles/feature_tests.cxx(32):
error #14: extra text after expected end of preprocessing directive
  #if __ICC >= 1500 __INTEL_CXX14_MODE__
^

This should fix it:

-set(Intel15_CXX14 "__ICC >= 1500 __INTEL_CXX14_MODE__")
+set(Intel15_CXX14 "__ICC >= 1500 && __INTEL_CXX14_MODE__")

After that the test runs so you can see the failures.

Also after fixing the above I see in
Tests/CompileFeatures/CMakeFiles/CMakeOutput.log the following:

Detecting CXX [-std=c++14] compiler features compiled with the following 
output:
...
icpc: command line warning #10159: invalid argument for option '-std'

This is with Intel 15.

More work may be needed to choose the proper flag based on the
version and platform:

 
https://software.intel.com/en-us/articles/c14-features-supported-by-intel-c-compiler
 "C++14 features can enabled by using /Qstd=c++14 on Windows
  and -std=c++14 on Linux and Mac OS X"

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] Add CXX_STANDARD support for Intel C++ compilers

[Levi Morrison]

>
> Also after fixing the above I see in
> Tests/CompileFeatures/CMakeFiles/CMakeOutput.log the following:
>
> Detecting CXX [-std=c++14] compiler features compiled with the
> following output:
> ...
> icpc: command line warning #10159: invalid argument for option '-std'
>
> This is with Intel 15.
>
> More work may be needed to choose the proper flag based on the
> version and platform:
>
>
> https://software.intel.com/en-us/articles/c14-features-supported-by-intel-c-compiler
>  "C++14 features can enabled by using /Qstd=c++14 on Windows
>   and -std=c++14 on Linux and Mac OS X"
>
> Thanks,
> -Brad
>

Hmm. Can you tell me what the value of -std was for that invocation?
-- 

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: Add imported targets

[Ruslan Baratov via cmake-developers]

On 17-Nov-15 15:48, Roger Leigh wrote:

On 17/11/2015 07:53, Ruslan Baratov wrote:

On 16-Nov-15 21:01, rle...@codelibre.net wrote:
I have attached a patch to add imported targets to FindBoost, in the 
form

of Boost:: (e.g. Boost::date_time) or Boost::Boost as a
generic
interface library for header-only components.

Since it's `Boost::date_time` I expect that it will be `Boost::boost`
(lowercase).


Yes, I've merged most of the previous work Brad pointed to yesterday, 
and this included this change.



On 16-Nov-15 21:39, Brad King wrote:

On 11/16/2015 09:26 AM, Florent Castelli wrote:

But one there’s one thing that comes to mind. Some compiled libraries
have dependencies on other compiled libraries.
Don’t you think it would make sense to teach FindBoost about those
so we link everything properly?

And also maybe add the native dependencies for some modules that
have one like maybe pthread or openssl.
Though, this might be hard to get right in a cross platform way.

Please look at adding these.  The imported targets should come
with all usage requirements as if they were provided by upstream
Boost.  It may be tricky to get right on all platforms but if we
do not do it then application code will have to do it instead.



One tricky part about it is that dependency can be optional. I.e.
Boost::iostreams may or may not depends on ZLIB/BZip2. Such information
is known only by build procedure. I.e. should be installed by b2 itself
or by wrapped ExternalProject_Add instructions.


For the specific case of the zlib/bzip2 dependencies, this is only the 
case when using the static libraries?  It's not exposed via the 
headers is it?
I'm not sure about all aspects it's not my main point anyway :) I'm 
saying that this kind of information can be installed by CMake project 
and I can predict that it will be hard to achieve the same in 
FindBoost.cmake when build already done and this info is lost.




Looking at the information embedded in the sources for use with 
autolinking, we could certainly process the headers for the requested 
components and pull out the referenced libraries.  This would get us 
all of the header dependencies without hardcoding anything ourselves, 
which would make it work with arbitrary versions of boost without 
having to hardcode the differences between Boost versions.


Fully supporting static linking would be much more difficult.  As you 
say, it depends upon how Boost was built. 

...

Full support here would need to wait for the upstream to generate this 
data at build time?
This is a best option but not necessary. As I said earlier if you're 
using wrapper to install boost (like ExternalProject_Add) you can add 
some extra files which will hold this info.


Ruslan
--

Powered by www.kitware.com

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

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

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

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

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

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

[Brad King]

On 11/17/2015 03:57 PM, Levi Morrison wrote:
> Also, it is worth pointing out that some of the features are partially
> supported in earlier versions, but in the FeatureTests.cmake I put it
> only for the first version that claims complete compatibility
> - is that the correct action?

Yes, 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] Add CXX_STANDARD support for Intel C++ compilers

[Levi Morrison]

On Tue, Nov 17, 2015 at 1:23 PM, Levi Morrison 
wrote:

> > I'm not sure how to edit Tests/CompileFeatures/CMakeLists.txt, though.
>> > I don't even know what half of this file is trying to accomplish.
>> > It seems like it is pure duplication of work; these checks are saying
>> > EXPECT_C_STATIC_ASSERT=1 if some compiler conditions are true but
>> > I already encoded that information in Intel-CXX-FeatureTests.cmake
>>
>> It is duplicated because the test memorizes the answers to make sure
>> the detection works for known cases.  The EXPECT_... definitions
>> encode the expected results for the HAVE_... definitions that are
>> set by the $ generator expressions.  This
>> way the test ensures that the detection works and its results
>> propagate all the way through genex evaluation correctly.
>>
>> > In any case, it seems I still need to update something
>>
>> Please post the patch so far so we can look at it to see what may be
>> missing.  Once this part works then it may activate the real parts
>> of the CompileFeatures test and lead you to the portions of that test
>> that need to be filled in for the Intel compiler.
>>
>> Thanks,
>> -Brad
>>
>>
> Attached is the patch. I'm unsure if the `&& __INTEL_CXX11_MODE__` parts
> are needed. I was hoping I'd find out when running tests.
>

Also, it is worth pointing out that some of the features are partially
supported in earlier versions, but in the FeatureTests.cmake I put it only
for the first version that claims complete compatibility – is that the
correct action?
-- 

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: Add imported targets

[Roger Leigh]

On 17/11/2015 07:53, Ruslan Baratov wrote:

On 16-Nov-15 21:01, rle...@codelibre.net wrote:

I have attached a patch to add imported targets to FindBoost, in the form
of Boost:: (e.g. Boost::date_time) or Boost::Boost as a
generic
interface library for header-only components.

Since it's `Boost::date_time` I expect that it will be `Boost::boost`
(lowercase).


Yes, I've merged most of the previous work Brad pointed to yesterday, 
and this included this change.



On 16-Nov-15 21:39, Brad King wrote:

On 11/16/2015 09:26 AM, Florent Castelli wrote:

But one there’s one thing that comes to mind. Some compiled libraries
have dependencies on other compiled libraries.
Don’t you think it would make sense to teach FindBoost about those
so we link everything properly?

And also maybe add the native dependencies for some modules that
have one like maybe pthread or openssl.
Though, this might be hard to get right in a cross platform way.

Please look at adding these.  The imported targets should come
with all usage requirements as if they were provided by upstream
Boost.  It may be tricky to get right on all platforms but if we
do not do it then application code will have to do it instead.



One tricky part about it is that dependency can be optional. I.e.
Boost::iostreams may or may not depends on ZLIB/BZip2. Such information
is known only by build procedure. I.e. should be installed by b2 itself
or by wrapped ExternalProject_Add instructions.


For the specific case of the zlib/bzip2 dependencies, this is only the 
case when using the static libraries?  It's not exposed via the headers 
is it?


Looking at the information embedded in the sources for use with 
autolinking, we could certainly process the headers for the requested 
components and pull out the referenced libraries.  This would get us all 
of the header dependencies without hardcoding anything ourselves, which 
would make it work with arbitrary versions of boost without having to 
hardcode the differences between Boost versions.


Fully supporting static linking would be much more difficult.  As you 
say, it depends upon how Boost was built.  Full support here would need 
to wait for the upstream to generate this data at build time?



I'll have a look at doing the above and should have an updated patch soon.


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] [CPackRPM] Configure RPM package group and name per component

[Domen Vrankar]

2015-11-15 20:32 GMT+01:00 Markus Rickert :
> Hi,
>
> similar to the previous patch for CPackDeb, the attached patch adds
> component-specific settings for group and name of an RPM package.
>
> CPACK_RPM__PACKAGE_GROUP allows setting the group of the
> component with the main libraries to "Development/Libraries", while
> "Documentation" can be used for the component with the actual documentation.
>
> CPACK_RPM__PACKAGE_NAME can set the package name (not the
> filename) of a component, e.g., "foo" for libraries (instead of
> "foo-libraries") and "foo-devel" for headers.

I'll try to review it today.

Thanks,
Domen
-- 

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

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

[Michael Scott]

In particular,
I moved the hunk below forward to "Modify dev warning options to affect
deprecated warnings", the commit where it actually becomes needed
because the default changes.

I'm not sure I follow, which hunk are we talking about here?


Please add a Help/release/dev/cmake-W-options.rst file with release
notes for these changes.

Okay no problem.


This
means that adding "-Wno-dev" on a non-initial configuration will not
disable deprecation warnings because CMAKE_WARN_DEPRECATED is already
cached even though no explicit -W option was given before.

Ah that's a good point, I hadn't considered that set of steps, thanks.


As a user
I may expect those options to be loaded from the current cache in each
build tree I select.
Okay well I'll remove the related patch from the set for now and come 
back to it after we've got the main sorted out and applied.


Cheers,
Michael



--

Powered by www.kitware.com

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

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

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

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

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

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

[Brad King]

On 11/17/2015 01:13 PM, Levi Morrison wrote:
> I have updated Modules/Compiler/Intel-CXX-FeatureTests.cmake.

Great.

> I'm not sure how to edit Tests/CompileFeatures/CMakeLists.txt, though.
> I don't even know what half of this file is trying to accomplish.
> It seems like it is pure duplication of work; these checks are saying
> EXPECT_C_STATIC_ASSERT=1 if some compiler conditions are true but
> I already encoded that information in Intel-CXX-FeatureTests.cmake

It is duplicated because the test memorizes the answers to make sure
the detection works for known cases.  The EXPECT_... definitions
encode the expected results for the HAVE_... definitions that are
set by the $ generator expressions.  This
way the test ensures that the detection works and its results
propagate all the way through genex evaluation correctly.

> In any case, it seems I still need to update something

Please post the patch so far so we can look at it to see what may be
missing.  Once this part works then it may activate the real parts
of the CompileFeatures test and lead you to the portions of that test
that need to be filled in for the Intel compiler.

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] Add CXX_STANDARD support for Intel C++ compilers

[Levi Morrison]

>
> > I'm not sure how to edit Tests/CompileFeatures/CMakeLists.txt, though.
> > I don't even know what half of this file is trying to accomplish.
> > It seems like it is pure duplication of work; these checks are saying
> > EXPECT_C_STATIC_ASSERT=1 if some compiler conditions are true but
> > I already encoded that information in Intel-CXX-FeatureTests.cmake
>
> It is duplicated because the test memorizes the answers to make sure
> the detection works for known cases.  The EXPECT_... definitions
> encode the expected results for the HAVE_... definitions that are
> set by the $ generator expressions.  This
> way the test ensures that the detection works and its results
> propagate all the way through genex evaluation correctly.
>
> > In any case, it seems I still need to update something
>
> Please post the patch so far so we can look at it to see what may be
> missing.  Once this part works then it may activate the real parts
> of the CompileFeatures test and lead you to the portions of that test
> that need to be filled in for the Intel compiler.
>
> Thanks,
> -Brad
>
>
Attached is the patch. I'm unsure if the `&& __INTEL_CXX11_MODE__` parts
are needed. I was hoping I'd find out when running tests.


0001-Add-CXX_STANDARD-support-to-Intel-C-compilers.patch
Description: Binary data
-- 

Powered by www.kitware.com

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

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

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

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

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

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

[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

[cmake-developers] [CMake 0015849]: Linker failure when WINDOWS_EXPORT_ALL_SYMBOLS and /bigobj are used together in a Win64 build.

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://cmake.org/Bug/view.php?id=15849 
== 
Reported By:Chris M
Assigned To:
== 
Project:CMake
Issue ID:   15849
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2015-11-17 16:08 EST
Last Modified:  2015-11-17 16:08 EST
== 
Summary:Linker failure when WINDOWS_EXPORT_ALL_SYMBOLS and
/bigobj are used together in a Win64 build.
Description: 

Shared library fails to link when attempting to use
CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS when compiled with /bigobj.  

Only tested using Visual Studio 14 2015 Win64.

Test project attached.

It appears that printf-family function symbol names are being modified (leading
'_' removed) when cmake is processing *.obj into exportall.def.

Steps to Reproduce: 
Extract attached zip.

> mkdir build
> cd build
> cmake ../ -G "Visual Studio 14 2015 Win64" -DBUILD_BIGOBJ=ON
> cmake --build . --release Debug

== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-11-17 16:08 Chris MNew Issue
2015-11-17 16:08 Chris MFile Added:
windows-symbols-export-all-bigobj.zip
==

-- 

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

[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] Add CXX_STANDARD support for Intel C++ compilers

[Brad King]

On 11/17/2015 04:34 PM, Levi Morrison wrote:
> On Tue, Nov 17, 2015 at 2:07 PM, Levi Morrison wrote:
>>> icpc: command line warning #10159: invalid argument for option '-std'
>> Hmm. Can you tell me what the value of -std was for that invocation? 
> 
> Hazarding a guess I think it might be gnu++14 – can you confirm this?

It was `-std=c++14`.  I'm using:

 $ icpc --version
 icpc (ICC) 15.0.0 20140723

According to the `man icpc` page there is no -std=c++14 option.

-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] Add CXX_STANDARD support for Intel C++ compilers

[Levi Morrison]

On Tue, Nov 17, 2015 at 2:38 PM, Brad King  wrote:

> On 11/17/2015 04:34 PM, Levi Morrison wrote:
> > On Tue, Nov 17, 2015 at 2:07 PM, Levi Morrison wrote:
> >>> icpc: command line warning #10159: invalid argument for option '-std'
> >> Hmm. Can you tell me what the value of -std was for that invocation?
> >
> > Hazarding a guess I think it might be gnu++14 – can you confirm this?
>
> It was `-std=c++14`.  I'm using:
>
>  $ icpc --version
>  icpc (ICC) 15.0.0 20140723
>
> According to the `man icpc` page there is no -std=c++14 option.
>
> -Brad
>
>
It seems it was added in either 15.0.1 or 15.0.2. I can't find it in the
documentation. For now I will tell it 15.0.2 which I can confirm works.
-- 

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

[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

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

[Levi Morrison]

On Tue, Nov 17, 2015 at 2:07 PM, Levi Morrison 
wrote:

> Also after fixing the above I see in
>> Tests/CompileFeatures/CMakeFiles/CMakeOutput.log the following:
>>
>> Detecting CXX [-std=c++14] compiler features compiled with the
>> following output:
>> ...
>> icpc: command line warning #10159: invalid argument for option '-std'
>>
>> This is with Intel 15.
>>
>> More work may be needed to choose the proper flag based on the
>> version and platform:
>>
>>
>> https://software.intel.com/en-us/articles/c14-features-supported-by-intel-c-compiler
>>  "C++14 features can enabled by using /Qstd=c++14 on Windows
>>   and -std=c++14 on Linux and Mac OS X"
>>
>> Thanks,
>> -Brad
>>
>
> Hmm. Can you tell me what the value of -std was for that invocation?
>
>
Hazarding a guess I think it might be gnu++14 – can you confirm this?
-- 

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