ExampleProject is a great start for quickly building an app that depends on libraries. It works well with any ocamlfind libraries that are ported to npm packages. But the first question someone asks is: "Now, that I wrote some library code in my ExampleProject fork, I want to share it and turn it into its own package that people can depend on".
background: Ocamlfind is the currently standard "build system interop" which means that if you use the ocamlfind convention, anyone can use your library easily. So if we make ExampleProject generate ocamlfind META files, etc then this accomplishes our goal of making ExampleProject a library that you can publish on npm and then depend on.
For this issue, I propose that we explore using the build system called solvuu-build, which is like a slimmed down ocamlbuild/rebuild that comes with rules to generate that ocamlfind META file and .merlin. We use rebuild for ExampleProject which is also a customized version of ocamlbuild (customized by us) so it could be quite easy to port ExampleProject over to solvuu-build.
Basic steps to get started:
Try out solvuu-build and see if it's really easy to make a library with three or four files. (The goal is just dirt simple, sharable, small projects).
Make it build ExampleProject . If #1 was easy, then it should be very easy to make it work on ExampleProject.
Then enhance ExampleProject's package.json so that the postinstall script doesn't just build, but also does ocamlfind install, which would use the autogenerated META file (that was auto-generated by solvuu-build) to install into our npm sandbox automatically. If you prefix the build command with eval $(dependencyEnv) && nopam then running ocamlfind install should "just work" because the nopam command prepares a place for any package to install their ocamlfind package.
This build system is a stripped down ocamlbuild with nice rules baked in. We can add our own rules if needed but hopefully we won't need to add too many.
-It will need to be taught about .re-pp refmt flags required for reason files. You could add a rule to make it happen. OCamlbuild rules are hard to figure out, but we already have the rules for .re->-pp refmt in the implementation of rebuild in the reason repo. Could just copy/paste them perhaps? It might even have a built in way to register extensions like .re so that it calls refmt, without having to use custom rules. I haven't looked.
If we can get a good story for making/sharing libraries easily, we can be working on pjc in parallel. Once pjc is done you could still use this build system in your projects and, pjc will work well with it because pjc works with any build system that plays well with ocamlfind.
pjc is a workflow for building many interdependent packages/libraries that all need to know about each other. This solvuu-build build system is just one build system among many other cooperating via pjc. One good thing is we don't need pjc to be done to use solvuu-buildin the example project.
If it turns out solvuu-build doesn't work out, that's fine too, but we should create some basic way to turn ExampleProject into an ocamlfind library.
ExampleProject
is a great start for quickly building an app that depends on libraries. It works well with anyocamlfind
libraries that are ported tonpm
packages. But the first question someone asks is: "Now, that I wrote some library code in myExampleProject
fork, I want to share it and turn it into its own package that people can depend on".background: Ocamlfind is the currently standard "build system interop" which means that if you use the ocamlfind convention, anyone can use your library easily. So if we make
ExampleProject
generate ocamlfindMETA
files, etc then this accomplishes our goal of makingExampleProject
a library that you can publish onnpm
and then depend on.For this issue, I propose that we explore using the build system called
solvuu-build
, which is like a slimmed downocamlbuild/rebuild
that comes with rules to generate that ocamlfindMETA
file and.merlin
. We userebuild
forExampleProject
which is also a customized version ofocamlbuild
(customized by us) so it could be quite easy to portExampleProject
over tosolvuu-build
.Basic steps to get started:
solvuu-build
and see if it's really easy to make a library with three or four files. (The goal is just dirt simple, sharable, small projects).ocamlfind install
, which would use the autogeneratedMETA
file (that was auto-generated bysolvuu-build
) to install into our npm sandbox automatically. If you prefix the build command witheval $(dependencyEnv) && nopam
then runningocamlfind install
should "just work" because thenopam
command prepares a place for any package to install theirocamlfind
package..re
-pp refmt
flags required forreason
files. You could add a rule to make it happen. OCamlbuild rules are hard to figure out, but we already have the rules for.re
->-pp refmt
in the implementation ofrebuild
in the reason repo. Could just copy/paste them perhaps? It might even have a built in way to register extensions like.re
so that it callsrefmt
, without having to use custom rules. I haven't looked.If we can get a good story for making/sharing libraries easily, we can be working on
pjc
in parallel. Oncepjc
is done you could still use this build system in your projects and,pjc
will work well with it becausepjc
works with any build system that plays well withocamlfind
.pjc
is a workflow for building many interdependent packages/libraries that all need to know about each other. Thissolvuu-build
build system is just one build system among many other cooperating viapjc
. One good thing is we don't needpjc
to be done to usesolvuu-build
in the example project.If it turns out
solvuu-build
doesn't work out, that's fine too, but we should create some basic way to turnExampleProject
into an ocamlfind library.