build: initial support for meson build system #902
Conversation
meson.build
Outdated
| qjsc_exe = executable( | ||
| 'qjsc', | ||
| qjsc_srcs, | ||
| qjs_libc_srcs, |
There was a problem hiding this comment.
This will cause all of these sources to be re-compiled for the executable, but then it seems like you link them back in via the qjs_dep.
There was a problem hiding this comment.
qjs_libc_srcs == [] if -Dlibc=true, since it's already compiled in the main qjs_lib.
this variable is here to explicitly add quickjs-libc to required targets. is it better to use qjs_libc_lib = static_library(...) and then add link_whole: qjs_libc_lib to qjs_lib?
There was a problem hiding this comment.
applied the qjs_libc_lib thing.
|
I saw your comments on the wrap proposal, and thought I might take a peak at what you where working on. |
|
Prior art: #761 |
mochaaP
force-pushed
the
mochaa
branch
2 times, most recently
from
24aba70 to
42cb912
Compare
|
I'm the author of mesonbuild/wrapdb#1865 . Then initial motivation is that we do not want to add |
Personally I'm still on the fence about adding Meson support here. If wrapdb is there then users already have a good way forward. |
|
I'm mildly negative on the changes to the Makefile. A meson build file, okay, but only if I don't have to look at it or think about it too much. For testing it, I'd add a CI job. |
|
From Meson's perspective we would prefer if meson.build files could live upstream, even with a lower level of support that $main_build_system. WrapDB can still reference projects with upstream meson.build files to make |
|
LGTM from a meson is correct point of view |
|
@bnoordhuis whats your appetite towards this? I'm somewhere around -0.5 |
Regarding changes to the |
|
@chqrlie Please let's keep this about meson. |
I'm okay with merging it provided it's close-to-zero effort to maintain. I don't care for it myself but there's no denying meson is pretty popular nowadays. Having said that, since wrapdb exists, is there a compelling reason to have the build file in this repo? |
|
Having them upstream means that your users can use git snapshots and git submodules as subprojects, that’s not possible with meson files hosted in wrapdb |
|
That's a good reason. @saghul, up to you. |
|
Alright, let's give it a try. I'll give it a deeper look this week. What this PR is missing is a few CI jobs, to make sure this thing works at all :-) |
|
sure, i will add it |
|
should I add this to a separate workflow or just |
|
Same file, new jobs. |
mochaaP
force-pushed
the
mochaa
branch
2 times, most recently
from
3c67859 to
d5deb43
Compare
|
clang sanitized builds fail with: |
|
In quickjs-libc? Any way to get more output from the meson runners? They seem to output to a file. |
|
Sticking to the default limit seems best/most appropriate. |
|
@mochaaP can you please apply the fix above? |
|
sure. |
mochaaP
force-pushed
the
mochaa
branch
2 times, most recently
from
0bd07a5 to
f68504b
Compare
There was a problem hiding this comment.
LGTM! Thanks for the perseverance!
@bnoordhuis do you want to take another look?
|
uhh, and now Win32 builds fails? |
|
What the... I'll take a look tonight :-/ |
|
This fixes the Windows build: #954 |
|
@mochaaP Can you please rebase? |
|
Aside from the rebase the same stack size flags need to be passed on to the linker. |
|
all checks passed. 🥳 |
ci: fix actionlint warnings
…suppress clang sanitize warnings Co-authored-by: Saúl Ibarra Corretgé <[email protected]>
Align with 857c42b.
| args: -Dlibc=true | ||
| - name: mimalloc | ||
| args: -Dcli_mimalloc=auto | ||
| - name: jscheck |
There was a problem hiding this comment.
oooh i think i accidently forgot some leftovers from testing. cleaning it.
|
Squashed and merged in #957 |
Initial support for meson build system.
I plan to maintain this port continuously alongside cmake.
suppoted features
make BUILD_BACKEND=mesonxrefs
mesonbuild/wrapdb#1865
#761
tested