https://open-source-silicon.dev logo
Join Slack
Powered by
<@U016G1URZGA>: I'm using docker version 19.03.12...
# openlane
t
@User: I'm using docker version 19.03.12. But the segfault is happening in the Centos6 container, right? Isn't docker supposed to be preventing those kind of issues, not creating them?
a
when the abstraction you put in place to help you ends up hindering you...
m
Hindering you for now but the real hindering if we ignore "packaged and tested" bundle and later have a silicon issue because people used whatever revisions they got from the last of abstraction. If docker in not the best - maybe we do it another way. Thoughts? Maybe a solid Makefile that does everything natively but tested on centos Debian Ubuntu macos or others?
a
hmm, maybe to some extent
you pose a very interesting configuration management question
the short TL:DR is that I am not sure if docker is or is not the best
we could start with gathering a couple of requirements/use cases of people and go from there
in my personal opinion I am a big fan of lightweight solutions and not reinventing the wheel if we don't specifically have good reasons for that
from just reviewing a bit this SW part of openlane and seeing people try to use it
I would say we are looking at two things which we might want to think if we want to have combined or not
basically at this point the "docker" abstraction mixes two things
source revision control + building
basically each app is checked out to a specific rev and built in its own container and then mixed together to become the "openlane" package
which is nice to some extent but it does come with some downsides as well
now one very interesting requirement which is not clear me: is what would you like openlane to be tested and distributed as
do we lean more to the ship a set well defined set of revisions for some tools that people then build themselves
or is more of we also want to provide a well tested framework for them to actually build the binaries in a specific way
basically I am saying that the problem of check a bunch of source code out to a specific know set of revisions and combine them to a specific path+tree structure has been solved
and there are tools we could apply for this (we don't need a new wheel)
the topic of building something multiplatform (Linux+MacOS+ maybe Windows under WSL or natively) is still a bit of a struggle
that is why I would lean towards splitting the two things
as for the Makefile or docker for the actual building in a "known" stable environment
that really depends on the use cases
for example at least in my past experience today we could make python a core requirement
without anyone objecting to that (and openlane also uses it)
such a core requirement simplifies the MacOS path a bit
Open in Slack
PreviousNext
Powered by