Re: Meson feedback as a user - AX_COMPILER_FLAGS

[Sébastien Wilmet]

On Sun, Jul 02, 2017 at 05:29:21PM +0200, Sébastien Wilmet wrote:
> The same for compiler flags, with the Autotools there is the
> AX_COMPILER_FLAGS macro. With meson it seems that the flags are listed
> in each GNOME module.

I've opened this issue to have the equivalent of AX_COMPILER_FLAGS in
Meson:
https://github.com/mesonbuild/meson/issues/2609

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

Re: Meson feedback as a user

[Tomas Popela]

On Mon, Nov 27, 2017 at 11:09 AM, Emmanuele Bassi  wrote:

> You could also have `generate_vapi` or `build_vapi` as options.
>

Or just vapi. Thank you Emmanuele!
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Meson feedback as a user

[Emmanuele Bassi]

On 27 November 2017 at 09:56, Tomas Popela  wrote:
> On Mon, Nov 27, 2017 at 10:49 AM, Richard Hughes 
> wrote:
>>
>> On 24 November 2017 at 14:49, Emmanuele Bassi  wrote:
>> >  - Drop the "enable" from --enable-foo boolean options; Meson has
>> > boolean values, so -Denable-foo=true would read as redundant, and
>> > -Denable-foo=false would read as contradictory. Use -Dfoo=true or
>> > -Dfoo=false instead
>>
>> I'm guilt of this, I'll fix up my projects, but before I do is there
>> any list of best practices? e.g. should it be
>>
>> * -Dgtk_doc=true, -Dgtkdoc=true or -Ddocs=true?
>> * -Dintrospection=true or -Dgobject_introspection=true?
>> * -Dman=true or -Dman_pages=true
>> * -Dconsolekit=false or -DConsoleKit=false
>
>
> And what about  an option about enabling Vala bindings? In libsoup I use
> -Denable-vala, but if I would like to change it to -Dvala, then:
>
> Option name vala is reserved.
>
> or another logic one -Dvala_bindings:
>
> Option name vala_bindings is reserved.
>
> Any opinion?

You'll have to ask the Meson developers about this.

You could also have `generate_vapi` or `build_vapi` as options.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Meson feedback as a user

[Emmanuele Bassi]

On 27 November 2017 at 09:49, Richard Hughes  wrote:
> On 24 November 2017 at 14:49, Emmanuele Bassi  wrote:
>>  - Drop the "enable" from --enable-foo boolean options; Meson has
>> boolean values, so -Denable-foo=true would read as redundant, and
>> -Denable-foo=false would read as contradictory. Use -Dfoo=true or
>> -Dfoo=false instead
>
> I'm guilt of this, I'll fix up my projects, but before I do is there
> any list of best practices? e.g. should it be

It would be great if Meson modules would also be able to define
options, so we would not need to deal with gtk-doc and
gobject-introspection. Until that happens, though, I kind of trust the
judgement of GNOME maintainers.

> * -Dgtk_doc=true, -Dgtkdoc=true or -Ddocs=true?

It depends if you're gating other kind of documentation, like man
pages, using the same option.

Personally, I prefer `docs` as a catch-all.

> * -Dintrospection=true or -Dgobject_introspection=true?

Up to you. I have a slight preference for `introspection`.

> * -Dman=true or -Dman_pages=true

You can use `man`, or you could gate both API references and man pages
under the same option. In many cases, man pages are generated from the
same DocBook XML format anyway.

> * -Dconsolekit=false or -DConsoleKit=false

That's kind of esoteric; it's up to you, but think of the people that
need to type this out. ;-)

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Meson feedback as a user

[Iñigo Martínez]

Just on my own experience, based on the packages I've ported:

* -Dgtk_doc=true
* -Dintrospection=true
* -Dman=true
* -Dconsolekit=false

There is only a minor quirk with this, which is `vala`, because it's a
reserved option name.

Anyway, a common glossary would be welcome, so that not only the
naming scheme is consistent between the different packages, but also
the names themselves.

Best regards,


2017-11-27 10:49 GMT+01:00 Richard Hughes :
> On 24 November 2017 at 14:49, Emmanuele Bassi  wrote:
>>  - Drop the "enable" from --enable-foo boolean options; Meson has
>> boolean values, so -Denable-foo=true would read as redundant, and
>> -Denable-foo=false would read as contradictory. Use -Dfoo=true or
>> -Dfoo=false instead
>
> I'm guilt of this, I'll fix up my projects, but before I do is there
> any list of best practices? e.g. should it be
>
> * -Dgtk_doc=true, -Dgtkdoc=true or -Ddocs=true?
> * -Dintrospection=true or -Dgobject_introspection=true?
> * -Dman=true or -Dman_pages=true
> * -Dconsolekit=false or -DConsoleKit=false
>
> Thanks,
>
> Richard.
> ___
> 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: Meson feedback as a user

[Tomas Popela]

On Mon, Nov 27, 2017 at 10:49 AM, Richard Hughes 
wrote:

> On 24 November 2017 at 14:49, Emmanuele Bassi  wrote:
> >  - Drop the "enable" from --enable-foo boolean options; Meson has
> > boolean values, so -Denable-foo=true would read as redundant, and
> > -Denable-foo=false would read as contradictory. Use -Dfoo=true or
> > -Dfoo=false instead
>
> I'm guilt of this, I'll fix up my projects, but before I do is there
> any list of best practices? e.g. should it be
>
> * -Dgtk_doc=true, -Dgtkdoc=true or -Ddocs=true?
> * -Dintrospection=true or -Dgobject_introspection=true?
> * -Dman=true or -Dman_pages=true
> * -Dconsolekit=false or -DConsoleKit=false


And what about  an option about enabling Vala bindings? In libsoup I use
-Denable-vala, but if I would like to change it to -Dvala, then:

Option name vala is reserved.

or another logic one -Dvala_bindings:

Option name vala_bindings is reserved.

Any opinion?

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

Re: Meson feedback as a user

[Richard Hughes]

On 24 November 2017 at 14:49, Emmanuele Bassi  wrote:
>  - Drop the "enable" from --enable-foo boolean options; Meson has
> boolean values, so -Denable-foo=true would read as redundant, and
> -Denable-foo=false would read as contradictory. Use -Dfoo=true or
> -Dfoo=false instead

I'm guilt of this, I'll fix up my projects, but before I do is there
any list of best practices? e.g. should it be

* -Dgtk_doc=true, -Dgtkdoc=true or -Ddocs=true?
* -Dintrospection=true or -Dgobject_introspection=true?
* -Dman=true or -Dman_pages=true
* -Dconsolekit=false or -DConsoleKit=false

Thanks,

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

Re: Meson feedback as a user

[Tristan Van Berkom]

On Sat, 2017-11-25 at 03:45 +, philip.chime...@gmail.com wrote:
> Is it possible to add to the guidelines to write your meson file such
> that you check dependencies as soon as possible and fail early?

I think we can do better than that.

Since unlike other build systems, meson is more of a declarative than
procedural thing; I thought meson should be able to report all of the
missing dependencies in one go (instead of the obnoxious trial and
error we are used to).

When I suggested this in #mesonbuild, I was directed to an existing bug
report which already has some merge request, unfortunately I am unable
to easily find the issue number off hand, but it seems there is already
a work in progress for this... the future is bright !

Cheers,
-Tristan

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

Re: Meson feedback as a user

[philip . chimento]

Is it possible to add to the guidelines to write your meson file such that
you check dependencies as soon as possible and fail early? I thought
automatic optional dependencies were a lifesaver back in the days when I
didn't have a current jhbuild tree at all times, configure took 5 minutes
and I'd have to run it over and over again as each missing dependency
failed, so I understand why people started using them in the first place.
The best way to get them to disappear is to make them unnecessary...

Regards,
Philip C.

On Fri, Nov 24, 2017, 07:04 Michael Catanzaro, 
wrote:

> All good guidelines!
>
> On Fri, Nov 24, 2017 at 8:49 AM, Emmanuele Bassi 
> wrote:
> > - Try to avoid automatic feature detection; this makes it harder for
> > distributors and continuous integration systems to identify the
> > dependencies needed to build your project
>
> I would use much stronger wording here. Automagic dependencies (meson's
> auto dependencies) are *evil*, a huge number of GNOME projects used
> them in their Autotools build systems, and believe some projects have
> dutifully ported them over to their new Meson build systems. Please
> pick reasonable true or false defaults for your project, and *fail the
> build* if a dependency for a feature is missing. Make the user
> explicitly disable the feature to proceed without the dependency. It's
> really, really unkind to distributions, Gentoo users, and anyone
> building your software to make features *silently disappear* if they
> don't magically know to have a certain BuildRequires.
>
> There are some *very rare* cases where automagic dependencies actually
> do make sense. For example, WebKitGTK+ will automagically determine to
> build with OpenGL ES support rather than OpenGL support if OpenGL ES is
> available but not OpenGL, because in the end no feature is disabled,
> and if you have one but not the other it's very likely that's the one
> you intend to be used. But if neither one is installed, the build will
> *fail* until you decide what to do: GL support will not just disappear
> unless you explicitly turn it off.
>
> Michael
>
> ___
> 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: Meson feedback as a user

[Michael Catanzaro]

All good guidelines!

On Fri, Nov 24, 2017 at 8:49 AM, Emmanuele Bassi  
wrote:
- Try to avoid automatic feature detection; this makes it harder for 
distributors and continuous integration systems to identify the 
dependencies needed to build your project


I would use much stronger wording here. Automagic dependencies (meson's 
auto dependencies) are *evil*, a huge number of GNOME projects used 
them in their Autotools build systems, and believe some projects have 
dutifully ported them over to their new Meson build systems. Please 
pick reasonable true or false defaults for your project, and *fail the 
build* if a dependency for a feature is missing. Make the user 
explicitly disable the feature to proceed without the dependency. It's 
really, really unkind to distributions, Gentoo users, and anyone 
building your software to make features *silently disappear* if they 
don't magically know to have a certain BuildRequires.


There are some *very rare* cases where automagic dependencies actually 
do make sense. For example, WebKitGTK+ will automagically determine to 
build with OpenGL ES support rather than OpenGL support if OpenGL ES is 
available but not OpenGL, because in the end no feature is disabled, 
and if you have one but not the other it's very likely that's the one 
you intend to be used. But if neither one is installed, the build will 
*fail* until you decide what to do: GL support will not just disappear 
unless you explicitly turn it off.


Michael

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

Re: Meson feedback as a user

[Emmanuele Bassi]

Hi Michael;

On 4 November 2017 at 01:59, Michael Biebl  wrote:
> Hi there
>
> 2017-09-05 19:48 GMT+02:00 Emmanuele Bassi :
>> On 5 September 2017 at 18:40, Michael Biebl  wrote:
>
>>> Has there been some effort to consolidate the names?
>>
>> We're still in the process of migrating projects. The migration was
>> slowed down for the release of GNOME 3.26.
>>
>> I fully expect this to become a goal for the 3.28 development cycle,
>> while we migrate more projects to Meson; I'll make sure to add a
>> sub-page for the porting effort under
>> https://wiki.gnome.org/Initiatives/GnomeGoals/MesonPorting
>
> Afaics there is no such page yet which documents the list of preferred
> build switch names or am I simply not finding it?

A couple of weeks ago I updated the Wiki page on the Meson port[0]
with some of the best practices:

```
If your project has configuration options for the Autotools build make
sure to port them all to the Meson one, following these style
guidelines

 - Drop the "enable" from --enable-foo boolean options; Meson has
boolean values, so -Denable-foo=true would read as redundant, and
-Denable-foo=false would read as contradictory. Use -Dfoo=true or
-Dfoo=false instead
 - Similarly, you should drop "with" from --with-bar options
 - Use a consistent separator character for multi-word options,
preferably the underscore _, like cert_file or cups_print_backend
 - Try to avoid automatic feature detection; this makes it harder for
distributors and continuous integration systems to identify the
dependencies needed to build your project
 - Do not add "enable debug" options to inject pre-processor symbols
into the build, or control the presence of debugging messages; you
should use Meson's own buildtype option
 - Do not add "enable -Werror" options to make warnings fail the
build; you should use Meson's own --werror build option
```

It would be good if maintainers that are in the process of porting to
Meson would follow these guidelines; for projects already ported, it
would be good to file bugs.

Ciao,
 Emmanuele

[0]: https://wiki.gnome.org/Initiatives/GnomeGoals/MesonPorting

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Meson feedback as a user

[Michael Biebl]

Hi there

2017-09-05 19:48 GMT+02:00 Emmanuele Bassi :
> On 5 September 2017 at 18:40, Michael Biebl  wrote:

>> Has there been some effort to consolidate the names?
>
> We're still in the process of migrating projects. The migration was
> slowed down for the release of GNOME 3.26.
>
> I fully expect this to become a goal for the 3.28 development cycle,
> while we migrate more projects to Meson; I'll make sure to add a
> sub-page for the porting effort under
> https://wiki.gnome.org/Initiatives/GnomeGoals/MesonPorting

Afaics there is no such page yet which documents the list of preferred
build switch names or am I simply not finding it?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Meson feedback as a user

[Michael Catanzaro]

On Tue, Sep 5, 2017 at 12:40 PM, Michael Biebl  wrote:

While at it, please consider dropping the autotoolsism and name the
option "docs", i.e. drop the with or enable prefix.


The meson developers suggested this, so I applied it to Epiphany:

https://git.gnome.org/browse/epiphany/commit/?id=d92acde9fe4c406774677f1dc9c399adcfc7150e

We haven't received clear guidance on underscores vs. hyphens, but the 
meson docs used underscores, and so does CMake (which is the more 
relevant comparison because it uses -D syntax for defining options), so 
that seemed good to me.


Note: jhbuild is still passing -Ddisable_gtkdoc=true. Seems no projects 
are actually using that though. :)


Michael

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

Re: Meson feedback as a user

[Emmanuele Bassi]

On 5 September 2017 at 18:40, Michael Biebl  wrote:
> 2017-07-02 16:21 GMT+02:00 Sam Thursfield :
>> On Sun, Jul 2, 2017 at 1:27 PM, Sébastien Wilmet  wrote:
>>> Out of curiosity, let's look at other GNOME-related modules that use
>>> gtk-doc. What is the name of the option that enables gtk-doc?
>>> - pango:enable_docs
>>> - gtk+: enable-documentation
>>> - graphene: enable-gtk-doc
>>> - atk:  enable_docs
>>
>> We should indeed work to make these names consistent across GNOME
>> modules. Having a page on the wiki where we list standard option names
>> for Meson build systems would be a good start.
>
> Has there been some effort to consolidate the names?

We're still in the process of migrating projects. The migration was
slowed down for the release of GNOME 3.26.

I fully expect this to become a goal for the 3.28 development cycle,
while we migrate more projects to Meson; I'll make sure to add a
sub-page for the porting effort under
https://wiki.gnome.org/Initiatives/GnomeGoals/MesonPorting

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Meson feedback as a user

[Michael Biebl]

2017-07-02 16:21 GMT+02:00 Sam Thursfield :
> On Sun, Jul 2, 2017 at 1:27 PM, Sébastien Wilmet  wrote:
>> Out of curiosity, let's look at other GNOME-related modules that use
>> gtk-doc. What is the name of the option that enables gtk-doc?
>> - pango:enable_docs
>> - gtk+: enable-documentation
>> - graphene: enable-gtk-doc
>> - atk:  enable_docs
>
> We should indeed work to make these names consistent across GNOME
> modules. Having a page on the wiki where we list standard option names
> for Meson build systems would be a good start.

Has there been some effort to consolidate the names?
Looking at a few random modules I find
 with_docs, with-docs, docs, enable_docs and enable-docs
to enable the gtk-doc API documentation.
Needless to say that's quite annoying.

While at it, please consider dropping the autotoolsism and name the
option "docs", i.e. drop the with or enable prefix.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Meson feedback as a user

[Sébastien Wilmet]

On Thu, Jul 06, 2017 at 05:41:11PM +0200, Mattias Bengtsson wrote:
> On Sun, 2017-07-02 at 17:39 +0200, Sébastien Wilmet wrote:
> > My main point of my email was that the Meson documentation should be
> > split in two or three IMHO:
> > - Simple user doc, how to build a project that uses meson;
> > - Doc for developers/maintainers that want to use meson as the build
> >   system of their project;
> > - Doc for contributors to Meson itself or developers who want to 
> >   write a macro/function (I don't exactly know how Meson works, but I
> >   suppose it can be extended in some way).
> 
> This sounds like feedback perfect for their bugtracker[0] rather than
> ddl honestly.
> 
> 1: https://github.com/mesonbuild/meson/issues

Done:
https://github.com/mesonbuild/meson/issues/2042

I started this thread on desktop-devel-list because I think some Meson
developers hang around here.

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

Re: Meson feedback as a user

[Mattias Bengtsson]

On Sun, 2017-07-02 at 17:39 +0200, Sébastien Wilmet wrote:
> My main point of my email was that the Meson documentation should be
> split in two or three IMHO:
> - Simple user doc, how to build a project that uses meson;
> - Doc for developers/maintainers that want to use meson as the build
>   system of their project;
> - Doc for contributors to Meson itself or developers who want to 
>   write a macro/function (I don't exactly know how Meson works, but I
>   suppose it can be extended in some way).

This sounds like feedback perfect for their bugtracker[0] rather than
ddl honestly.

1: https://github.com/mesonbuild/meson/issues
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Meson feedback as a user

[Matthias Clasen]

On Sun, Jul 2, 2017 at 11:29 AM, Sébastien Wilmet  wrote:


> To make the names consistent, the best way is to write the name in only
> one place, i.e. in meson itself or a meson function/macro. Not in each
> individual modules.
>
> Like the GTK_DOC_CHECK Autotools macro.
>
> The same for compiler flags, with the Autotools there is the
> AX_COMPILER_FLAGS macro. With meson it seems that the flags are listed
> in each GNOME module.
>
>
Consistent option names are good.

But please, please, lets not reproduce all the misery of autotools where
the first thing that breaks when you build your project on another platform
is the portability layer because some 3rd party macro is missing...
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Meson feedback as a user

[Emmanuele Bassi]

On 2 July 2017 at 17:02, Philip Withnall  wrote:
> On Sun, 2017-07-02 at 15:37 +, Emmanuele Bassi wrote:
>>
>> On Sun, 2 Jul 2017 at 16:29, Sébastien Wilmet 
>> wrote:

>> There is a subset of warnings you want for C - and those should go in
>> Meson's warning_level option. Differently projects have very
>> different requirements: there is no "one size fits all" or alias for
>> an ever changing set of warnings - otherwise we'd all run with
>> -Wextra and -Werror.
>
> The statements
> “There is a subset of warnings you want for C”
> and
> “there is no "one size fits all" or alias for an ever changing set of
> warnings”
> seem to be incompatible.

I was on my phone, so there's a missing "small" from "there is a subset".

The minimal subset of warnings is basically -Wall, considering that
GCC tends to promote new warnings in there across versions, as well as
adding them to -Wextra. Anything else is negotiable, and needs to be
validated against the current project code base on different
platforms, compilers, and versions of the compiler, before toggling
it.

If you want to have a blanket option, use Meson's 'warning_level=2' or
'warning_level=3', and then be prepared to battle against compiler
changes, as well as dependency changes.

> AX_COMPILER_FLAGS is meant to provide that
> ‘subset of warnings you want for C’. If you think the set of warnings
> it enables is incorrect, please bring that up with me (in a different
> ML thread, I don’t want to take this one off topic).

I don't think we are ever going to agree on the usefulness of
AX_COMPILER_FLAGS, so I'd rather not waste anybody's time.

My point is:

 - use 'warning_level' in Meson to enable different compiler warnings
 - if you want to add compiler flags to Meson, submit a patch for the
existing 'warning_level' option so that the options are per-platform,
per-compiler, and per-language
 - considering the amount of compiler flags that are per-project, and
the maintenance burden they impose on maintainers, newcomer
developers, and CI, I'd rather you figured out the list of warnings
*you* need and, especially, that *you* are willing to commit to,
instead of a blanket option that requires disabling for everyone while
you figure out how to fix a code base

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Meson feedback as a user

[Sébastien Wilmet]

On Sun, Jul 02, 2017 at 04:10:45PM +0200, Iñigo Martínez wrote:
> You can also use mesonconf, which will show you all the available options,
> even those present in the meson_options.txt file  along with their possible
> values.
> 
> To activate those options, you can use either meson or mesonconf:
> 
> - meson -Denable_docs=true builddir
> - mesonconf -Denable_docs=true builddir
> 
> Meson site has some more information regarding build options[0].
> 
> I agree with you that it would be nice to use the same name for common
> options, like gtk docs, just for consistency.
> 
> Best regards,
> 
> [0] http://mesonbuild.com/Build-options.html#build-options

My main point of my email was that the Meson documentation should be
split in two or three IMHO:
- Simple user doc, how to build a project that uses meson;
- Doc for developers/maintainers that want to use meson as the build
  system of their project;
- Doc for contributors to Meson itself or developers who want to write a
  macro/function (I don't exactly know how Meson works, but I suppose it
  can be extended in some way).

Indeed the documentation that I was looking for (and that was missing in
the manpage or meson --help) is available at:
http://mesonbuild.com/Build-options.html#build-options
but that's the doc for developers/maintainers.

(btw I've now added this to my jhbuildrc:

module_mesonargs['graphene'] = '-Denable-gtk-doc=true'

For Pango the build fails when enabling the docs, I didn't investigate
why).

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

Re: Meson feedback as a user

[Emmanuele Bassi]

On Sun, 2 Jul 2017 at 16:29, Sébastien Wilmet  wrote:

> On Sun, Jul 02, 2017 at 03:21:51PM +0100, Sam Thursfield wrote:
> > On Sun, Jul 2, 2017 at 1:27 PM, Sébastien Wilmet 
> wrote:
> > > Out of curiosity, let's look at other GNOME-related modules that use
> > > gtk-doc. What is the name of the option that enables gtk-doc?
> > > - pango:enable_docs
> > > - gtk+: enable-documentation
> > > - graphene: enable-gtk-doc
> > > - atk:  enable_docs
> >
> > We should indeed work to make these names consistent across GNOME
> > modules. Having a page on the wiki where we list standard option names
> > for Meson build systems would be a good start.
>
> To make the names consistent, the best way is to write the name in only
> one place, i.e. in meson itself or a meson function/macro. Not in each
> individual modules.
>
> Like the GTK_DOC_CHECK Autotools macro.


Currently, Meson modules cannot define options, but it's something that
would be useful, and AFAIR there's an issue opened about it.

>
> The same for compiler flags, with the Autotools there is the
> AX_COMPILER_FLAGS macro. With meson it seems that the flags are listed
> in each GNOME module.


On the other hand, having a common set of warnings is broken and it
demonstrably does not work, as I've found after having to fix the various
modules that were moved to AX_COMPILER_FLAGS.

There is a subset of warnings you want for C - and those should go in
Meson's warning_level option. Differently projects have very different
requirements: there is no "one size fits all" or alias for an ever changing
set of warnings - otherwise we'd all run with -Wextra and -Werror.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Meson feedback as a user

[Sébastien Wilmet]

On Sun, Jul 02, 2017 at 03:21:51PM +0100, Sam Thursfield wrote:
> On Sun, Jul 2, 2017 at 1:27 PM, Sébastien Wilmet  wrote:
> > Out of curiosity, let's look at other GNOME-related modules that use
> > gtk-doc. What is the name of the option that enables gtk-doc?
> > - pango:enable_docs
> > - gtk+: enable-documentation
> > - graphene: enable-gtk-doc
> > - atk:  enable_docs
> 
> We should indeed work to make these names consistent across GNOME
> modules. Having a page on the wiki where we list standard option names
> for Meson build systems would be a good start.

To make the names consistent, the best way is to write the name in only
one place, i.e. in meson itself or a meson function/macro. Not in each
individual modules.

Like the GTK_DOC_CHECK Autotools macro.

The same for compiler flags, with the Autotools there is the
AX_COMPILER_FLAGS macro. With meson it seems that the flags are listed
in each GNOME module.

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

Re: Meson feedback as a user

[Michael Catanzaro]

On Sun, Jul 2, 2017 at 7:27 AM, Sébastien Wilmet  
wrote:

Out of curiosity, let's look at other GNOME-related modules that use
gtk-doc. What is the name of the option that enables gtk-doc?
- pango:enable_docs
- gtk+: enable-documentation
- graphene: enable-gtk-doc
- atk:  enable_docs


JHBuild passes -Ddisable_gtkdoc=true to all meson modules by default. 
Looks like that will work for zero of the above modules. :)


I wonder, is it smart enough to know that an option named disable_foo 
is the inverse of an option named enable_foo? What about the hyphenated 
form, enable- and disable-? I was expecting all projects would use 
underscores for meson options, so I'm surprised to see hyphens at 
all


Michael

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

Re: Meson feedback as a user

[Sam Thursfield]

On Sun, Jul 2, 2017 at 1:27 PM, Sébastien Wilmet  wrote:
> Out of curiosity, let's look at other GNOME-related modules that use
> gtk-doc. What is the name of the option that enables gtk-doc?
> - pango:enable_docs
> - gtk+: enable-documentation
> - graphene: enable-gtk-doc
> - atk:  enable_docs

We should indeed work to make these names consistent across GNOME
modules. Having a page on the wiki where we list standard option names
for Meson build systems would be a good start.

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

Re: Meson feedback as a user

[Iñigo Martínez]

You can also use mesonconf, which will show you all the available options,
even those present in the meson_options.txt file  along with their possible
values.

To activate those options, you can use either meson or mesonconf:

- meson -Denable_docs=true builddir
- mesonconf -Denable_docs=true builddir

Meson site has some more information regarding build options[0].

I agree with you that it would be nice to use the same name for common
options, like gtk docs, just for consistency.

Best regards,

[0] http://mesonbuild.com/Build-options.html#build-options

El 2/7/2017 2:27 p. m., "Sébastien Wilmet"  escribió:

> Hi,
>
> I don't want to learn Meson yet as a maintainer. Just as a user to build
> some GNOME modules that now require Meson.
>
> It seems that the Meson docs are now more focused for maintainers, not
> users. What was great with the Autotools is that it was easy to use, as
> a user: INSTALL file with all the user documentation,
> ./configure --help, etc.
>
> So let's take a simple use-case: I want to build in Jhbuild the API docs
> of Pango and other GNOME/GTK+ libraries.
>
> I see that Jhbuild doesn't build the API docs of Pango by default. How
> do I enable it? With the Autotools I had something like this in my
> jhbuildrc:
> module_autogenargs['pango'] = '--enable-gtk-doc'
>
> $ cd ~/gnome/pango/
> $ man meson
> OK so I need to do:
> $ meson --help
> Nothing resembling --enable-gtk-doc. It seems that meson --help outputs
> the same text for all projects.
>
> Let's look at the Meson web site:
> http://mesonbuild.com/Quick-guide.html doesn't help me.
> http://mesonbuild.com/Tutorial.html dives directly for maintainers, not
> users.
>
> $ ls
> Oh I see that there is a meson_options.txt.
> $ cat meson_options.txt
> option('enable_docs',
>description: 'Build API reference for Pango using GTK-Doc',
>type: 'boolean',
>value: false)
> OK that's what I was looking for, how do I enable it?
>
> $ meson --help
> -D PROJECTOPTIONS Set project options.
>
> Probably that. Do I need to pass "-D enable_docs" or
> "-D enable_docs=true" or "-D enable_docs='true'" or anything else? Do I
> proceed by trials and errors until I find something that works?
>
> Out of curiosity, let's look at other GNOME-related modules that use
> gtk-doc. What is the name of the option that enables gtk-doc?
> - pango:enable_docs
> - gtk+: enable-documentation
> - graphene: enable-gtk-doc
> - atk:  enable_docs
>
> With the Autotools with the GTK_DOC_CHECK macro, it was --enable-gtk-doc
> everywhere at least.
>
> 
>
> So, that's it, I think Meson is still a bit young. I'll try another day.
> Or I could do the same as everybody, asking on IRC, or reading the docs
> for maintainers.
>
> --
> 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

Meson feedback as a user

[Sébastien Wilmet]

Hi,

I don't want to learn Meson yet as a maintainer. Just as a user to build
some GNOME modules that now require Meson.

It seems that the Meson docs are now more focused for maintainers, not
users. What was great with the Autotools is that it was easy to use, as
a user: INSTALL file with all the user documentation,
./configure --help, etc.

So let's take a simple use-case: I want to build in Jhbuild the API docs
of Pango and other GNOME/GTK+ libraries.

I see that Jhbuild doesn't build the API docs of Pango by default. How
do I enable it? With the Autotools I had something like this in my
jhbuildrc:
module_autogenargs['pango'] = '--enable-gtk-doc'

$ cd ~/gnome/pango/
$ man meson
OK so I need to do:
$ meson --help
Nothing resembling --enable-gtk-doc. It seems that meson --help outputs
the same text for all projects.

Let's look at the Meson web site:
http://mesonbuild.com/Quick-guide.html doesn't help me.
http://mesonbuild.com/Tutorial.html dives directly for maintainers, not
users.

$ ls
Oh I see that there is a meson_options.txt.
$ cat meson_options.txt
option('enable_docs',
   description: 'Build API reference for Pango using GTK-Doc',
   type: 'boolean',
   value: false)
OK that's what I was looking for, how do I enable it?

$ meson --help
-D PROJECTOPTIONS Set project options.

Probably that. Do I need to pass "-D enable_docs" or
"-D enable_docs=true" or "-D enable_docs='true'" or anything else? Do I
proceed by trials and errors until I find something that works?

Out of curiosity, let's look at other GNOME-related modules that use
gtk-doc. What is the name of the option that enables gtk-doc?
- pango:enable_docs
- gtk+: enable-documentation
- graphene: enable-gtk-doc
- atk:  enable_docs

With the Autotools with the GTK_DOC_CHECK macro, it was --enable-gtk-doc
everywhere at least.



So, that's it, I think Meson is still a bit young. I'll try another day.
Or I could do the same as everybody, asking on IRC, or reading the docs
for maintainers.

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