I'm keeping up with the learning process. I've got to digest a lot
of things, before being able to carry on with my task. This requires
me some extra effort, because I find it hard to apply my usual
hands-on approach. If anything, I was able to sleep a little better
the last two nights. I don't even know if it makes sense, since
our son insists in waking up at 4 AM.
With half a working brain, I managed to absorb some of the Yocto
documentation, and to find the strength of overlooking the
(unreasonably?) complex build system.
Besides Yocto, I have to wrap my head around the effective project,
which is basically the software side of an embedded system. This
gives me the opportunity of learning how Git Submodules work.
Yocto works as a composition of losely dependent layers, whose
configurations are tracked on various repositories. My colleagues
organised the global project by means of git submodules. I don't
know how standard this approach is, but I find it reasonable. I
consider myself a decent git user, but I always neglected the
submodules support.
After some bad job experiences, at my very first job position, back
in 2013, I always had a bias against submodules. Maybe things are
better nowadays? The gitsubmodules(7) man pages mention that the
implementation changed over time. For the record, I've had bad
experiences with the monorepo approach too, just a few of years
later. I guess both approaches has pros and cons. None of them
prevent you from turning your master-project a utter crap, of course.
Now that I visit submodules again, I find the idea appealing, at
least for the use case I'm looking at.
