One idea to speed up CI and developer re-builds augmented with ccache when just little parts of the NUT codebase have changed (and were committed) is to sever the dependency on NUT version string.
Currently it is set up as a macro in a generated nut_version.h file which everyone includes, so every git commit requires a rebuild of "completely" new source after C preprocessor has done its job, due to the changed header file. This needlessly slows down CI (at least, first run on a build agent done for the same PR) as well as local development builds.
This logged issue is about research into making an object file (or a *.la helper) with a NUT version string, and whatever similarly volatile data we have, so only it is rebuilt whenever git commits happen (or other circumstances for that data to change) and used in linking of end-user libraries and/or binaries. Rebuilds from C sources to object files, something ccache is good at accelerating, should then become less troublesome (same preprocessed source hash and toolkit => known object file).
NOTE: Source-wise, it only impacts a couple of files:
$ git grep -E '# *include.*nut_version.h'
common/common.c:#include "nut_version.h"
tools/nut-scanner/nut-scanner.c:#include "nut_version.h"
UPDATE: further review showed that this would mostly "jump from fire into a frying pan", with most of the work done by compiler being to re-link with a new build of libcommon*.la as relevant for this or that binary/library file. This idea might however speed up builds a little, since libcommon itself would not have to be rebuilt (and it is depended on from a number of "sub" makefiles)...
One idea to speed up CI and developer re-builds augmented with
ccachewhen just little parts of the NUT codebase have changed (and were committed) is to sever the dependency on NUT version string.Currently it is set up as a macro in a generated
nut_version.hfile which everyone includes, so every git commit requires a rebuild of "completely" new source after C preprocessor has done its job, due to the changed header file. This needlessly slows down CI (at least, first run on a build agent done for the same PR) as well as local development builds.This logged issue is about research into making an object file (or a
*.lahelper) with a NUT version string, and whatever similarly volatile data we have, so only it is rebuilt whenever git commits happen (or other circumstances for that data to change) and used in linking of end-user libraries and/or binaries. Rebuilds from C sources to object files, somethingccacheis good at accelerating, should then become less troublesome (same preprocessed source hash and toolkit => known object file).NOTE: Source-wise, it only impacts a couple of files:
UPDATE: further review showed that this would mostly "jump from fire into a frying pan", with most of the work done by compiler being to re-link with a new build of
libcommon*.laas relevant for this or that binary/library file. This idea might however speed up builds a little, since libcommon itself would not have to be rebuilt (and it is depended on from a number of "sub" makefiles)...