On 29/07/16 15:46, Ian Eyberg wrote:
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 don't think I expressed myself clearly. Let's imagine three target
configurations which contain various packages: C1 = {a,b}, C2 = {b,c}
and C3 = {d}. I meant we'd require you to build a+c+d once and b twice.
e, f, ... would not be built for C1+C2+C3. So, in essence, caching b
between C1 and C2 would not be supported, for the purposes of
simplifying the infra.
I think in general though there is plenty of room for someone interested
to improve the workflows.
Yes, but those improvements need to start from something concrete, not
references to google and infiniband. Also, at least in the context of
this list and the open source community, those improvements need to be
general enough to be useful to the public, yet specific enough to
actually work. A full stack system is complex enough that eventually
maintenance trumps everything else (already now, even if you don't see it).
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.
I'd imagine (though I didn't check) that on a general purpose system the
interpreters would use dlopen in such cases as opposed to having to
hardcode the configuration at link-time.
Regardless, it's not relevant for the Rumprun scenario, because *every*
build is a "special case". You're building your system to do only one
thing, not for, to use your term, a hodgepodge of general purpose cases.
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.
Well, regardless of what you see it as, I see that it has to be
*useful*. Examples/prototypes of cases which are not useful in the
context of Rumprun would make the packages repo rather pointless.
