1) We have 2 builds of Go (1.5) and (1.7) on gorump. Building either
of
them takes a long time to do. Then you have to run your 'tests'. Keeping
these separate allows one to iterate faster and not have to wait on
other packages. One of the reasons we kept the go stuff separate is
because I didn't want to be bound by build/test times from outside code.
What does "separate" mean? separate between 1.5 and 1.7? separate
from other packages? Either way, I don't see why you'd be bound by
"outside" code that you're not going to build or use.
Separate from everything. :)
Separate from other languages. Separate from other libraries. Separate
from each language version. The mono-repo might work well for google but
unfortunately not everyone has 30k engineers, an entire build tools team
nor inifinband everywhere. The build process is very bound. A large
majority of shops won't push code to production unless 'tests are
passing' - that implies that builds are complete. While we're nowhere
near that goal and have little to no tests in the code the dependency
chain *does*. Waiting a hour for something like rust to build is a
non-starter. Similarily if there were tests for the modifications made
to other places that would lengthen the time as one has to (should) in
many cases install/boot up the hypervisor to run their tests
effectively.
For example - as a POC I recently added a 'test' to ensure GC was being
ran in Go. I wouldn't want anyone to have to wait for that to build/test
who was not interested in Go.
I don't know if the case is to ensure that changes to rumpkernel/rumprun
don't dramatically negatively affect rumpkernel/rumprun-packages or
whether it's more for workflow reasons. I think those are probably two
different discussions with different goals/solutions.
I think in general though there is plenty of room for someone interested
to improve the workflows.
2) All of the interpreted languages require a hodepodge of various
libraries to link against and so it's never going to be the case outside
of hello world examples that you wouldn't have completely different
builds for them.
Why do you specifically pick out interpreted languages? All code ever
links against various libraries depending on what the code wants to
accomplish.
While this is true, I single out the interpreted stuff more simply
because those are the ones, that in the past, most of their practioners
would not be manually linking against the language interpreter itself,
(apt-get install php, ruby, python, etc.) vs the compiled ones where
it's already part of their workflow.
Things like libxslt/libxml get linked into virtually every interpreted
language out there. What happens when you want to add rmagick to ruby?
Or perhaps you need to link in libjpeg because every blog requires that.
You have to make a special case.
This is one of the reasons why I'm not proposing any changes to the
packages repo as I see it as a set of examples - not something I would
design a repeatable build process around.
