[External Project module] How to execute autogen.sh?

[moi15moi]

I'm trying to use the External Project module. Before running add_project which expects a configure script, I need to execute autogen.sh first.

The documentation states:

Note that if a bootstrap script is required (e.g. autogen.sh when building from git instead of tarball), it can be done using run_command() before calling add_project() method.

The problem is that autogen.sh must be run from its own directory.
I tried using run_command like this:

run_command('sh', 'autogen.sh', check: true)

Unsurprisingly, this fails because the working directory when running the command is not the directory containing autogen.sh.

The Meson logs show:

Running autoreconf...
autoreconf-2.72: export WARNINGS=
autoreconf-2.72: error: 'configure.ac' is required

The error occurs because configure.ac is not found because autogen.sh expects configure.ac to be in the current working directory.

So, is there any way to specify the working directory when executing the command? If not, how meson expect us to write run_command to execute autogen.sh?

Note that this is the autogen.sh that I am trying to run.

PS: I saw that there is an issue about the problem of working_directory, but I guess that since meson mention that it is possible to run autogen.sh with run_command there must be a way to do it that I haven't tought about.

[moi15moi]

Forget about it, it seems that run_command('./autogen.sh', check: true) works. It just that, for a unknown reason, it doesn't work on mingw, but it does work on a "native" linux disto.

[bonzini]

It should have converted c:/ to /, instead of . which isn't an absolute path. Can you try changing that bit at lines 95-96 to enforce an absolute path, adding something like self.prefix = Path('/') / self.prefix?

[moi15moi]

I did this: moi15moi@b78e41b

But now, I get this error:

configure: loading site script C:/msys64/etc/config.site
configure: error: cannot find required auxiliary files: ltmain.sh config.guess config.sub compile missing install-sh

I also have a CI that has pretty much the same error (the only different if the config.site path): https://productionresultssa10.blob.core.windows.net/actions-results/05f93487-8583-42f6-94c1-e5a7d2109b79/workflow-job-run-2a793b2e-9c6a-5027-8af2-bdf64a842c79/logs/job/job-logs.txt?rsct=text%2Fplain&se=2025-07-02T12%3A22%3A07Z&sig=souOLFmOsgFFVDKuJfdQCqiTJk%2F6uFCe0%2Fwwb8T2kBA%3D&ske=2025-07-03T00%3A05%3A42Z&skoid=ca7593d4-ee42-46cd-af88-8b886a2f84eb&sks=b&skt=2025-07-02T12%3A05%3A42Z&sktid=398a6654-997b-47e9-b12b-9515b896b4de&skv=2025-05-05&sp=r&spr=https&sr=b&st=2025-07-02T12%3A12%3A02Z&sv=2025-05-05

[moi15moi]

I have been able to fix the previous error with this commit: moi15moi/VideoTimestamps@a928674

To fix it, I don't call directly "./configure" anymore. I call configure.sh that has this content (so, it is a similar fix with autogen.sh. I use sh -l):

#!/bin/sh
sh -l "$(cygpath -u "$(dirname "$0")")/configure" "$@"

Now, I have this error:

2025-07-03T00:03:13.0785680Z   checking for libavformat >= 60.16.0 libavcodec >= 60.31.0 libswscale >= 7.5.0 libavutil >= 58.29.0 libswresample >= 4.12.0... no
2025-07-03T00:03:13.0786964Z   configure: error: Package requirements (libavformat >= 60.16.0 libavcodec >= 60.31.0 libswscale >= 7.5.0 libavutil >= 58.29.0 libswresample >= 4.12.0) were not met:

I don't know why it doesn't find ffmpeg requirement. In my CI, I also build the project on linux + macOS and I don't have this error. You can see the run here: https://github.com/moi15moi/VideoTimestamps/actions/runs/16038313069

I even use depends that should prevent this problem: https://github.com/moi15moi/VideoTimestamps/blob/a92867462d933f47cf079a2c4a29646b36675415/subprojects/packagefiles/ffms2/meson.build#L34

[moi15moi]

Oh, it doesn't find ffmpeg because sh -l change the env var, so the PKG_CONFIG_PATH doesn't contain the right value (that is correctly setted by meson).

So, I guess using sh -l is a bad idea, without it, I get this error: #14727 (reply in thread)

[moi15moi]

Finally, I created a branch based on #13916 where I also "fixed" the env var: https://github.com/moi15moi/meson/tree/fix
The fix is really hacky, but now I am able to setup the project on msys2.
I'm still not able to build it. I get this error:

2025-07-03T20:03:48.9083094Z   build step returned error code 2.
2025-07-03T20:03:48.9084913Z   while executing ['D:/a/_temp/msys64/tmp/pip-build-env-54ps7brr/overlay/bin/meson', '--internal', 'externalproject', '--name', 'ffms2', '--srcdir', 'D:/a/VideoTimestamps/VideoTimestamps/subprojects/ffms2', '--builddir', 'D:/a/VideoTimestamps/VideoTimestamps/.mesonpy-36bncvwy/subprojects/ffms2/build', '--installdir', 'D:/a/VideoTimestamps/VideoTimestamps/.mesonpy-36bncvwy/subprojects/ffms2/dist', '--logdir', 'D:/a/VideoTimestamps/VideoTimestamps/.mesonpy-36bncvwy/meson-logs', '--make', 'D:/a/_temp/msys64/usr/bin/make.EXE', '--verbose', 'subprojects/ffms2/ffms2.stamp', 'subprojects/ffms2/ffms2.d']
2025-07-03T20:03:48.9085160Z   [2314/2321] Linking static target subprojects/ffmpeg/libavcodec-static.a
2025-07-03T20:03:48.9085243Z   FAILED: subprojects/ffms2/ffms2.stamp
2025-07-03T20:03:48.9085907Z   "D:/a/_temp/msys64/tmp/pip-build-env-54ps7brr/overlay/bin/meson" "--internal" "exe" "--unpickle" "D:/a/VideoTimestamps/VideoTimestamps/.mesonpy-36bncvwy/meson-private/meson_exe_meson_199db12d0aa8c917625ebc98f6677f9187efe0cb.dat"
2025-07-03T20:03:48.9086292Z   [2316/2321] Compiling C++ object video_timestamps/video_provider/abc_video_provider.cp312-mingw_x86_64_msvcrt_gnu.pyd.p/abc_video_provider.cpp.obj
2025-07-03T20:03:48.9086727Z   [2317/2321] Compiling C++ object video_timestamps/video_provider/best_source_video_provider.cp312-mingw_x86_64_msvcrt_gnu.pyd.p/best_source_video_provider.cpp.obj
2025-07-03T20:03:48.9086811Z   ninja: build stopped: subcommand failed.

See these CI logs

Edit:
If I try to install ffms2 manually, I need to do this:

./autogen.sh
./configure
make LDFLAGS="-municode"

The problem is that meson external project doesn't allow us to pass a LDFLAGS ONLY to make. It will also pass it to configure which fail.

@bonzini Do you have a idea what we should do to fix the env var problem?