annacrombie / muon Goto Github PK

An implementation of the meson build system in c99

License: GNU General Public License v3.0

Shell 0.70% C 76.30% Meson 19.12% Roff 0.03% Python 2.72% C++ 0.68% Assembly 0.27% LLVM 0.01% Fortran 0.01% Batchfile 0.02% Lex 0.01% Vim Script 0.11% Cython 0.03%

meson build-system c99

muon's People

Contributors

Stargazers

Watchers

Forkers

dangyajun wdlkmpx amcn danieldavis5 jcwasmx86 rofl0r vtorri apprehensions torque

muon's Issues

Commands on Stage 2 doesn't work for me

I'm on Windows 7 (without MSYS2) so I'm using a standalone MinGW-w64 distro with Windows Command Prompt. It seems the developer doesn't have this setup in mind. I don't know if his support for MSVC is any better, too.

Please note that I have managed to have muon bootstrapped successfully (see: #37).

I have to change build/muon into build\muon.exe for the command to be able to run.

build\muon.exe setup build worked. But build\muon.exe -C build samu failed. I inserted -v and this is the error message:

C:\Work\muon>build\muon.exe -v -C build_muon samu
[1/129] compiling c subprojects/tinyjson/libtiny-json.a.p/tiny-json.c.o
dbg executing : '"/bin/sh" -c gcc -std=c99 -g -O0 -Wpedantic -Wextra -Wall -I subprojects/tinyjson -I ../subprojects/tinyjson -MD -MQ subprojects/tinyjson/libtiny-json.a.p/tiny-json.c.o -MF subprojects/tinyjson/libtiny-json.a.p/tiny-json.c.o.d -o subprojects/tinyjson/libtiny-json.a.p/tiny-json.c.o -c ../subprojects/tinyjson/tiny-json.c'
err CreateProcess() failed: The system cannot find the file specified.
samu: failed to start job: failed to create process
samu: job failed to start
samu: subcommand failed

Why muon is trying to invoke sh on a pure Windows environment?

warn configuring muon for an unsupported platform "unknown"

$ ./build/muon setup build
detected compiler gcc '14.1.0' (['cc']), linker: ld (gnu) (['ld']), static_linker: ar (gcc) (['ar'])
configuring 'muon', version: 0.2.0
warn configuring muon for an unsupported platform "unknown"
c compiler: supports argument '-Wendif-labels': YES
c compiler: supports argument '-Wimplicit-fallthrough=2': YES
c compiler: supports argument '-Winit-self': YES
c compiler: supports argument '-Wlogical-op': YES
c compiler: supports argument '-Wmissing-include-dirs': YES
c compiler: supports argument '-Wno-missing-braces': YES
c compiler: supports argument '-Wno-missing-field-initializers': YES
c compiler: supports argument '-Wno-unused-parameter': YES
c compiler: supports argument '-Wold-style-definition': YES
c compiler: supports argument '-Woverflow': YES
c compiler: supports argument '-Wstrict-aliasing=2': YES
c compiler: supports argument '-Wstrict-prototypes': YES
c compiler: supports argument '-Wundef': YES
c compiler: supports argument '-Wvla': YES
c compiler: supports argument '-fstrict-aliasing': YES
c compiler: supports argument '-std=c99': YES
/home/Administrator/muon/src/platform/meson.build:26:42: error file 'null/filesystem.c' does not exist
/home/Administrator/muon/src/platform/meson.build:26:25: error in function files
/home/Administrator/muon/src/meson.build:95:1: error in function subdir
/home/Administrator/muon/meson.build:141:1: error in function subdir

Everything is fine on MSYS2 MSYS (the Cygwin-based environment). I guess it will fail for all MinGW-w64 based environments.

Please note: I can't use the muon binary compiled on MSYS2 MSYS. Each MSYS2 environment has their own libraries and toolings; for example, apart from the MSYS2 pkgconf, there is also mingw-w64-ucrt-x86_64-pkgconf. The muon binary compiled on MSYS2 MSYS will not integrate with other environments. Each environment will need its own version of muon.

prefer_static not implemented yet?

When building a 3rd-party project, I'd like to be able to tell it to build both library types with the -Ddefault_library=both (works) argument but link any created binaries statically, with the -Dprefer_static=true option. Unfortunately, the latter does not seem to work yet in muon, which throws an invalid option error.

Kindly request supporting such an option.

missing features of custom target code

when i try to debug my windows module,

afaics, it is not possible to set the value of the depends kwarg
build.ninja has no DEPFILE_UNQUOTED entry
there is no description entry (though i guess it is not so important)
in the build.ninja generated by meson, i can see C$:/Documents/msys2/mingw64/bin/windres.EXE in CUSTOM_COMMAND.

string.to_upper() does not work correctly on f-strings

I have the following (that works correctly with Meson):

cpp = meson.get_compiler('cpp')
conf = configuration_data()
foreach f : ['unreachable']
  conf.set10(f'HAVE_@f@'.to_upper(), cpp.has_function(f))
endforeach
conf_h = configure_file(
  configuration : conf,
  output : 'config.hpp',
)

With meson this correctly produces a header file:

#pragma once
#define HAVE_UNREACHABLE 1

With Muon (tip of main branch)

#pragma once
#define HAVE_unreachable 1

The following solutions work as expected:

'HAVE_@0@'.format(f).to_upper()
'HAVE_@0@'.format(f.to_upper())

dependency() does not accept the `main` argument to `dependency('gtest')`

Upstream Meson allows the following: dependency('gtest', main : true), which is the same as dependency('gtest_main'), but without having a magical name that might not be expected.

I understand this is probably a very low priority issue, but it's an actual issue I've run into

`clean` target not created

Meson's ninja backend creates a clean target in its build.ninja such that:

$ ninja clean

invokes the clean target and also cleans up any outputs of custom_target.

muon's ninja backend does not create this target. Is this by design?

For context, I was looking into implementing support for b_coverage in muon and I noticed that meson's coverage support includes the cleaning up of the .gcda and .gcno files which then lead me to discover this difference in the clean target.

EDIT: This is more a question than an issue, but I can't seem to add the question label.

How to build code using the built-in samu?

I always use a standalone ninja up to now. I found that samu is embedded into the muon executable itself. But the equivalent command to meson, muon compile -C build, doesn't work (see: #43). Since there is no standalone samu executable and there is also no way to start the build via muon itself, how could I use the built-in samu?

Update: Maybe the syntax is muon -C build [something] based on the commands on Stage 2? But how to know what this [something] is? Take this project for example: https://github.com/franko/fox. I have tried everything I could think of but it always said err invalid command [something]!

String version comparison not supported in binary expressions

Under meson the following expression:

if '0.10.0' <= '0.20.0'
  message('0.10.0 <= 0.20.0')
endif

yields: Message: 0.10.0 <= 0.20.0

Under muon, it yields a type error: error expected type int, got str. Is this a deliberate choice?

Path separators in target output.

Has outputting to sub-directories in the build directory been considered?

How to build with Tiny C Compiler on Linux?

bootstrap.sh works, but the second stage is failing. there's a cc symlink to tcc, c11 and c99 that point to the corresponding standards that tcc supports. What do I do? I refuse to use gcc or clang for this.

import('i18n', required: false).found() returns true in the latest git

It works fine in muon 0.2.0, but in the latest git, I just get the error:

error module 'i18n' is unimplemented,
  If you would like to make your build files portable to muon, use `import('i18n', required: false)`, and then check the .found() method before use.

Which is exactly what I'm doing.

Bisecting says 5e1c455cbcc7d4c184c8eb591926ec57deebc0e4 is the first bad commit.

muon does not consider PKG_CONFIG env var

the system only has pkgconf thus

export PKG_CONFIG=pkgconf

meson setup .build --reconfigure
The Meson build system
Version: 1.4.0
Source dir: /Users/lu_zero/Sources/muon
Build dir: /Users/lu_zero/Sources/muon/.build
Build type: native build
Project name: muon
Project version: 0.2.0
C compiler for the host machine: sccache cc (clang 15.0.0 "Apple clang version 15.0.0 (clang-1500.3.9.4)")
C linker for the host machine: cc ld64 1053.12
Host machine cpu family: aarch64
Host machine cpu: aarch64
Program git found: YES (/opt/homebrew/bin/git)
Compiler for C supports arguments -Wendif-labels: YES (cached)
Compiler for C supports arguments -Wimplicit-fallthrough=2: NO (cached)
Compiler for C supports arguments -Winit-self: YES (cached)
Compiler for C supports arguments -Wlogical-op: NO (cached)
Compiler for C supports arguments -Wmissing-include-dirs: YES (cached)
Compiler for C supports arguments -Wno-missing-braces: YES (cached)
Compiler for C supports arguments -Wno-missing-field-initializers: YES (cached)
Compiler for C supports arguments -Wno-unused-parameter: YES (cached)
Compiler for C supports arguments -Wold-style-definition: YES (cached)
Compiler for C supports arguments -Woverflow: YES (cached)
Compiler for C supports arguments -Wstrict-aliasing=2: YES (cached)
Compiler for C supports arguments -Wstrict-prototypes: YES (cached)
Compiler for C supports arguments -Wundef: YES (cached)
Compiler for C supports arguments -Wvla: YES (cached)
Compiler for C supports arguments -fstrict-aliasing: YES (cached)
Configuring version.c using configuration
Dependency libcurl found: YES 8.4.0 (cached)
Found pkg-config: YES (/opt/homebrew/bin/pkgconf) 2.1.1
Found CMake: /opt/homebrew/bin/cmake (3.28.3)
Run-time dependency libarchive found: NO (tried pkgconfig, framework and cmake)
Dependency libpkgconf found: YES 2.1.1 (cached)
Dependency bestline skipped: feature bestline disabled
Run-time dependency tinyjson found: NO (tried pkgconfig, framework and cmake)
Looking for a fallback subproject for the dependency tinyjson
Building fallback subproject with default_library=static

Executing subproject tinyjson

tinyjson| Project name: tiny-json
tinyjson| Project version: undefined
tinyjson| C compiler for the host machine: sccache cc (clang 15.0.0 "Apple clang version 15.0.0 (clang-1500.3.9.4)")
tinyjson| C linker for the host machine: cc ld64 1053.12
tinyjson| Build targets in project: 3
tinyjson| Subproject tinyjson finished.

Dependency tinyjson found: YES undefined (overridden)
Run-time dependency tracy found: NO (tried pkgconfig, framework and cmake)
Program python3 found: YES (/opt/homebrew/bin/python3)
Program test.sh found: YES (/Users/lu_zero/Sources/muon/tests/fmt/test.sh)
Program test.sh found: YES (/Users/lu_zero/Sources/muon/tests/fmt/editorconfig/test.sh)
Program afl-fuzz found: NO
Program runner.sh found: YES (/Users/lu_zero/Sources/muon/tests/project/runner.sh)
Program scdoc found: NO
Build targets in project: 4

muon 0.2.0

    libcurl   : true
    libarchive: false
    libpkgconf: true
    bestline  : false

  Subprojects
    tinyjson  : YES

Found ninja-1.11.1 at /opt/homebrew/bin/ninja
Cleaning... 0 files.

muon setup .build-muon
detected compiler clang '1500.3.9.4' (['cc']), linker: ld64 (['ld']), static_linker: ar (['ar'])
configuring 'muon', version: 0.2.0
c compiler: supports argument '-Wendif-labels': YES
c compiler: supports argument '-Wimplicit-fallthrough=2': NO
c compiler: supports argument '-Winit-self': YES
c compiler: supports argument '-Wlogical-op': NO
c compiler: supports argument '-Wmissing-include-dirs': YES
c compiler: supports argument '-Wno-missing-braces': YES
c compiler: supports argument '-Wno-missing-field-initializers': YES
c compiler: supports argument '-Wno-unused-parameter': YES
c compiler: supports argument '-Wold-style-definition': YES
c compiler: supports argument '-Woverflow': YES
c compiler: supports argument '-Wstrict-aliasing=2': YES
c compiler: supports argument '-Wstrict-prototypes': YES
c compiler: supports argument '-Wundef': YES
c compiler: supports argument '-Wvla': YES
c compiler: supports argument '-fstrict-aliasing': YES
configuring '/Users/lu_zero/Sources/muon/.build-muon/src/version.c'
warn dependency ['libcurl'] not found
warn dependency ['libarchive'] not found
fallback ['pkgconf','dep_libpkgconf'] failed for 'libpkgconf'
fallback ['pkgconf','dep_libpkgconf'] failed for 'libpkgconf'
warn dependency ['libpkgconf'] not found
[tinyjson] entering subproject 'tinyjson'
[tinyjson] detected compiler clang '1500.3.9.4' (['cc']), linker: ld64 (['ld']), static_linker: ar (['ar'])
[tinyjson] configuring 'tiny-json', version: undefined
found dependency 'tinyjson' (declared dependency) version undefined static
warn dependency ['tracy'] not found

summary:
- muon 0.2.0
      libcurl: false
      libarchive: false
      libpkgconf: false
      bestline: false
setup complete

muon compile -C build

Currently doesn't work:

err invalid command 'compile'

Please support Windows resources

I tried to build this project:

https://github.com/franko/fox

Everything is fine, but the binaries don't have their icons!

How to build on Windows with MinGW compiler?

I'm using the MinGW compiler from winlibs.com. bootstrap.bat only supports MSVC. I can compile a muon-bootstrap.exe with the MinGW compiler but I don't know what to do next.

Segmentation fault on setup for compiler.has_function() with dependencies

Hi, @annacrombie

I found a crash on the setup subcommand. Here are the steps to reproduce it:

Build muon and show version

git clone --depth 1 -b master https://git.sr.ht/~lattis/muon
cd muon
./bootstrap.sh stage1
# There are no necessary dependencies to reproduce the segfault.
./stage1/muon setup -Ddocs=disabled -Dlibarchive=disabled -Dlibcurl=disabled -Dlibpkgconf=disabled stage2
./stage1/muon samu -C stage2

$ ./stage2/muon version
muon 0.2.0-bd2e191
meson compatibility version 1.1.99
enabled features:
  samurai

Prepare a sample project for reproducing the segfault.

mkdir sample_project
cd sample_project
cat <<EOF >meson.build
project('sample_project', 'c', version : '0.1')

dep = dependency('', required : false)
c_compiler = meson.get_compiler('c')
c_compiler.has_function('xxxxxx', dependencies : dep)
EOF

Proceed with the setup:

$ ../stage2/muon setup _build
detected compiler gcc '13.2.0' (['cc']), linker: ld (gnu) (['ld']), static_linker: ar (gcc) (['ar'])
configuring 'sample_project', version: 0.1
Segmentation fault (core dumped)

To further investigate the issue, I ran the command under gdb and obtained a backtrace:

$ gdb --args ../stage2/muon setup _build
(gdb) run
(snip)
detected compiler gcc '13.2.0' (['cc']), linker: ld (gnu) (['ld']), static_linker: ar (gcc) (['ar'])
configuring 'sample_project', version: 0.1

Program received signal SIGSEGV, Segmentation fault.
push_linker_args (wk=0x7fffffffc310, ctx=0x7fffffffa4e0, args=0x5555556175f0 <args>) at ../src/backend/common_args.c:510
510             if (ctx->compiler->linker_passthrough) {
(gdb) p ctx
$1 = (struct setup_linker_args_ctx *) 0x7fffffffa4e0
(gdb) p ctx->compiler
$2 = (struct obj_compiler *) 0x0
(gdb) bt
#0  push_linker_args (wk=0x7fffffffc310, ctx=0x7fffffffa4e0, args=0x5555556175f0 <args>) at ../src/backend/common_args.c:510
#1  0x0000555555560e5c in setup_linker_args (wk=0x7fffffffc310, proj=0x0, tgt=0x0, ctx=0x7fffffffa4e0) at ../src/backend/common_args.c:613
#2  0x000055555556be7c in compiler_check (wk=0x7fffffffc310, opts=0x7fffffffaac0,
    src=0x7fffffffab70 "#define xxxxxx muon_disable_define_of_xxxxxx\n\n#include <limits.h>\n#undef xxxxxx\n#ifdef __cplusplus\nextern \"C\"\n#endif\nchar xxxxxx (void);\n#if defined __stub_xxxxxx || defined __stub___xxxxxx\nfail fail "..., err_node=3258, res=0x7fffffffaa4d)
    at ../src/functions/compiler.c:314
#3  0x000055555556dcca in func_compiler_has_function (wk=0x7fffffffc310, self=447, res=0x7fffffffbbe8) at ../src/functions/compiler.c:924
#4  0x00005555555ba8b3 in vm_native_func_dispatch (wk=0x7fffffffc310, func_idx=207, self=447, res=0x7fffffffbbe8) at ../src/lang/vm.c:1971
#5  0x00005555555b8f8f in vm_op_call_method (wk=0x7fffffffc310) at ../src/lang/vm.c:1316
#6  0x00005555555ba30b in vm_execute (wk=0x7fffffffc310) at ../src/lang/vm.c:1811
#7  0x000055555559c32b in eval (wk=0x7fffffffc310, src=0x555555636f50, mode=eval_mode_first, res=0x7fffffffbcf8) at ../src/lang/eval.c:143
#8  0x000055555559c5d4 in eval_project_file (wk=0x7fffffffc310,
    path=0x7fffffffbec0 "/home/ma8ma/var/src/muon/muon/sample_project/meson.build", first=true) at ../src/lang/eval.c:192
#9  0x000055555559bfb0 in eval_project (wk=0x7fffffffc310, subproject_name=0x0,
    cwd=0x55555565b9c0 "/home/ma8ma/var/src/muon/muon/sample_project",
    build_dir=0x55555565bfa2 "/home/ma8ma/var/src/muon/muon/sample_project/_build", proj_id=0x7fffffffc2f8) at ../src/lang/eval.c:65
#10 0x00005555555cf2c7 in cmd_setup (argc=3, argi=3, argv=0x7fffffffda08) at ../src/main.c:854
#11 0x00005555555cfebc in cmd_main (argc=3, argi=1, argv=0x7fffffffda08) at ../src/main.c:1066
#12 0x00005555555d002b in main (argc=3, argv=0x7fffffffda08) at ../src/main.c:1098

Expected setup result:

detected compiler gcc '13.2.0' (['cc']), linker: ld.bfd (['ld.bfd']), static_linker: ar (gcc) (['ar'])
configuring 'sample_project', version: 0.1
c compiler: has function xxxxxx: NO

setup complete

Please let me know if you need any further information to investigate this issue.

Thank you.

type-pun warnings in rpath_fixer.c

getting a bunch of warnings about type-punning pointers , like these:

../src/platform/posix/rpath_fixer.c:106:3: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
   elf->shoff = ((Elf32_Ehdr *)buf)->e_shoff;
   ^~~
../src/platform/posix/rpath_fixer.c:107:3: warning: dereferencing type-punned p>
   elf->shentsize = ((Elf32_Ehdr *)buf)->e_shentsize;
   ^~~

it goes on until line 201. gcc used: 6.5.0
these should probably be fixed using memcpy, or by adding -fno-strict-aliasing to that TU.

Assertion failure in analyzer when returning nested complex types

The following function in Muon's extended language causes the analyzer to assert:

func return_nested_complex_type() -> list[any]
  ls = find_program('ls')

  tgts = []

  foreach i : range(3)
    tgts += run_target(f'run_tgt@i@', command: ls)
  endforeach

  return [ tgts, 'hello', 'world' ]
endfunc

The assertion failure is: ../src/lang/typecheck.c:19: obj_type_to_tc_type: Assertion 't - 1 < tc_type_count' failed.

However, if I restructure the function to be as follows, then the assertion does not fail:

func return_nested_complex_type() -> list[any]
  ls = find_program('ls')
  run_tgts = [
    run_target('run_tgt0', ls),
    run_target('run_tgt1', ls),
    run_target('run_tgt2', ls)
  ]

  return [ run_tgts, 'hello', 'world' ]
endfunc

So it seems to be related to the separate declaration and modification of the tgts variable.

Upon assertion gdb renders the stack as:

#0  __pthread_kill_implementation (threadid=549621233440, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
#1  0x0000007ff7ca0a64 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78
#2  0x0000007ff7c5a76c in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3  0x0000007ff7c474bc in __GI_abort () at ./stdlib/abort.c:79
#4  0x0000007ff7c541e4 in __assert_fail_base (fmt=0x7ff7d6f2c8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x55555e93d0 "t - 1 < tc_type_count", file=file@entry=0x55555e93b8 "../src/lang/typecheck.c", line=line@entry=19, 
    function=function@entry=0x55555e94d0 <__PRETTY_FUNCTION__.2> "obj_type_to_tc_type") at ./assert/assert.c:92
#5  0x0000007ff7c5424c in __GI___assert_fail (assertion=0x55555e93d0 "t - 1 < tc_type_count", file=0x55555e93b8 "../src/lang/typecheck.c", line=19, function=0x55555e94d0 <__PRETTY_FUNCTION__.2> "obj_type_to_tc_type") at ./assert/assert.c:101
#6  0x00000055555aed54 in obj_type_to_tc_type (t=obj_typeinfo) at ../src/lang/typecheck.c:19
#7  0x00000055555af4f0 in typecheck_nested_type_arr_iter (wk=0x7fffffd728, _ctx=0x7fffffbe60, v=7248) at ../src/lang/typecheck.c:239
#8  0x00000055555a1c90 in obj_array_foreach (wk=0x7fffffd728, arr=7816, ctx=0x7fffffbe60, cb=0x55555af4c4 <typecheck_nested_type_arr_iter>) at ../src/lang/object.c:507
#9  0x00000055555af864 in typecheck_complex_type (wk=0x7fffffd728, got_obj=7816, got_type=9223372036854776064, type=10376575016438333726) at ../src/lang/typecheck.c:304
#10 0x00000055555af960 in typecheck_custom (wk=0x7fffffd728, n_id=871, got_obj=7816, type=10376575016438333726, fmt=0x55555e67f0 "function returned invalid type, expected %s, got %s") at ../src/lang/typecheck.c:332
#11 0x00000055555949e8 in analyze_node (wk=0x7fffffd728, n_id=871, res=0x7fffffbf7c) at ../src/lang/analyze.c:1632
#12 0x000000555559dda0 in interp_node (wk=0x7fffffd728, n_id=870, res=0x7fffffc034) at ../src/lang/interpreter.c:1220
#13 0x0000005555594888 in analyze_node (wk=0x7fffffd728, n_id=256, res=0x7fffffc034) at ../src/lang/analyze.c:1603
#14 0x0000005555567aa0 in func_obj_call (wk=0x7fffffd728, f=0x5555686400, args=3171, res=0x7fffffc0c4) at ../src/functions/common.c:762
#15 0x0000005555591c98 in analyze_func_obj_immediate (wk=0x7fffffd728, n_id=233, func_obj=3161) at ../src/lang/analyze.c:695
#16 0x0000005555594870 in analyze_node (wk=0x7fffffd728, n_id=233, res=0x7fffffc1ac) at ../src/lang/analyze.c:1597
#17 0x000000555559dda0 in interp_node (wk=0x7fffffd728, n_id=232, res=0x7fffffc35c) at ../src/lang/interpreter.c:1220
#18 0x0000005555594888 in analyze_node (wk=0x7fffffd728, n_id=1, res=0x7fffffc35c) at ../src/lang/analyze.c:1603
#19 0x0000005555596420 in eval (wk=0x7fffffd728, src=0x7fffffc360, mode=eval_mode_default, res=0x7fffffc35c) at ../src/lang/eval.c:166
#20 0x0000005555587480 in module_import (wk=0x7fffffd728, name=0x55556b61e3 "i18n", encapsulate=true, res=0x7fffffc954) at ../src/functions/modules.c:97
#21 0x0000005555576c84 in func_import (wk=0x7fffffd728, _=0, args_node=14, res=0x7fffffc954) at ../src/functions/kernel.c:1599
#22 0x0000005555568900 in analyze_function (wk=0x7fffffd728, fi=0x555561f6a8 <impl_tbl_kernel+1080>, args_node=14, rcvr=0, res=0x7fffffc954, was_pure=0x7fffffc953) at ../src/functions/common.c:1111
#23 0x0000005555591fdc in analyze_function_call (wk=0x7fffffd728, n_id=13, args_node=14, fi=0x555561f6a8 <impl_tbl_kernel+1080>, rcvr=0, res=0x7fffffc9a4) at ../src/lang/analyze.c:763
#24 0x00000055555927c8 in analyze_func (wk=0x7fffffd728, n_id=13, chained=false, l_id=0, res=0x7fffffca58) at ../src/lang/analyze.c:925
#25 0x0000005555594a38 in analyze_node (wk=0x7fffffd728, n_id=13, res=0x7fffffca58) at ../src/lang/analyze.c:1645
#26 0x0000005555594600 in analyze_assign (wk=0x7fffffd728, n=0x55556ea408) at ../src/lang/analyze.c:1540
#27 0x0000005555594ad8 in analyze_node (wk=0x7fffffd728, n_id=11, res=0x7fffffcb0c) at ../src/lang/analyze.c:1663
#28 0x000000555559dda0 in interp_node (wk=0x7fffffd728, n_id=9, res=0x7fffffcc94) at ../src/lang/interpreter.c:1220
#29 0x0000005555594888 in analyze_node (wk=0x7fffffd728, n_id=1, res=0x7fffffcc94) at ../src/lang/analyze.c:1603
#30 0x0000005555596420 in eval (wk=0x7fffffd728, src=0x7fffffcc98, mode=eval_mode_first, res=0x7fffffcc94) at ../src/lang/eval.c:166
#31 0x000000555559656c in eval_project_file (wk=0x7fffffd728, path=0x7fffffce70 "/home/andrew/github/muon/build/welp/meson.build", first=true) at ../src/lang/eval.c:199
#32 0x00000055555951a0 in analyze_eval_project_file (wk=0x7fffffd728, path=0x7fffffce70 "/home/andrew/github/muon/build/welp/meson.build", first=true) at ../src/lang/analyze.c:1853
#33 0x0000005555596008 in eval_project (wk=0x7fffffd728, subproject_name=0x0, cwd=0x5555669980 "/home/andrew/github/muon/build/welp", build_dir=0x55555e9550 "dummy", proj_id=0x7fffffd6f4) at ../src/lang/eval.c:63
#34 0x0000005555595920 in do_analyze (opts=0x7fffffe480) at ../src/lang/analyze.c:2046
#35 0x00000055555bcf68 in cmd_analyze (argc=2, argi=2, argv=0x7ffffff058) at ../src/main.c:340
#36 0x00000055555bfea0 in cmd_main (argc=2, argi=1, argv=0x7ffffff058) at ../src/main.c:1075
#37 0x00000055555bffbc in main (argc=2, argv=0x7ffffff058) at ../src/main.c:1107

I am looking into this as I am close to submitting a script module implementation of Meson's i18n module and the gettext function on that module exercises exactly this codepath: it returns a list which itself contains a list of custom_tgt objects.

Bump meson compatibility to v1.2.0+

New features described here. Among the key features: "default_options and override_options may now be dictionaries".