[CN] Repackage CN as separate library and executable

[samcowger]

Currently, CN is packaged as an executable (in dune terms). As far as I can tell, this makes it impossible for other OCaml packages/projects to import/rely on CN modules, because (again, as far as I can tell - my OCaml/opam/dune is rusty) projects can only depend on libraries, not executables. Assuming the choice of this shape of packaging was arbitrary, I think we ought to reorganize things such that other projects can depend on CN, and can import the bulk of CN's modules.

One approach could look something like:

• Create two new directories, backend/cn/{lib,bin}
• Move backend/cn/main.ml to backend/cn/bin
  • Create an appropriate backend/cn/bin/dune file there
• Move everything else in backend/cn (except, perhaps, manual) to backend/cn/lib
  • Revise the just-moved dune file to declare itself as a library rather than an executable
• Make a trivial backend/cn/dune file that points to the two subdirectories

Some local experimentation suggests this approach is viable. Though a directory shuffle ought to have negligible impact on CN development in general, I realize it would be a bit painful immediately, especially for anyone with unmerged CN changes lying around. How does this land with folks? Does it seem like a good idea, and/or does it seem burdensome?

[dc-mak]

Related: https://github.com/rems-project/cerberus/issues/308

[samcowger]

Related: #308

Aha - I went looking for related issues but didn't see this one, thanks for the pointer! It seems like that issue is more about repo-splitting, and that the library/executable splitting I'm proposing here would work in tandem with (at best help, at worst not harm) that effort. Does that seem right?

[dc-mak]

Correct; though I think it is unwise to parallelise major refactors and we might be able to move a little faster on this after the repo splitting.

[thatplguy]

@samcowger is building an OCaml implementation of the language server with the intention of linking against CN as a library, rather than invoking it from the command line.

@samcowger, are you blocked on this refactoring? If so, it would make sense to do this first, unless @dc-mak has already started the repo split on a branch.

[samcowger]

I've successfully implemented the lib/exe split locally, so I can probably make progress and quasi-maintain it while the repo-splitting is in progress, though if I need to rebase on changes to CN, it could be a bit finicky.

Has work on that split begun?

[dc-mak]

@kmemarian will be able to comment precisely - it’s substantially underway I believe.

I think library splitting first is also fine, but I guess I’m just slightly wary of both at the same time and then someone needing to rebase/redo all the work again so please hold fire (annoying I know, but better safe than sorry, and better smooth than rough).

[samcowger]

it’s substantially underway I believe.

In that case, no worries! I don't want to step on any toes. We can revisit this once that's done, unless this accidentally gets taken care of in the process.

[samcowger]

Just checking in - @kmemarian, how is the repo split progressing?

[dc-mak]

We've been sidelined with POPL deadline, which has now passed. We'll all be taking a few days to recover, and we can give an update then.

[dc-mak]

Hi @samcowger , we discussed and we think the repo split/refactor will take some time yet and the changes to backend/cn should be small, so we should proceed with this now. Sorry for the double delay (in getting back, and in holding this up), and thank you for the suggestion and work.

[samcowger]

Alrighty, thanks! I'll put together a PR, and we can figure out how best to merge it without too much disruption.