Closed Thaodan closed 2 months ago
IMO it makes sense to always tangle, even when it appears that doing so is probably unnecessary based on modification times. All the other targets do that, so it should be done here too.
This may seem like waste, but I have wasted so much time helping users with issues they encounter with my popular packages because their preferred package manager leaks old versions of installed packages into new byte-code, that I consider it highly efficient in comparison, that my own package manager tries very hard to prevent that.
Jonas Bernoulli @.***> writes:
IMO it makes sense to always tangle, even when it appears that doing so is probably unnecessary based on modification times. All the other targets do that, so it should be done here too.
OK that explains why it run even when I already ran it using my git pre-push hook to prevent pushing a broken init.el.
This may seem like waste, but I have wasted so much time helping users with issues they encounter with my popular packages because their preferred package manager leaks old versions of installed packages into new byte-code, that I consider it highly efficient in comparison, that my own package manager tries very hard to prevent that.
I know what you mean it can been very frustrating and time wasting to deal with these kind of issues. Especially when the issue is somewhere else and the resulting discussions with the other developers.
Partially revert 2628c68fa91c35ce7b9cfb1e637fd397dda6621f and add optional dependency for init-build to init.el
Like #162 but better.