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.
ExampleProjectis a great start for quickly building an app that depends on libraries. It works well with anyocamlfindlibraries that are ported tonpmpackages. But the first question someone asks is: "Now, that I wrote some library code in myExampleProjectfork, 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
ExampleProjectgenerate ocamlfindMETAfiles, etc then this accomplishes our goal of makingExampleProjecta library that you can publish onnpmand then depend on.For this issue, I propose that we explore using the build system called
solvuu-build, which is like a slimmed downocamlbuild/rebuildthat comes with rules to generate that ocamlfindMETAfile and.merlin. We userebuildforExampleProjectwhich is also a customized version ofocamlbuild(customized by us) so it could be quite easy to portExampleProjectover tosolvuu-build.Basic steps to get started:
solvuu-buildand 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 autogeneratedMETAfile (that was auto-generated bysolvuu-build) to install into our npm sandbox automatically. If you prefix the build command witheval $(dependencyEnv) && nopamthen runningocamlfind installshould "just work" because thenopamcommand prepares a place for any package to install theirocamlfindpackage..re-pp refmtflags required forreasonfiles. 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 refmtin the implementation ofrebuildin the reason repo. Could just copy/paste them perhaps? It might even have a built in way to register extensions like.reso 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
pjcin parallel. Oncepjcis done you could still use this build system in your projects and,pjcwill work well with it becausepjcworks with any build system that plays well withocamlfind.pjcis a workflow for building many interdependent packages/libraries that all need to know about each other. Thissolvuu-buildbuild system is just one build system among many other cooperating viapjc. One good thing is we don't needpjcto be done to usesolvuu-buildin the example project.If it turns out
solvuu-builddoesn't work out, that's fine too, but we should create some basic way to turnExampleProjectinto an ocamlfind library.