annacrombie/muon

An implementation of the meson build system in c99

muon

muon is an implementation of the meson build system in c99 with minimal dependencies.

Features

• muon analyze - a static analyzer for meson.build files. demo
• muon fmt - a meson.build code formatter
• An interactive stepping debugger with the dbg() function.
• A built-in cross platform ninja implementation
• fast

Status

muon is close to feature-complete with the core of meson for c and c++.

See the status page for more detailed information.

Things missing include:

• cross-compilation support
• build optimizations like pch and unity
• some b_ options
• dependencies with a custom configuration tool
• many modules

Other differences from meson are described in doc/differences.md

If you want to contribute, try using muon to build your favorite project. Patches and bug reports welcome!

Dependencies

Essential:

• A c99 compatible toolchain

For pkgconf support:

• libpkgconf
• pkgconf or pkg-config

For [wrap-file] support:

• libcurl
• libarchive

To build documentation:

• scdoc for muon.1 and meson.build.5
• python3 and py3-yaml for meson-reference.3

To run most project tests:

• python3

Install

If you already have meson or muon and are not interested in bootstrapping, you can just do a typical meson configure, build, install:

$meson setup build
cd build
ninja build
$meson test
$meson install

Otherwise, you must bootstrap muon.

The bootstrapping process has two stages. The first stage produces a muon binary capable of building itself (but not necessarily anything else). The second stage produces the final binary.

Stage 1:

./bootstrap.sh build

This will by default build a ninja implementation (samu) into the resulting executable. To disable this behavior use CFLAGS=-DBOOTSTRAP_NO_SAMU.

Stage 2:

build/muon setup build
build/muon -C build samu
build/muon -C build test
build/muon -C build install

Contribute

Please refer to the contributing guide before sending patches. Send patches on the mailing list, report issues on the issue tracker, and discuss in #muon on libera.chat.

License

muon is licensed under the GPL version 3 (see LICENSE). Tests under tests/project were copied from the meson project tests and are licensed under Apache 2.0.

Credits

Although I had already had the idea to re-implement meson in C, I was initially inspired to actually go out and do it when I saw boson. muon's code was originally based on boson, though has since been almost completely rewritten.

muon's Issues

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

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.

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())

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.

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?

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.

`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.

Bump meson compatibility to v1.2.0+

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

Path separators in target output.

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

Related

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