Maybe we ought to switch to plain buildtype as it is what upstream recommends https://mesonbuild.com/Quick-guide.html#using-meson-as-a-distro-packager

GNOME Documents probably should not rely on this though and use meson subprojects instead: https://mesonbuild.com/Subprojects.html#download-subprojects

I think we should do what you think is best ;), sir resident expert. But I can take a look if discussion is helpful, but if you're saying that's how it is I say let's do it :).

The information about what each build type does is pretty scattered and I am not sure which flags we would need to set using plain. We would probably need to define them in the cross file https://mesonbuild.com/Running-Meson.html#environment-variables
@Ericson2314 might be a better person to tackle this

The information about what each build type does is pretty scattered and I am not sure which flags we would need to set using plain.

I made this patch exactly because the plain build type was pretty undocumented.
The pr that introduced this added the condition on plain because it was possible that certain environments wouldn't have git?
Not sure if that was even a proper use.

At any rate do we really need total control of the flags used?

GNOME Documents probably should not rely on this though and use meson subprojects instead: https://mesonbuild.com/Subprojects.html#download-subprojects

Indeed, I should submit a patch. Though do we have support for that in nixpkgs?

Hmm, setup hook should probably add nodownload to mesonFlags. But since the dist tarball already includes the submodule, it is probably not downloaded anyway.

GNOME Documents probably should not rely on this though and use meson subprojects instead: https://mesonbuild.com/Subprojects.html#download-subprojects

Actually, I don't think that would do what they want, since it would just fetch it from the submodule's commit and not the latest.

perhaps they could do https://github.com/mesonbuild/meson/blob/master/docs/markdown/Wrap-dependency-system-manual.md#wrap-git

Does the command really fetch HEAD? That sounds like a very bad idea.

Does the command really fetch HEAD? That sounds like a very bad idea.

No 😄.
git submodule ui changes too much in my head.

Ahh now I found why they did this

https://gitlab.gnome.org/GNOME/gnome-photos/merge_requests/59
My understanding is that it ensures that the contents
of subprojects/foo to match whatever is committed into Git.

Say I have a stale checkout of a project, with a stale submodule
checkout, on some computer.

Now, in the meantime, the submodule was updated and committed
into Git from elsewhere.

When I come back to the stale checkout and do 'git fetch origin
&& git rebase origin/master', and do a build, I want the contents of
submodule/foo to get force-updated to match Gwhat's known to it as part
of the build.

And meson won't update this once it's fetched.

All of this for:

My main objective was to avoid the manual
intervention, so that I don't mistakenly release broken tarballs and such.

No point really arguing that. I think just checking if git exists would be better, i.e buildtype plain doesn't make sense for this.

And meson won't update this once it's fetched.

I think it will with subproject. And it definitely will be noticed during dist.

Opened as #58310