[CMake] AStyle or similar code beautifier

[Alan W. Irwin]

On 2014-01-31 14:24+0100 Eric Noulard wrote:

> Would you mind sharing the script you used with us?

Although that question was directed to someone else, you might be
interested in scripts/style_source.sh within the PLplot source code.

There are options to show diffs (or not) and apply the changes shown
by those diffs or not.  There is also some sed processing used so that
uncrustify can style *.i files (Swig configuration files). There is an
addition a further (python) script called by scripts/style_source.sh
that enforces the C++ ("//") style of commenting on C code (which
we prefer).

The scripts/style_source.sh script and the sed and python scripts it
uses (in addition to uncrustify) are now reliable enough that I
normally just use the --apply option.

Returning back to the original topic, if someone did decide to
implement full-blown CMake support for code styling, then one obvious
possibility is to use properties (specified for any of directory
source or target) to control styling.

Here are my thoughts on the properties required based on
my experience with the above script.

You would need support for multiple STYLE_COMMAND properties (similar
to execute_process COMMAND's) to identify the series of commands that
are used (typically in a pipeline which is why I mentioned
excecute_process) for styling a file.

You would need properties to support what to do with the style
checker results, e.g., warn or error out if style does not conform,
show diffs, or apply.

CMake support for Swig support would likely have to be changed to
allow styling properties to apply to the *.i files.

In my view it would also be essential to have some overall CMake
variable (which defaults to OFF) concerning whether to use the styling
properties that are specified by the build system.  Most users won't
have the code styling tools (e.g., a specific version of uncrustify
like we use in our case) installed, and even project developers would
not want to check style every time they did a build since that would
noticeably add to build times.  Of course, this is just a convenience
variable, but in its absence each project that uses styling tools
would have to implement conditional CMake code at each place where
style options were used. So I classify this convenience option as
essential.

One advantage of integrating styling support into CMake in the way I
have outlined is there would be just one tool where source code needs
to be identified (i.e., CMake) rather than two (i.e., CMake and some
external script).  Even though finding source code is pretty
straightforward with a shell script that uses file globbing, I still
feel that advantage of a CMake implementation is worth having so I
would likely abandon my script and move to using CMake for styling if
support for such styling includes the capabilities I have mentioned
above.  And obviously such an implementation of CMake support for code
styling would appeal even more to those interesting in styling their
code but who have not yet written a script to do that.

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
__________________________