Meson: Recommend a standard coding style for meson.build files

[swilmet]

It seems that there is no recommended standard for the coding style of meson.build files.

So in some projects the indentation is with two spaces, in other projects it's with tabs or four spaces, etc etc.

I think it's useful to have the same coding style in all projects, it makes contributing easier, it is also easier to copy/paste a snippet of code between projects.

Like the PEP 8 for Python:
https://www.python.org/dev/peps/pep-0008/

[nirbheek]

See also: https://github.com/mesonbuild/meson/issues/2687

[jibsen]

I think to some degree the unit tests serve as an example of the style the authors use.

It seems to be roughly 2 space indents, and breaking function arguments like many CMake scripts do; unless there is only positional and/or one keyword argument, have one keyword argument per line. For instance:

~Meson
mytarget = custom_target('bindat',
output : 'data.dat',
input : 'data_source.txt',
capture : true,
command : [python3, comp, '@INPUT@'],
install : true,
install_dir : 'subdir'
)
~

[swilmet]

OK, thanks for the comment. I personally prefer tabs for the indentation, read for example the rationale for the Linux coding style:

1) Indentation
--------------

Tabs are 8 characters, and thus indentations are also 8 characters.
There are heretic movements that try to make indentations 4 (or even 2!)
characters deep, and that is akin to trying to define the value of PI to
be 3.

Rationale: The whole idea behind indentation is to clearly define where
a block of control starts and ends.  Especially when you've been looking
at your screen for 20 straight hours, you'll find it a lot easier to see
how the indentation works if you have large indentations.

Now, some people will claim that having 8-character indentations makes
the code move too far to the right, and makes it hard to read on a
80-character terminal screen.  The answer to that is that if you need
more than 3 levels of indentation, you're screwed anyway, and should fix
your program.

In short, 8-char indents make things easier to read, and have the added
benefit of warning you when you're nesting your functions too deep.
Heed that warning.

Another thing that I prefer is to align parameters on the opening parenthesis (this is easily done with some text editors):

executable(meson.project_name(),
       sources,
       dependencies : GNOTE_DEPS,
       include_directories : CONFIG_H_INCLUDE_DIR,
       install : true)

But at the end of the day, it is just a matter of preferences, the most important is to have a convention and stick to it for consistency. But without good tools, it can be difficult to change the coding style after the fact, so it's better to choose the convention wisely at the beginning.

Another coding style that could make sense for Meson is to follow as closely PEP 8 for Python. This would have the advantage that a lot of developers are already familiar with it.

[jpakkane]

https://github.com/mesonbuild/meson/blob/master/contributing.txt

[swilmet]

https://github.com/mesonbuild/meson/blob/master/contributing.txt

This file is for contributing to Meson itself. I've opened this issue to have a recommended standard for all projects that would like to use Meson as its build system.

[jpakkane]

Yes, but the statement on tabs is unambiguously clear on that document.

No tabs. Ever. End of discussion.

[jon-turney]

Added in 541eca8 (#2864)

[swilmet]

The sections "Global arguments" and "Cross compilation arguments" would better fit in a page named best-practices, it is not really related to the coding style, in my opinion. (but it's a good thing to document it).

For the coding style, a lot of aspects are missing: number of spaces for one indentation level, how to format a function call with a lot of parameters, whether to have a space before/after some "punctuation", etc.

But it's a good start ;-)