search

mesonbuild / meson

The Meson Build System
http://mesonbuild.com
Apache License 2.0
5.59k stars 1.63k forks source link

meson dist --include-subprojects should apply diff_files from wrap #13102

Open agx opened 6 months ago

agx commented 6 months ago

Describe the bug

Building a dist tarball from a project with a subproject that uses diff_files and using --include-subprojects includes the subproject but without patches applied leading to unexpected results.

To Reproduce

Example wrap file:

[wrap-git]
directory=wlroots
url=https://gitlab.freedesktop.org/wlroots/wlroots.git
revision=0.17.2
depth=1

diff_files = wlroots/0001-Revert-layer-shell-error-on-0-dimension-without-anch.patch

Building the dist tarball like:

meson dist -C  _build-dist --no-tests --include-subprojects

Exmple project:

git clone https://gitlab.gnome.org/World/Phosh/phoc.git
git checkout v0.38.0 
meson setup _build-dist 
meson dist -C  _build-dist --no-tests --include-subprojects

Note that the generated subprojects/wlroots subdirectory does not have the subprojects/packagefiles/wlroots/0001-Revert-layer-shell-error-on-0-dimension-without-anch.patch applied.

(I can provide a minimal example if that helps)

Expected behavior I'd expect diff_files to be applied to subprojects in the generated tarballs as they're otherwise missing for builds from the tarball.

system parameters

xclaesse commented 6 months ago

It should have included the patch file in the tarball and it will be applied when the subproject is used. Does that work?

agx commented 6 months ago

@xclaesse That doesn't happen either, here's the bit from the build log:

$ tar axf phoc-0.38.0.tar.xz
$ cd phoc
$ meson setup _build
The Meson build system
Version: 1.2.3
Source dir: /tmp/phoc
Build dir: /tmp/phoc/_build
Build type: native build
Project name: phoc
Project version: 0.38.0
C compiler for the host machine: ccache cc (gcc 13.2.0 "cc (Debian 13.2.0-13) 13.2.0")
C linker for the host machine: cc ld.bfd 2.42
Host machine cpu family: x86_64
Host machine cpu: x86_64
Found pkg-config: /usr/bin/pkg-config (1.8.1)
Run-time dependency gio-2.0 found: YES 2.78.4
Run-time dependency glib-2.0 found: YES 2.78.4
Run-time dependency gobject-2.0 found: YES 2.78.4
Run-time dependency glesv2 found: YES 3.2
Run-time dependency gnome-desktop-3.0 found: YES 44.0
Run-time dependency gsettings-desktop-schemas found: YES 46.0
Run-time dependency libinput found: YES 1.25.0
Run-time dependency libdrm found: YES 2.4.120
Run-time dependency pixman-1 found: YES 0.42.2
Run-time dependency wayland-client found: YES 1.22.0
Run-time dependency wayland-protocols found: YES 1.34
Run-time dependency wayland-server found: YES 1.22.0
Run-time dependency xkbcommon found: YES 1.6.0
Library m found: YES

Executing subproject gmobile 

[... SNIP another subproject without patch]

Executing subproject wlroots 

wlroots| Project name: wlroots
wlroots| Project version: 0.17.2
wlroots| C compiler for the host machine: ccache cc (gcc 13.2.0 "cc (Debian 13.2.0-13) 13.2.0")
wlroots| C linker for the host machine: cc ld.bfd 2.42

So no patch gets applied for wlroots.

In contrast when cloning from git (so no submodules/wlroots present and submodules/wlroots.wrap is used to clone):

…
Cloning into 'wlroots'...
remote: Enumerating objects: 470, done.
remote: Counting objects: 100% (470/470), done.
remote: Compressing objects: 100% (452/452), done.
remote: Total 470 (delta 27), reused 132 (delta 8), pack-reused 0
Receiving objects: 100% (470/470), 736.87 KiB | 1.42 MiB/s, done.
Resolving deltas: 100% (27/27), done.
Applying diff file "wlroots/0001-Revert-layer-shell-error-on-0-dimension-without-anch.patch"

The above made me believe that patches would get applied to the tarball on meson dist. Having them applied during build would be o.k. too but doesn't happen for me either (I think it could also cause problems detecting if patches are properly applied already).

eli-schwartz commented 6 months ago

It should have included the patch file in the tarball and it will be applied when the subproject is used. Does that work?

Why would it do that? That would imply that we re-apply patches every time meson setup is run, which would be illogical and not work.