A welded source tree stored in a single monolithic git repo has a major sanity/usability problem.
When you update your source tree (by pull/merge/whatever), how do you know what to rebuild?
Back in the day, before weld was on the scene, it was easy; muddle pull was wired in to the underlying VCS and this caused the relevant labels to be deasserted. Then you could just muddle redeploy your top-level deployment, and you're done. Easy.
When weld is in play, the muddle-VCS linkage is broken.
My known strategies to date are:
- Read the commit logs and deduce a list of packages to turn into a
muddle rebuild invocation. This depends on being able to work out the list of packages quickly, and there not being too many changes.
muddle rebuild _all. On this build tree that takes at least half an hour, even with a fully loaded ccache.
There must be a better way. Perhaps a clever git hook?
A welded source tree stored in a single monolithic git repo has a major sanity/usability problem.
When you update your source tree (by pull/merge/whatever), how do you know what to rebuild?
Back in the day, before
weldwas on the scene, it was easy;muddle pullwas wired in to the underlying VCS and this caused the relevant labels to be deasserted. Then you could justmuddle redeployyour top-level deployment, and you're done. Easy.When
weldis in play, the muddle-VCS linkage is broken.My known strategies to date are:
muddle rebuildinvocation. This depends on being able to work out the list of packages quickly, and there not being too many changes.muddle rebuild _all. On this build tree that takes at least half an hour, even with a fully loaded ccache.There must be a better way. Perhaps a clever git hook?