Created attachment 354947 [details] [review]
Port to meson build system

Created attachment 355024 [details] [review]
Port to meson build system

I'm sorry as I missed to convert tabs to spaces. The patch is fixed now.

Comment on attachment 354946 [details] [review]
Changed box drawing script to read input file

+done < $1

That should be "$1", just to be totally safe.

Assuming that works, ok to commit with that change.

Comment on attachment 354946 [details] [review]
Changed box drawing script to read input file

Shorten the summary line a bit, maybe "build: Use input file as parameter" or so.

Comment on attachment 355024 [details] [review]
Port to meson build system

Please get someone interested in meson to review this.

I'm not ready to switch to meson, so this will have to be kept in parallel until then, and someone needs to keep it uptodate with any changes in the autotools build. If someone commits to doing that, I'd be ok with having this meson build in vte git, with the default still being autotools.

Created attachment 355969 [details] [review]
Use input file as parameter

Use "$1" instead of $1 and changed the commit message.

Created attachment 355970 [details] [review]
Port to meson build system

An update to the meson patch. It improves readibility when checking header/functions/symbols and fixes some "misc applications" that weren't using language arguments properly.

(In reply to Christian Persch from comment #5)
> Comment on attachment 355024 [details] [review] [review]
> Port to meson build system
> 
> Please get someone interested in meson to review this.
> 
> I'm not ready to switch to meson, so this will have to be kept in parallel
> until then, and someone needs to keep it uptodate with any changes in the
> autotools build. If someone commits to doing that, I'd be ok with having
> this meson build in vte git, with the default still being autotools.

I would very much appreciate if someone reviews it. Despite my best efforts, I make mistakes, and another person may spot them. However, I regret to say that I don't know anyone close to me that could review it.

I am also sorry to say that I cannot commit myself to update neither autotools nor meson. Nonetheless, I have been involved in different meson ports[0][1][2][3][4][5][6][7][8][9][10], and I've been trying to take care of the work I've done so far[1][2][10][11][12][13][14].

[0] https://bugzilla.gnome.org/show_bug.cgi?id=781908
[1] https://bugzilla.gnome.org/show_bug.cgi?id=782707
[2] https://bugzilla.gnome.org/show_bug.cgi?id=782843
[3] https://bugzilla.gnome.org/show_bug.cgi?id=782994
[4] https://bugzilla.gnome.org/show_bug.cgi?id=783205
[5] https://bugzilla.gnome.org/show_bug.cgi?id=783819
[6] https://bugzilla.gnome.org/show_bug.cgi?id=784354
[7] https://bugzilla.gnome.org/show_bug.cgi?id=784910
[8] https://bugzilla.gnome.org/show_bug.cgi?id=784922
[9] https://bugzilla.gnome.org/show_bug.cgi?id=784975
[10] https://bugzilla.gnome.org/show_bug.cgi?id=783589
[11] https://bugzilla.gnome.org/show_bug.cgi?id=784179
[12] https://bugzilla.gnome.org/show_bug.cgi?id=783735
[13] https://bugzilla.gnome.org/show_bug.cgi?id=784097
[14] https://bugzilla.gnome.org/show_bug.cgi?id=784524
[15] https://bugzilla.gnome.org/attachment.cgi?id=355970

I'm getting back to every meson port that still have not removed autotools, to add meson build files as "extra files", so they are also distributed.

Those ports also include 'vte' and 'gnome-terminal', though I'm not sure if these are going anywhere. I have ended doing the same work for these: review the meson build port to improve it, update also autotools files to update "EXTRA_DIST", and finally create a patch to remove autotools as build system, because some applications are doing so. Hence, you can find here the updated patches.

Created attachment 357015 [details] [review]
Port to meson build system

Updated meson build port patch. The important changes are as follows:

- autotools files have modified to include meson files as extra files.
- Bsymbolic flag was also added only if it was supported by both C and C++ compilers. Now they are independent.
- Test and utility programs have been grouped, so just in case more are created, they should be easier to be added.

Created attachment 357016 [details] [review]
Remove autotools

Some applications are removing autotools to avoid the burden of maintaining two different build system. Just in case this option is considered, this patch removes autotools

Iñigo, thanks for your work!

I'm new to the meson/ninja build system, this is the first time I've tried it. I hate autoconf, I dislike the non-reproducible tarballs that take files from my computer, so I'm really looking forward to a better, modern replacement.

---

> [Christian] I'm not ready to switch to meson

Are you ready now, or any ETA? :)

> so this will have to be kept in parallel until then

I believe keeping and testing the two in sync is a terrible pain for us. I vote for a sudden switch. Maybe at the very beginning of the next devel cycle?

---

Generic meson/ninja experience:

I'm using these commands:
[vte] meson --prefix=/usr --libdir=/usr/lib/x86_64-linux-gnu -Denable-glade-catalogue=false -Denable-gtk-doc=true BUILD
[g-t] meson --prefix=/usr --libexecdir=/usr/lib/gnome-terminal -Denable-search-provider=false BUILD

enable-stuff has to be looked up from meson_options.txt (or is there a meson --something flag to show them?) and the exact spelling used (e.g. no "disable" instead of "enable").

"=true" or "=false" should also be spelled out. Omitting the "=" sign results in a crash that Apport wants me to report to Ubuntu – meson should handle faulty user input much more gracefully.

./configure has nice auto-completion on TAB (mind you, ./autogen.sh doesn't, obviously), I could just --disable-[TAB] to see how exactly that optional feature I don't want to have is called. I hope bash-completion will catch up with meson, too.

DESTDIR becomes an env variable instead of a parameter, that is, "make DESTDIR=/tmp/x install" => "DESTDIR=/tmp/x ninja install"

---

Feedback on the VTE and gnome-terminal meson patches:

They basically work like a charm, and indeed significantly faster than autotools, cool!

VTE: -Denable-gtk-doc=true doesn't work for me, I don't get html files generated.

VTE: "make check" runs 7 tests (as of the time you forked), "ninja test" only runs 1 of them.

VTE: If I do an autotools build and then check out the meson branch to do a meson one, it sometimes fails with various error messages (either vte_sequence_handler_whatever not being declared, or no DEFAULT under WriteFlags in the vala vteapp – which is now removed anyway). Perhaps some generated files have priority from the source dir rather than the build dir? Anyway, really not a problem, just thought I'd make a note. One shouldn't switch back and forth between the two build systems in the same source tree.

The patches are obviously somewhat out of date, it'd be a good warmup task for us to update them.

Thank you very much Egmont for testing this. I would say that this meson port needs an update. It uses meson's 0.41 version, and there is 0.48 now and 0.49 is in progress, meson porting guidelines[0] has also been improved (for example, options should not use any `enable|disable` prefix), and my meson's coding conventions has also greatly improved. testing is also a must, so any mistakes or quirks are fixed in time.

I can return to work on the meson port, updating and testing everything that is necessary, if there is real interest. I leave the decision in your hands, Christian and Egmont.

Me myself I have created a fork in GNOME's GitLab[1] and I can start working there. (However, there doesn't seem to be support for pushing MR from forks.)

[0] https://wiki.gnome.org/Initiatives/GnomeGoals/MesonPorting
[1] https://gitlab.gnome.org/inigomartinez/vte

> there is 0.48 now and 0.49 is in progress

Let's make sure not to require any newer than Christian or I have (which probably means 0.47 now).

> for example, options should not use any `enable|disable` prefix

This is one of the things I was going to ask :)

Some other new comments:

Not all the configure options are the same by default. E.g. debugging is enabled (I see there's a section how it should be reworked anyway).

Static libraries (.a and .la) aren't generated now, and I couldn't quickly find a corresponding option – this is probably the main reason for the build itself (make vs. ninja) being significantly faster.

We'd indeed need to thoroughly compare the installed files, there were some differences around vapi files and filenames.

html docs are generated during the "ninja install" phase, that's not the right place.

(In reply to Egmont Koblinger from comment #12)
> I'm new to the meson/ninja build system, this is the first time I've tried
> it. I hate autoconf, I dislike the non-reproducible tarballs that take files
> from my computer, so I'm really looking forward to a better, modern
> replacement.

We could do git-export only tarballs (or git-tag only, no-tarball releases) with autotools already.

> > [Christian] I'm not ready to switch to meson
> 
> Are you ready now, or any ETA? :)

Switch no, but we can add it in parallel.

> Generic meson/ninja experience:

I'd like to have a generated Makefile in builddir that translates a simple "make" / "make install" into the required meson commands.
 
(In reply to Egmont Koblinger from comment #14)
> > there is 0.48 now and 0.49 is in progress
> 
> Let's make sure not to require any newer than Christian or I have (which
> probably means 0.47 now).

I have 0.48.1 on fedora 29.

I have only looked briefly at the actual patch, but here are a few things:

* Don't add anything meson to Makefile.am/configure.ac. They should be entirely separate, and we shouldn't dist the meson files on an autotools 'make dist'.

* The list of compiler warnings needs to be updated from configure.ac, and they need to be always enabled when found, not just on 'vte_debug'.

* Should compare config.h between autotools and meson and see if there's nosome unexpected differences.

* Should compare the installed files from an autotools vs. a meson build, and see if there's some unexpected differences (diffoscope, ignoring binary differences probably).

(In reply to Christian Persch from comment #15)

> We could do git-export only tarballs (or git-tag only, no-tarball releases)
> with autotools already.

Are there any other official GNOME apps doing any of these? I wouldn't want to be the first one to switch.

> Switch no, but we can add it in parallel.

We have different preferences for the migration process, then :)

> I have 0.48.1 on fedora 29.

I'm the bottleneck here, 0.47.2 on Ubuntu 18.10.

> * Don't add anything meson to Makefile.am/configure.ac. They should be
> entirely separate, and we shouldn't dist the meson files on an autotools
> 'make dist'.

This way only autotools is usable from the tarball, not meson. Which means that we effectively communicate autotools as the default/preferred variant, and meson as a technological preview for git users only. Unless we switch to neutral tarballs (git-export) or no tarballs at all.

If, by whatever means, we encourage the use of one build system over the other, I'm probably going to use whichever we encourage. E.g. if we keep generating tarballs as we do now, and they don't include meson, I'll keep using autotools. This is because I'd like to make sure that we keep testing what we deliver, including its build phase; this is more important for me than my personal convenience or the advantages/disadvantages of each.

If we claim that the two build systems are equally supported then... them I'm not sure, probably I'm going to ask which one you use and I'd use the other one, so that both get tested.

I honestly don't see the point in maintaining the two in parallel, I just see it as an additional burden. I really wouldn't want to burn engineering resources on this in the long run. If we do it for one or two cycles with the firm goal of retiring autotools then I'm fine with this compromise.

(In reply to Egmont Koblinger from comment #16)
> I honestly don't see the point in maintaining the two in parallel, I just
> see it as an additional burden. I really wouldn't want to burn engineering
> resources on this in the long run. If we do it for one or two cycles with
> the firm goal of retiring autotools then I'm fine with this compromise.

I totally agree with Egmont.

The reason for porting vte to meson (and also gnome-terminal and other gnome packages) is because it's a software I use and wanted to make a contribution that would be helpful/useful. It has proved very useful in other developments[0], and the number of packages ported to meson is a proof of this[1]. However, if this contribution causes more annoyance than advantages to the developers/maintainers, there's no point in working on it anymore.

[0] https://inigomartinez.github.io/2017/10/11/meson-and-gnome/
[1] https://wiki.gnome.org/Initiatives/GnomeGoals/MesonPorting

(In reply to Christian Persch from comment #15)

> I'd like to have a generated Makefile in builddir that translates a simple
> "make" / "make install" into the required meson commands.

What's your reason for this? If it's only that the commands of your muscle memory keep working, then I think it's best addressed with a wrapper script you create in front of your "make".

Anyway, I think we should put this issue on hold until you say you're ready to switch. :)

I have ended rebasing and updating vte's meson port. vte has changed a lot since I created the meson port. You can find it in the wip branch[0]. I hope this can help testing it. I would like to suggest that setting up a GitLab CI runner that builds vte's meson port could help.

I'm sorry to say that, among some other few issues, you need the wip version of meson (0.48.999 at the moment due the `module_version` `gtkdoc's` parameter). I also have updated the meson port according to the different GNOME's packages meson port, regardless of your comment. I haven't ignored them, but I've been more concerned about the consistency with those other packages. However, everything can be discussed.

Please, feel free to ask any question about it, as it contains many subtle details set after working a bit with meson.

I hope this doesn't become in another sad meson fiasco[1].

[0] https://gitlab.gnome.org/GNOME/vte/tree/wip/inigomartinez/meson
[1] https://bugzilla.gnome.org/show_bug.cgi?id=783819

> wip version of meson 0.48.999

Thanks – although this means I won't be able to test it until Ubuntu 19.04 – or whichever version will include it. I have no intent to manually update meson on my system. Also, I generally find it a bad idea to require such cutting edge version of other software, IMHO ideally there should be a safety window of at least a year, if not more.

Is it realistically expected that 0.49 will be good enough for us in the long run, and we can target a switch let's say a year after 0.49's release? Or is this going to be a never ending chase of the latest and greatest meson version? At least autotools didn't have this problem – as far as I can tell.

> another sad meson fiasco[1].

Why is [1] a fiasco? Looks like they switched.

I have removed the `module_version` and `c_args` parameters from the `gtkdoc` function and thanks to this the minimum meson's version requirement is now `0.46.0`. However, the `devhelp` file is named `vte.devhelp2` instead of `vte-${api_version}.devhelp2` and there are some missing bits in the documentation.

I have also changed how `libvte-${api_version}` is generated, because only the shared library was created and now both, static and shared, libraries are created.

I have updated the wip branch with these changes.

(In reply to Iñigo Martínez from comment #21)
> I have removed the `module_version` and `c_args` parameters from the
> `gtkdoc` function and thanks to this the minimum meson's version requirement
> is now `0.46.0`. However, the `devhelp` file is named `vte.devhelp2` instead
> of `vte-${api_version}.devhelp2` and there are some missing bits in the
> documentation.
> 
> I have also changed how `libvte-${api_version}` is generated, because only
> the shared library was created and now both, static and shared, libraries
> are created.
> 
> I have updated the wip branch with these changes.

That's not the correct thing to do here, since this creates a conflict with the API docs for the old vte version (which must be parallel-installable) and also with the future gtk4-based vte version's API docs. If getting it right requires meson 0.49, then so be it.

Also this demonstrates that even without *switching* vte to meson, the port has some value, in that it identified a deficit in meson.

Please push the commit "build: Use input file as parameter in box drawing script" to master; it's independently useful.

(In reply to Christian Persch from comment #22)
> That's not the correct thing to do here, since this creates a conflict with
> the API docs for the old vte version (which must be parallel-installable)
> and also with the future gtk4-based vte version's API docs. If getting it
> right requires meson 0.49, then so be it.

If you don't mind, I'd like to leave the meson port as it is now until meson 0.49 is officially released, as a proof of concept, so it can be easily tested. Once the new meson version is released I'll update the necessary bits.

> Also this demonstrates that even without *switching* vte to meson, the port
> has some value, in that it identified a deficit in meson.

In fact, meson has quite a few deficiencies[0], but authors/maintainers are usually very open to fix those and also to include new features. That's one of the reason why it's changing that much through versions.

> Please push the commit "build: Use input file as parameter in box drawing
> script" to master; it's independently useful.

Pushed.

BTW, if meson could be finally be an option for vte, and taking in consideration that the future GNOME's issue tracker is `gitlab.gnome.org`, what do you think about moving this discussion into an issue/MR there?

[0] https://github.com/mesonbuild/meson/issues

I've just realized that our library versioning strategy is different for stable and unstable releases.

Stable version 0.54.1 becomes libvte-2.91.so.0.5400.1
 Devel version 0.55.1 becomes libvte-2.91.so.0.5501.0
                                                 ^^^^

Not sure if it's just the filename or some internals too.

This originates from commit 860ed1875, refactored in commit 137e16630.

Is this a standard practice, or a VTE oddity?

According to the – somewhat confusing – comments removed in the first mentioned commit, it makes some sense: denotes that each devel version might add a new API while stable versions don't. (I'm wondering if anyone really cares, though, especially for the devel versions.)

Does the meson port keep this behavior?

You can find more information in a message from 2010[0]. Yes I tried to use the same behavior also in meson[1]. Take in consideration that meson does not use libtool, so the version number format changes a bit (the version number is the same though).

[0] https://mail.gnome.org/archives/desktop-devel-list/2010-June/msg00234.html
[1] https://gitlab.gnome.org/GNOME/vte/blob/wip/inigomartinez/meson/meson.build#L54

meson 0.49 release[0] has been announced today[1]. I have rebased and updated the wip meson branch[2] with some of the new features, and also by including the missing bits necessary for proper GtkDoc documentation generation.

Following also the previous comment[3], I have opened a new issue[4] to follow the development of the meson port, so any comment or suggestion can be added there.

[0] https://mesonbuild.com/Release-notes-for-0-49-0.html
[1] https://groups.google.com/forum/#!topic/mesonbuild/kgQLqciq8nY
[2] https://gitlab.gnome.org/GNOME/vte/tree/wip/inigomartinez/meson
[3] https://bugzilla.gnome.org/show_bug.cgi?id=784561#c24
[4] https://gitlab.gnome.org/GNOME/vte/issues/78

I haven't mentioned my pet peeve so far:

Similarly to "make", "ninja" doesn't guarantee either a correct build if I'm editing the source files while "ninja" is running, and then re-run "ninja" to catch up.

See https://github.com/ninja-build/ninja/issues/1162 and the duplicate 1497 that I filed.

In my opinion, this should be a basic requirement in any build system.

Apparently most people don't share my opinion here...

Egmont, meson is fairly standalone: it basically only depends on python3. You could easily download the meson .deb from Ubuntu 19.04 if you want a newer version.

Once your project has a working meson build, there's no need to be aggressive about requiring new meson versions. Newer versions fix bugs and make improvements.

meson does support static libraries, although most meson-using projects I've seen don't bother creating them. How important is it for you?

See https://mesonbuild.com/Reference-manual.html#library