Am Samstag, den 08.02.2020, 13:51 +0100 schrieb David Kastrup: > Jonas Hahnfeld via Discussions on LilyPond development > < > lilypond-devel@gnu.org > > writes: > > > Am Freitag, den 07.02.2020, 13:21 +0100 schrieb Han-Wen Nienhuys: > > > Considerations > > > ============== > > > > > > * Because the build happens inside a container, we can test multiple > > > builds. We could build against guile 1.8 and 2.2 at the same time, > > > for example > > > > I don't agree that we need containers for this, you can easily set > > environment variables to make configure pick up the version you want to > > use. > > I use stuff like > > ./configure GUILE_CONFIG=/usr/local/tmp/guile-1.8/bin/guile-config > GUILE=/usr/bin/guile > > all the time.
Exactly. > > > * Because the "build binary" step reuses CCache results, it can > > > complete quickly. > > > > Maybe I don't fully understand the proposal, but: > > * if we only build the release image for every "official" tag, it will > > not provide quicker builds - especially towards the end of a cycle when > > many changes have accumulated. > > * if instead we build images for every commit, then incremental > > building of a provided patch will be fast(er) (_if_ it doesn't touch > > any header file). But what's then the point of using ccache, we can > > just trigger a full build? > > Full builds are slower. True, but my point is that it doesn't matter: You have to do a full build to populate ccache; or you just build with the changes already applied, what's the difference? Jonas > But I really don't trust our dependencies all > too much, and for example Clang builds don't get a working set of > dependencies anyway (which is sort of curious since it is the modular > Clang that should be able to parse for them easily).
signature.asc
Description: This is a digitally signed message part
