Junio C Hamano venit, vidit, dixit 09.09.2008 17:13:
> Michael J Gruber <michaeljgruber+gmane@xxxxxxxxxxx> writes:
>
>> I would go about renaming quick-install-doc to quick-install-man, introducing quick-install-html doing the analogous using the "html" branch and quick-install-doc doing both, which would be more in line with the install-doc target.
>>
>> Are there any objections to renaming quick-install-doc to quick-install-man?
>
> What does it improve?
It makes it more systematic.
Right now:
Documentation/Makefile:
all: builds html and man
install: installs only man (depends on man)
install-{info,html}: installs $foo (depends on $foo)
quick-install: installs man from man branch
Makefile:
doc: builds html and man (-C D all)
install-doc: installs only man (-C D install)
install-{info,html}: installs $foo (-C D install-$foo)
quick-install-doc: installs man from man branch (-C D install-$foo)
So there is a distinct asymmetry between build targets and install
targets. Wouldn't you expect "make install" to install what "make"
builds? That is true, but "make install-doc" doesn't install what "make
doc" builds.
Put it differently:
doc = man + html for build targets
doc = man for install targets
What's worse: "make doc" fails if you don't have xmlto, even though
"make install-doc" may succeed; but you'll never try it when the build
fails. Until a few hours ago I thought I couldn't build man pages at
work (asciidoc, but no xmlto), and I had never heard about
quick-install-doc until I looked at the Makefiles in detail.
> IOW, can't you do what you want to do (I am assuming that what you want to
> do is to be able to copy out the pregenerated contents from convenience
> branches) without such a rename?
Sure I can. "Namen sind Schall und Rauch". Names don't matter.
quick-install-html would follow the above logic. I just think that the
doc logic is flawed.
So, my suggestion is that doc = man + html, whether it appears in a
build target or an install target.
> If you rename the target, I am reasonably sure you would break somebody's
> build procedure. It is a separate topic if there are large number of such
> somebody, or just a limited few.
I keep hearing this argument, and I'm even more surprised to hear it
right after a major release. If not now then when's a good time for
cleaning up confusing inconsistencies?
Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
