Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > Briefly: The entire reason I changed those bits is exactly to avoid the > sort of CI lock-in you're talking about, to th point where this series > effectively adds another CI target: You can run everything it's doing > with a normal "make" invocation. I'll comment only on this part. FWIW, the above matches my impression fromt he base part of the rewrite. As long as a particular CI integration runs shell scriptlets that invoke "make", moving the code that is shared common among CI platforms from the shell scriptlets to the recipe in Makefile should not make it harder to support it, and ... >> A better approach would be to use the already-generic code and adapt it >> e.g. to extend to the CirrusCI definition we have. > > This series doesn't change .cirrus.yml or how it functions, but it just > does: > > build_script: > - su git -c gmake > test_script: > - su git -c 'gmake test' > > Which, after this series is exactly what your "main" CI does. So we're > set up to make it easier to unify the two. ... BSDs or any POSIXy system I would expect to fall into the same "shell scriptlets eventually driving make" pattern. The same argument may not apply if another CI platform uses shell scriptlets but does not want to use "make" at all. The "do more in 'make'" movement could be hurting such a user. I do not know if Windows' preference to use cmake plays a role there, or if Dscho's resistance comes from there, though. > Anyway, I really hope we can find some way past what seems to be an > impasse with these various CI changes. All the best. Yup. Thanks.
