Re: meson ground rules!

[Patrick Griffis via desktop-devel-list]

On Wed, 2016-11-23 at 14:35 +0530, Nirbheek Chauhan wrote:
> From what I can understand, this is done specifically because distros
> such as Ubuntu and F23 do not ship a new-enough version of Meson
> quickly? Please correct me if I'm wrong.

In particular, Ubuntu, yes. Fedora ships meson updates aggressively so
it's not really a problem here.

> If so, what's stopping us from adding a `meson` module to jhbuild
> instead of always using the system-provided package? Meson is pure
> Python so the module should be trivial to maintain.

It's certainly possible, but someone has to make it happen. Currently
meson and ninja are both "virtual sysdeps" which means the dependency
is added automatically for all meson modules, and there's no support
for doing that with non-sysdep modules. It could be done by removing
the virtual sysdep and manually adding a dependency from every meson
module to a meson module in core-deps, but it'd be better to have it
built-in like the dependencies for all other module types. Either way,
we could indeed drop the version requirement if you were to make this
happen.

> Meson has a very swift pace of development, and a one-year delay in
> the version that can be used is a bit harsh, don't you think? For
> instance, as existing modules are having experimental ports to Meson,
> we're finding that enhancements are necessary which necessitates the
> use of a new release. If modules have to continue to default to
> Autotools because of that, the Meson port won't get wider testing and
> we'll continue to be stuck with Autotools.
>
> I'd be happy to maintain the meson module in jhbuild if that's
> necessary.

Keep in mind that the version requirement only affects modules that
remove the Autotools build system.

Thanks,

Michael
Meson is very easy to install and distribute though. For a developer its a 
`pip3 install --user meson` away. For distributing it you can make a Python 
zipapp so it is a single file you store in the tarball (smaller than autotools 
output ever was). 0.36.0 is a very major release IMO, I put a lot of work into 
it getting gnome-builder and sysprof building and most gnome apps would 
certainly want to target that.___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Script to format the functions in a C header?

[Christian Hergert]

On 11/23/2016 05:03 AM, Sébastien Wilmet wrote:

Also, in the GNOME convention there is something that I don't like and
that I would prefer not to do: aligning all the parameter names on the
same column (the third column). I prefer aligning the parameter names
for each function separately, IMHO it's more readable. Because
otherwise, for some functions, there can be a big empty space between
parameter types and their names, which doesn't help readability (caused
by a long type in another function).


While I certainly respect that others would want something different 
than me, this is something I'm quite fond of in our style. I'd be happy 
to add it.


-- Christian
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Script to format the functions in a C header?

[Christian Hergert]

On 11/23/2016 05:38 AM, Leslie S Satenstein via desktop-devel-list wrote:

Can someone tell me what is wrong with using the *indent* program?


indent does not fully support our style, nor does it align groups of 
functions to add space so functions are aligned as a group.

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: meson ground rules!

[Michael Catanzaro]

On Wed, 2016-11-23 at 14:35 +0530, Nirbheek Chauhan wrote:
> From what I can understand, this is done specifically because distros
> such as Ubuntu and F23 do not ship a new-enough version of Meson
> quickly? Please correct me if I'm wrong.

In particular, Ubuntu, yes. Fedora ships meson updates aggressively so
it's not really a problem here.

> If so, what's stopping us from adding a `meson` module to jhbuild
> instead of always using the system-provided package? Meson is pure
> Python so the module should be trivial to maintain.

It's certainly possible, but someone has to make it happen. Currently
meson and ninja are both "virtual sysdeps" which means the dependency
is added automatically for all meson modules, and there's no support
for doing that with non-sysdep modules. It could be done by removing
the virtual sysdep and manually adding a dependency from every meson
module to a meson module in core-deps, but it'd be better to have it
built-in like the dependencies for all other module types. Either way,
we could indeed drop the version requirement if you were to make this
happen.

> Meson has a very swift pace of development, and a one-year delay in
> the version that can be used is a bit harsh, don't you think? For
> instance, as existing modules are having experimental ports to Meson,
> we're finding that enhancements are necessary which necessitates the
> use of a new release. If modules have to continue to default to
> Autotools because of that, the Meson port won't get wider testing and
> we'll continue to be stuck with Autotools.
> 
> I'd be happy to maintain the meson module in jhbuild if that's
> necessary.

Keep in mind that the version requirement only affects modules that
remove the Autotools build system.

Thanks,

Michael
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Script to format the functions in a C header?

[Leslie S Satenstein via desktop-devel-list]

Can someone tell me what is wrong with using the indent program?man indent for 
detailsSummary The indent program can be used to make code easier to read.  It 
can also convert from one style of writing C to another.

   indent understands a substantial amount about the syntax of C, but it 
also attempts to cope with  incomplete  and  misformed
   syntax.

   In version 1.2 and more recent versions, the GNU style of indenting is 
the default.




 Regards 
 Leslie
 Leslie Satenstein
Montréal Québec, Canada



  From: Sébastien Wilmet 
 To: desktop-devel-list@gnome.org 
 Sent: Wednesday, November 23, 2016 8:03 AM
 Subject: Re: Script to format the functions in a C header?
   
On Tue, Nov 22, 2016 at 07:03:02PM +0100, Daiki Ueno wrote:
> For what it's worth, I wrote such elisp some time ago:
> http://elpa.gnu.org/packages/gnome-c-style.html

Cool, added to:
https://wiki.gnome.org/Newcomers/Tools-C-language

> If anyone is trying to implement the feature somewhere, I would suggest
> to provide two separate scripts or commands to do the job: (1) guess the
> alignment rule somehow, e.g. from the existing C code, and (2) do the
> actual formatting.  That would be helpful to avoid unnecessary
> formatting changes when creating a patch for existing projects.

Why two separate scripts? A single script can have two passes.

I think I'll write a new script like I did for lineup-parameters, so
that it can be integrated in Vim or Emacs or other text editors (it just
reads stdin and write to stdout, or optionally takes file arguments).

For the script, the first pass - to determine the columns where to do
the alignment - could have two modes: "re-align everything" and "minimal
perturbation". For the minimal perturbation, it would look which columns
are used the most, and fix the functions that are not aligned to those
columns.

Also, in the GNOME convention there is something that I don't like and
that I would prefer not to do: aligning all the parameter names on the
same column (the third column). I prefer aligning the parameter names
for each function separately, IMHO it's more readable. Because
otherwise, for some functions, there can be a big empty space between
parameter types and their names, which doesn't help readability (caused
by a long type in another function).

--
Sébastien
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

   ___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Script to format the functions in a C header?

[Sébastien Wilmet]

On Tue, Nov 22, 2016 at 07:03:02PM +0100, Daiki Ueno wrote:
> For what it's worth, I wrote such elisp some time ago:
> http://elpa.gnu.org/packages/gnome-c-style.html

Cool, added to:
https://wiki.gnome.org/Newcomers/Tools-C-language

> If anyone is trying to implement the feature somewhere, I would suggest
> to provide two separate scripts or commands to do the job: (1) guess the
> alignment rule somehow, e.g. from the existing C code, and (2) do the
> actual formatting.  That would be helpful to avoid unnecessary
> formatting changes when creating a patch for existing projects.

Why two separate scripts? A single script can have two passes.

I think I'll write a new script like I did for lineup-parameters, so
that it can be integrated in Vim or Emacs or other text editors (it just
reads stdin and write to stdout, or optionally takes file arguments).

For the script, the first pass - to determine the columns where to do
the alignment - could have two modes: "re-align everything" and "minimal
perturbation". For the minimal perturbation, it would look which columns
are used the most, and fix the functions that are not aligned to those
columns.

Also, in the GNOME convention there is something that I don't like and
that I would prefer not to do: aligning all the parameter names on the
same column (the third column). I prefer aligning the parameter names
for each function separately, IMHO it's more readable. Because
otherwise, for some functions, there can be a big empty space between
parameter types and their names, which doesn't help readability (caused
by a long type in another function).

--
Sébastien
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list