Re: [GRASS-dev] Proposal for using ClangFormat, replacing GNU indent, for C/C++ code formatting

[Nicklas Larsson via grass-dev]

> On 7 Dec 2022, at 02:51, Vaclav Petras  wrote:
> 
> 
> 
> On Mon, 5 Dec 2022 at 08:07, Nicklas Larsson via grass-dev 
> mailto:grass-dev@lists.osgeo.org>> wrote:
> 
> 1. We adapt the formatting policy using ClangFormat.
> 
> +1
> 
> I would prefer if formatting changes from GNU indent which can be done 
> separately are done separately.

I don’t quite follow you.


> For Python & Black, I did that together but 1) in multiple PRs and 2) we 
> lacked any formatting, so it was a little different. Things like 
> ReflowComments seem like a good second round. (Sorry, I'm a little confused 
> about your intention with unused .clang-format and what will be in there.) 


My intention is simple. First agree on style and add the .clang-format file to 
source and only after that start the actual formatting work.

I strongly advice to make visual supervision on formatting changes before 
merging. For that reason alone the whole source base should be formatted in 
batches of about 500 files each to be manageable. In total there are ca. 3360 
files. The directories ‘include’ and ‘lib’ may need special attention because 
of the Doxygen comments, all the other will be very easily processed. In all 
this will need some 5-8 PRs.


Directory #files

lib 1199
include  103
db   120
display  109
general   67
imagery  379
misc  13
ps84
raster   774
raster3d 100
temporal   1
utils  2
vector   408
visualization  2

3361

I’d say we should strive to limit the formatting changes of a single file to 
minimum, i.e. to 1 (as in one) time. Therefore any changes like ReflowComments 
should be done in one go. (Also, I’m happy to go through all those file once, 
but not twice.)


> 2. We implement "BreakBeforeBraces" rules according the "Stroustrup" style.
> 
> 
> Related to that, the in-line comments in the PR are modified to have one 
> space after the code while Black, i.e., our Python code, has two.

Well, the two are distinct different languages with different history. Black 
also imposes 88 col line width, not 80. I’d say we keep the ClangFormat 
defaults as long as there is no strong argument against. In the case with 
SpacesBeforeTrailingComments set to 1: do not forget that C-style comments take 
at least 6 characters!  E.g. `/* comment */`. And that is not even a Doxygen 
doc comment.


___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Configure changes in main (8.3.dev)

[Nicklas Larsson via grass-dev]

FYI, from now on, on main branch, after PR #2679 [1] configuring png library 
has changed to:

 --with-libpng=path/libpng-config


The following flags are not usable anymore:

 --with-png-includes=DIRS
 --with-png-libs=DIRS


Best,
Nicklas



[1] https://github.com/OSGeo/grass/pull/2679

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Question on the CDHC library

[Nicklas Larsson via grass-dev]

The deafening response on this issue :-) suggests to me it is safe to remove 
the unused function 'Cdhc_enormp()’ from the CDHC library.

If there are no objections I will shortly merge the PR:
https://github.com/OSGeo/grass/pull/2640






> On 10 Nov 2022, at 15:39, Nicklas Larsson  wrote:
> 
> Hi all!
> 
> Is there someone tuning in to this list that has knowledge on the content and 
> history of the GRASS library CDHC?
> 
> In a recent PR dealing with compiler warnings a strange line of code in 
> Cdhc_enormp() was discussed [1].
> 
> It turned out we could not find any documentation on what this function is 
> supposed to do and --more importantly-- that it was not even used. I 
> therefore put up a PR suggesting to remove that function [2], but I wanted to 
> give it a last chance with this post…
> 
> I also posted a PR [3] for adding the statlib cdh Fortran source code by Paul 
> Johnson (which the cdhc library code was based upon) to the library 
> documentation.
> 
> Best,
> Nicklas
> 
> 
> [1] https://github.com/OSGeo/grass/pull/2164#discussion_r1014211809 
> 
> [2] https://github.com/OSGeo/grass/pull/2640 
> 
> [3] https://github.com/OSGeo/grass/pull/2642 
> 
> 
> 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev