Meson support

[satk0]

Hello again,

I tried to subproject qjs inside r2 but found out that there is no meson.build file implemented. Would be great if it was ;)

Could I please take care of it?

[saghul]

I don't have much experience with it, but I fear the rabbit hole it would open, since others may want their build system of choice supported.

[trufae]

Frida keeps a fork of bellard's qjs just to hold the meson.build and few extra patches. having that in qjsng will let other projects use it without patches or forks https://github.com/frida/quickjs

[satk0]

I thought that it would be attractive to you as it could help to move forward with source code layout plans as mentioned here #133

[saghul]

We are keeping the current layout for now, so that doesn't change things.

Ben also proposed we do amalgamated builds so it might end up just being 2 files. I think there would be no build system on that type of source release.

Is it really not possible to keep the meson file in r2 while using quickjsng as a sub module?

[satk0]

I've managed to add it via meson diff_files but r2 uses different version to test etc. and some of this meson versions don't have this feature. That's all I know. @trufae would have definitely more to say about this.

[KaruroChori]

@satk0, a special meson.build is not really needed to use it in a meson project. I am using it as a cmake subproject and it works perfectly fine :).
For reference https://github.com/KaruroChori/vs-fltk integrated @ https://github.com/KaruroChori/vs-fltk/blob/c3bc5f2de65cc823f1de282c6a6791836d712aca/meson.build#L130 & wrap @ https://github.com/KaruroChori/vs-fltk/blob/master/subprojects/quickjs.wrap

[satk0]

@KaruroChori Oooh, Looks neat. However it requires having cmake installed ;/ Nevertheless, clever walk around ;)

Btw, Interesting project :)

[bnoordhuis]

I'm not strenuously opposed to meson support but amalgamated builds (#688) by and large obviate the need for it.

[satk0]

Amalgamated builds would be crazy good idea in my opinion. Last time I tried to dig into quickjs.c code Neovim was heavily lagging

[chqrlie]

Amalgamated builds would be crazy good idea in my opinion. Last time I tried to dig into quickjs.c code Neovim was heavily lagging

I am not sure we are on the same page: an amalgamated build for quickjs would mean collecting all files that currently get linked into the library into a single file, preferably using a script. This would facilitate the inclusion of quickjs into other projects, regardless of the build system used.

Splitting quickjs.c into smaller modules is a different topic, which is not currently planned. Given the power and memory available on current PCs and laptops, editing this file should not cause so much lagging. It does not on my system using qemacs, where load time with complete colorization from shell prompt takes less than 70 ms.

[satk0]

OOh yeah we are not, thanks for explaining it to me 😅
Btw, going off-topic, how can you achieve maintaining split file and then somehow merging it into one file? Is there any terminology behind it?

[chqrlie]

How can you achieve maintaining split file and then somehow merging it into one file? Is there any terminology behind it?

Say you have a bunch of files you link into a library with a number of public APIs.
You want to create a single file by concatenating all these source files, starting with the private headers, removing the redundant #include lines and making all internal symbols static. This can be achieved with a simple tool or a manual operation. APIs entry points are already flagged as JS_EXTERN, so it would be easy to flag as static all the other symbols not already declared / defined as static.

[chqrlie]

How can you achieve maintaining split file and then somehow merging it into one file? Is there any terminology behind it?

Say you have a bunch of files you link into a library with a number of public APIs. You want to create a single file by concatenating all these source files, starting with the private headers, removing the redundant #include lines and making all internal symbols static. This can be achieved with a simple tool or a manual operation. APIs entry points are already flagged as JS_EXTERN, so it would be easy to flag as static all the other symbols not already declared / defined as static.
We don't have a tool like this in the project, but it is easy to write and does not require a full parser of the C language.

[satk0]

Oh thanks a ton, how could you call such an operation, file concating or smth? I'm asking this cuz I'd like to search for such a library on github hah

[saghul]

It's usually called "amalgamation". The first project that comes to mind that uses it is SQLite.

[satk0]

Ooh, allright, thanks.

Just a small update: we managed to add meson.build through patch_directory in r2. So there is no need for qjs to have meson.build file as anyone can create it on their own and get it working thanks to patches ;)

[saghul]

Good to hear! Is it ok to close this now?

[satk0]

Sure, sorry for the chaos, I am just not so experienced in meson hah

[saghul]

No worries!

[trim21]

I think we can have one in wrapdb？

[KaruroChori]

In theory yes, but I have my hands full with tinycc at the moment :D.
I might submit a patch to wrapdb for qjs at some point :).
Unless someone else wants to do that.

[trim21]

thanks. there is a old PR for origial quick-js and doesn't get merged yet, maybe helpful

mesonbuild/wrapdb#1661

[trim21]

In theory yes, but I have my hands full with tinycc at the moment :D. I might submit a patch to wrapdb for qjs at some point :). Unless someone else wants to do that.

I send a partial patch at mesonbuild/wrapdb#1865