annacrombie/muon

An implementation of the meson build system in c99

muon's Issues

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.

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

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.

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

Path separators in target output.

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

Related

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?

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

Bump meson compatibility to v1.2.0+

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

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