[libre-riscv-dev] experimental code & monorepo

[Jacob Lifshay]

On Sun, May 3, 2020 at 4:03 AM Luke Kenneth Casson Leighton
<lkcl at lkcl.net> wrote:
>
> On Sun, May 3, 2020 at 5:49 AM Jacob Lifshay <programmerjake at gmail.com> wrote:
> >
> > Additionally, I'd advocate for all HDL code (at least soc, ieee754fpu, and
> > nmutil) to be moved to one repo
>
> > and using submodules for often updated external dependencies (nmigen at
> > least),
>
> the experience we've had - already - of using submodules is a royal
> pain in the neck.  commits which involve changing of files *and*
> changing submodules do *not* merge properly, and i actually had to use
> rebase --skip for the first time - ever - in order to recover the
> repository.  this lost some work by michael.

One potential workaround would be to have a server-side git hook that
rejects commits that have changes to a submodule and other files
(other than .gitmodules) in the same commit.

> i'm inclined to suggest (as we discussed on the coriolis2 bug,
> briefly) that an *independent* top-level repo be created that "joins"
> *all* source code - and tools - together.  this to *never*, under any
> circumstances, have actual files added to it (with the exception of a
> README, saying "please read documentation at location X and please do
> not edit this file further").

That could work, but would be difficult to use when developing code.

> > since that helps tie all the code together so one commit id is
> > sufficient to describe the state of all the code that's tightly
> > interconnected. See LLVM switching to a monorepo for an example of how this
> > is a good idea.
>
> if the IEEE754 FP code had not been designed - from the start - to be
> a general-purpose independent library and toolkit, i would agree
> immediately with that.
>
> however it was never intended - ever - right from the start - to be a
> specific hard-coded isolated our-use-only FP library.
>
> <snip>
>
> all three are therefore actually independent projects.  putting their
> source into a single repository has detrimental implications.  it also
> results in confusion about what the roles of each of those three
> independent projects is.

That's seems to work out just fine and even be outright beneficial for
LLVM, where they have many loosely associated libraries/programs all
in the same git repo.

A short list of projects that are mostly unrelated to each other but
are still in the LLVM monorepo:

clangd: a LSP server for adding C++ language support to IDEs
lldb: a interactive debugger
flang: a FORTRAN frontend for LLVM
libc: a WIP C standard library
mlir: a IR originally designed for machine learning, but is now quite
a bit more generic
yaml2obj: a program that converts a YAML description of an object file
to the binary form

Basically all of them can (and are) used nearly independently of the rest.

As long as we state so in all the readmes and other docs, it should be
pretty unambiguous that ieee754fpu can be used independently of most
of the rest of our code. We could even provide a read-only git repo
that mirrors the ieee754fpu directory.

Jacob