On Fri, May 24, 2013 at 11:40:07AM +0200, Petr Baudis wrote: > On Fri, May 24, 2013 at 09:22:53AM +0100, John Keeping wrote: > > On Fri, May 24, 2013 at 01:57:12AM +0200, Petr Baudis wrote: > > > Just to clear up on what the best practice is, I'd imagine the setup > > > to be something like: > > > > > > (a) Makefile contains inclusion of Makefile.include. > > > > > > (b) There is a file like Makefile.include.template containing > > > a template to be copied over and filled by the user. > > > > > > (c) Makefile contains code that makes sure all variables that > > > are supposed to be set are set and obsolete variables are not, > > > since there is no mechanism to cause e.g. a merge conflict > > > on change of Makefile.include.template. > > > > > > Is there a better way to solve this? > > > > I think the best practice would be what Git itself does ;-) > > > > The Makefile sets default values for all parameters, some of which are > > inferred based on the system. It then includes config.mak, which allows > > the user to override any of these values. > > So that's pretty similar to what I described, modulo the filenames. > I'd say it's more friendly if you don't need to tweak any of the > defaults in the common case, but less friendly if you always need to > tweak something/everything (you really want a template file then > and not covering (c) is a problem).
I don't see anything wrong with having a template file documenting the parameters, but I think it's important that there are sensible defaults in place when the user's configuration file does not specify a value for a parameter. It wasn't clear to me from your definition that there were defaults to be overridden by the user's configuration file, as opposed to forcing the user to define certain values and causing an error if those are not defined. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
