advice: split the huge quickjs.c into small pieces.

[fatfatson]

Since the goal is to rewrite it and we don't plan to merge it directly with the upstream, can we split the large file quickjs. c into smaller files for easy reading and writing by module?

[saghul]

We discussed this already and landed on the no.

Now, since we added the amalgamated build the "integration is easy, just a bunch of files" argument no longer applies.

As for merging, yes, it doesn't seem to be happening but who knows what the future may hold.

Initially I really wanted to do it, but I personally ended up being comfortable with the status quo.

Thoughts, @bnoordhuis ?

[fatfatson]

I have been using quickjs for several years. The biggest problem is that it is very inconvenient to modify and debug this large file. In vscode, even typing and editing are very difficult, and single step debugging is also very difficult. From the perspective of releasing an easy-to-use version, it is possible to write a script to automatically concatenate them, but as source code, it is still better to divide them into modules. If this project can be modified in this way, I would like to switch to using it and gradually submit some that I think are beneficial

[chqrlie]

Splitting the file into smaller fragments is feasible but the main issue would be to determine the set of internal functions that need to be public for separate compilation.

If we still compile the large quickjs.c module as a single unit, by #including the fragments, this issue would not need to be solved, but the benefits from smaller files for reading, merging, debugging etc. would still be achieved.

[bnoordhuis]

I like the one-big-file approach (works fine in vim and gdb) but I don't strenuously object to breaking it up. Charlie's suggestion sounds the most workable.