On 2019-07-01, David Demelier <[email protected]> wrote:
> I think the Makefile rule is redundant and keeping just the .gitignore
> could be enough. Because to me a project/code/application should not
> know which SCM it is based on. That's also why I personnally exclude
> SCMs bits from distributions files (including ignore files).
The idea with the Makefile rule is that the Makefile is the single
source of truth for the list of build artifacts that need to be
ignored. If someone removes a tool from sbase but forgets to remove
the entry from .gitignore, or adds a tool and messes up the sorting
order in .gitignore, that could easily go unnoticed for a long time.
> The Makefile rule could be a simple alias in your shell :-)
I don't think this is as simple as you make it sound, since it depends
on variables within the Makefile. My best attempt is to pipe a
Makefile fragment to make and tell it to read from multiple sources.
printf '.PHONY: .gitignore\n.gitignore:\n\t{ printf '\''*.o\\n'\'' ;
printf '\''/%%s\\n'\'' getconf.h $(LIB) $(BIN) ; } > $@\n' | make -f
Makefile -f - .gitignore
Either way, I don't think the files checked into the sbase repository
should depend on any personal scripts I have. If the maintainer
changes, I want to make sure it is clear how it was generated.
Additionally, having the rule ensures that a contributor of a new tool
can easily update .gitignore with their patch.
I appreciate your concern, but I don't think the two-line Makefile
rule at the end of the file will negatively affect anyone using or
working on sbase. It's there if you need it, but if not it can just be
ignored.
