Junio C Hamano venit, vidit, dixit 09.09.2008 17:13:
quoted text
> Michael J Gruber <michaeljgruber+gmane@fastmail.fm> 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.

quoted text
> 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.

quoted text
> 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
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/