Am 28.07.2017 um 04:35 schrieb R0b0t1:
The earliest versions of the Rakudo Star build system started out by trying to
use Git submodules to manage packages, but it quickly proved to be unwieldy and
almost impossible to understand and maintain. Perhaps the submodule ecosystem
has changed since then, though.
Can you give an example of how submodules were insufficient?
I don't know what was unwieldy for the Perl6 guys, but having to manage
multiple repositories for a given task is always some extra steps when
synchronizing new code to the public repositories. If one of those steps
is forgotten, everybody will see repositories that won't work, or show
weird problems.
Submodules are built for the use case that repositories evolve
independently of each other, subtrees for the case that they evolve in
sync. It's possible that submodules were the wrong approach, or that
subtrees didn't work well enough at the point in time, or that nobody
found the time to set everything up well enough to make it really work,
or for lack of knowledge how to get submodules to work well.
Since everybody's time is constrained, and Perl6 is still a work in
progress, there is a long list of things that could be improved, so it's
no surprise to see defects. The more important question is whether
defects are important.
Most issues I have seen that arise with submodules come from people
trying to treat the submodule directory in a way that is different
than other objects tracked by Git. If you treat it like a source file
you're tracking most problems should disappear, at least in theory.
Dunno what the problems were for Perl6.
Versioning generated (non-source) files can indeed create problems, but
that's independently of whether it's submodule or not, so don't know
what problem you're seeing here.
There's still some unfortunate submodule command names.
git's ergonomics is generally not that good. Projects still stick with
it, I have several theories about the reasons but don't know which of
them apply.
NQP? I was told that has bytecode in it. If possible I would request
that this is changed in the future.
NQP is just the language that large parts of the Perl6 compiler are
written in.
Bytecode is what the AST is compiled to. One could write a different
backend, translating either AST or bytecode down to machine code; it's
just that nobody did it yet. It would be a pretty large project, so I
don't count on that happening anytime soon (but then the Perl community
can be pretty amazing and incredible things happen on a semi-regular
basis, so I'm not counting on that *not* happening either).
