build system causing waaaay too many rebuilds #2252
Comments
it would be possible to do the substitutions as a dependency (or part) of the respective packaging targets - the package definition files need only one or two substitutions each, so it isn't particularly bothersome. definitely better than re-running configure each time ... |
It's also used in contrib/dist/redhat/mc.spec.in, so it might be not so trivial. |
it's just one file more, so why would it matter?
i already thought about the hardcoded version hack as well, but it's rather annoying to use (for one, activating it already requires a recompile). |
|
|
Closed as duplicate of #4125.
fun fact: i initially hacked up a patch that implemented exactly what i described here. then i thought again, and did something different which is more effective and a smaller diff.
the new ticket has a patch and a description that matches it, so closing the old one. |
|
|
Branch: 2252_rebuild |
that's a lot better, and probably a reasonable default behavior, but still kinda annoying when doing active development or "archaeology". i'll keep applying my patch on top of this.
btw, the commit message of the first commit in the series is kinda weird, as it makes the commits formally non-atomic. the explanation should be in the "juicy" 2nd commit, while the first one can say something trivial like "rename ..., as it won't be handled according to normal autoconf rules soon" or some such. |
Branch is repushed. |
|
|
Important
This issue was migrated from Trac:
ossi(@ossilator)mooffie@….com(@mooffie)the build system puts the git version into config.h, which basically means that each git operation which modifies HEAD will cause a full rebuild. this is highly annoying, in particular during bisecting.
i suggest throwing VERSION out of config.h and having the relevant files include version.h directly. that would also have the advantage of removing the version.h parsing from the configure script.
The text was updated successfully, but these errors were encountered: