The thing is that you are still hitting the bad codepath for older versions of meson...
There's a useful if/else you can do here: on new enough meson versions, use import('fs').read('../src/examples/......') for portability reasons.
If you're looking up iconv in both sides of the branch, what's the point? Just use dependency('', required: false) to get a null dependency.
In this case I would advise not using configure_file at all. It seems to have nothing to configure, so usong configuration: conf is "wrong" (newer meson actually wants you to use fs.copy()!!) but the purpose of either one is supposed to be for files that you need in the build directory. For installing files, just (rename them to avoid the useless .in and) use install_data() instead.
A lot of this isn't really necessary. Meson will log an informational notice but not escalate to a deprecation warning for things that you don't have the ability to change yet due to meson_version…
This isn't the missing DLL error. It appears to be https://github.com/msys2/MINGW-packages/issues/11864
The issue there is that cpython itself randomly segfaults, but setting the debugger up…
This would presumably be an even bigger issue for using .full_path, which attempts to run the full path of a .exe without necessarily getting that to work in terms of injecting DLL dependencies.
…
BTW since meson 0.57 (a hefty bump in minimum version, I know) you can pass env: {'EFL_RUN_IN_TREE': '1'} to a custom target, and it will either use /usr/bin/env if possible or a slightly slower…
hmmm... full path is at least meant to remove $PATH from having an effect. what breaks on windows and why should we not use the full path?
Hi. The problem here is:
- rich program objects,…