Open cknitt opened 3 weeks ago
I think the resulting standard library packages could then even be published as separate npm packages (see #6183) independent of a v12 compiler release. They could be used/tested in any ReScript project that sets the -nostdlib
compiler option and adds them as dependencies.
@zth @cristianoc @jfrolich @rolandpeelen what do you think?
I think it's probably easier to get everything compiled the same way using rewatch in the compiler repo, and refactor from there. This allows us to have the two options side-by-side. Feels like the above approach takes too many steps at once. Sorry I didn't get to finalizing the PR where we compile the stdlib with rewatch but I don't have the impression that it's hard. We just have to determine if we keep the cyclic deps, or refactor them out, we went for the last and that seemed to work. Just need to spend some time to make sure everything is properly compiling.
I think the stdlib mini would be pretty nice to have, as it isolates all the special cases. If I understand correctly, everything else can be built user-level on top of it without tricks/surprises. So it seems doable and independent from the details of the other steps.
Feels like the above approach takes too many steps at once.
Thanks for the feedback. My feeling was the opposite, that doing it in the compiler would mean taking too many steps at once. IMHO it is hard to refactor all this until it has the proper structure while still keeping the old build process working. (Unless we copy everything to a new dir in the compiler repo, but then we may as well put it into a separate repo temporarily to be able to iterate quickly, like we did for Core itself.)
I think the stdlib mini would be pretty nice to have, as it isolates all the special cases. If I understand correctly, everything else can be built user-level on top of it without tricks/surprises. So it seems doable and independent from the details of the other steps.
Definitely! Everything can be built from scratch in user level, starting with the stdlib mini. (Even with bsb, and even with the v11 compiler with -nostdlib
). I'll put up a repo tomorrow with what I have now (basically step 1-4).
Ok, so here is my repo: https://github.com/cknitt/rescript-stdlib
It uses compiler v11.1.3-rc.1 with -nostdlib -nopervasives
. This ensures that everything is indeed built from scratch.
You can clone it and run npx rewatch
to build with rewatch, or npx rescript
to build with bsb.
It will then build in one go:
Js
, too)This is based on #6772, but further modified to get it to build in this setup.
Next up would be adding Core.
Moved my repo to https://github.com/rescript-lang/experimental-rescript-stdlib-build
I have also added Core in the meantime and adapted it a bit to fit into the structure.
Some questions:
runtime
(caml_*) to be present, see #6836. Therefore the question is, shouldn't the basic types and the "stdlib mini" actually be part of the runtime as caml_types
and caml_pervasives
or something like that?What do you think @cristianoc @zth?
Before integrating Core into the compiler repo, we should sort out the standard library build procedure. We should get rid of the ninja scripts and build everything with rewatch (or maybe even still bsb at first).
It turns out to be difficult to set this up because of (among other things) cyclic dependencies that need to be resolved. A lot things need to be shuffled around. It would be easier to iterate on this outside of the compiler repo IMHO.
My proposal is therefore to create a separate repo
rescript-stdlib
to work on a monorepo structure where all standard libs can be built with a single build command and without relying on any pre-existing artifacts inlib/ocaml
. For this, we do not even need the v12 compiler, it should work fine with v11, too. Thisrescript-stdlib
repo would be a temporary one, allowing us to iterate quickly on the standard library build infrastructure. Once we everything is working, it can be taken over into the compiler repo.A rough plan could look like this: