Ah yes i totally forgot to mention it. Indeed the build works, but if you "make clean" then it can't rebuild the dat. I didn't get it was a dependency cycle tho.
Would a compiler switch like "INCLUDE_ROMS" work? It could be set to true for tic80studio and false for prj2cart. Something like this:

static const u8 JsDemoRom[] =
{
#ifdef INCLUDE_ROMS
#include "../build/assets/jsdemo.tic.dat"
#endif
};

But perhaps the tic80core target is built just once per run? not sure how the build process work in that regard.
I don't think it can be refactored out either, becouse prj2cart depend right on tic_script_config, so the cycle is real. Or we need to define a different target to build a subset of tic80core without the roms, to be used by prj2cart.

Otherwise the roms needs to be put back in tic80studio. i don't think it can be made completely dynamic tho.
Let me know :)

Hard to say, on the one hand, we want to keep all the language-related things in one place, in another hand tic80core doesn't need to know anything about demo carts and marks, it's only the console related thing.
Maybe we could add INCLUDE_ROMS definition for the whole demo code

#ifdef INCLUDE_ROMS
static const u8 JsDemoRom[] =
{
#include "../build/assets/jsdemo.tic.dat"
};
#else
// lang implementation
#endif

and then include the file in the console.c

#define INCLUDE_ROMS
#include "api/js.c"

This could partly solve the issue.

Uhm so basically js.c would be two different files: when included by the full version it will be only the demos? It's a bit forced but could work. Problem is, you still need to wire JsDemoRom somewhere, statically. So that means switches and macros in some places.
I don't know, i feel like if we miss the objective of centralizing language related stuff on a single place then the whole thing kind of lose meaning. I mean, the for loop on Languages is certainly more readable than the SCRIPT_LIST kung fu, and that would stay, but..

What about this: we remove cart related stuff from tic_script_config, and create a new file with an new type tic_script_config_extra (or something). Here we put the demos etc. Then we create an array of tic_script_config_extra that parallels Languages, perhaps LanguagesExtra. This new stuff would be included only in studio, resolving the cycle. We end up with two places to define stuff instead of one, but they'll be pretty "parallel" so to speak. And a simple function could look up the right tic_script_config_extra from a tic_script_config to keep things dynamic.

If you like i can give it a try.

Ps if you feel like we're going in the wrong direction and want to throw this away just let me know, i'll understand :)

What about this: we remove cart related stuff from tic_script_config, and create a new file with an new type tic_script_config_extra (or something). Here we put the demos etc. Then we create an array of tic_script_config_extra that parallels Languages, perhaps LanguagesExtra. This new stuff would be included only in studio, resolving the cycle. We end up with two places to define stuff instead of one, but they'll be pretty "parallel" so to speak. And a simple function could look up the right tic_script_config_extra from a tic_script_config to keep things dynamic.

Sounds good, I like it, demo things will link to the studio and we keep the core clean without unnecessary dependencies.
Thank you

Should be ok now. New files are demos.h and demos.c, both under "studio". demos.c contains demos for all languages, it's just mechanical definitions, i don't think there's need to have a different file per language. Perhaps even proper demos (like fire, 3d etc, could be moved there).

i've also committed the modification i mentioned earlier since i was already working on it: the vm pointers at tic_core are now unified, instead of a pointer per language, there are two fields: an opaque pointer (currentVM) and a tic_script_config* (currentScript) that record the information about which language the current vm belongs to, so we can close it. The opening and closing logic has been updated accordingly. This way tic_core doesn't know anything about the current language and is completely dynamic. (also it now never keeps more than one VM open at a time, previously it could have up to one VM per language open at the same time).

oh man i even checked multiple times that i removed all printf 🤦
fixed the crash too, i forgot the poor Javascript.