[RFC] Resolve Circular Dependency Problem on Wren CLI building
clsource opened this issue · 3 comments
In the #80 conversation, it was noted that if in the future we would want to replace python
with wren
files for building wren_cli
, it would be needed to compile a wren_cli
before compiling the final version. Hence creating a need for having a wren_cli
before having a wren_cli
.
One possibility for solving this is using a cached versions of the wren_cli modules. That way a transitional wren_cli can be built only for executing the future wren scripts needed for compilation:
util
├── generate_projects.wren
├── metrics.wren
├── test.wren
└── wren_to_c_string.wren
cached modules can be called inside modules.c
with a compiler flag.
// modules.c
#ifdef USE_MODULES_CACHE
#include "modules_cache.h"
#else
#include "io.wren.inc"
#include "os.wren.inc"
#include "repl.wren.inc"
#include "scheduler.wren.inc"
#include "timer.wren.inc"
#endif
A possible value for modules_cache.h
From the original thread:
Ruby: It's not solving any particular problem that has impact while working on the cli, and is unnecessary complexity at this time. (not referring the to new line fix).
I think "at this time" can be read optimistically as "it might be nice to have one day, but it doesn't really help us out right now"... and [a bit] sadly I think I agree. I feel like someone would have to show that Python3 is a truly onerous requirement to get any traction on this (in the immediate future).
Worth noting I do play to do this in my own wren-essentials
project, replace the scripts with Wren as possible - though it's not a high priority.
Ok.
I'm closing this. Maybe in the future it can be reopened when python
can be replaced with wren
scripts (if wanted)
👍