"make install" now tries to build the documentation
Sometime since Friday, somebody (probably Peter) "fixed" things so that
"make install" at the top level of the tree insists on building the SGML
documentation first. I regard this as utterly unacceptable; if I'm just
trying to build a new test installation (which I often do multiple times
per day), I do not wish to wait around for the SGML docs to be built.
Please fix. Maybe installing the docs could be conditional on having
done "make distprep", instead?
regards, tom lane
On tis, 2009-08-18 at 11:30 -0400, Tom Lane wrote:
Sometime since Friday, somebody (probably Peter) "fixed" things so that
"make install" at the top level of the tree insists on building the SGML
documentation first. I regard this as utterly unacceptable; if I'm just
trying to build a new test installation (which I often do multiple times
per day), I do not wish to wait around for the SGML docs to be built.
Please fix. Maybe installing the docs could be conditional on having
done "make distprep", instead?
That's pretty much how it is supposed to work. I can't reproduce the
problem you are describing.
Peter Eisentraut <peter_e@gmx.net> writes:
On tis, 2009-08-18 at 11:30 -0400, Tom Lane wrote:
Sometime since Friday, somebody (probably Peter) "fixed" things so that
"make install" at the top level of the tree insists on building the SGML
documentation first. I regard this as utterly unacceptable; if I'm just
trying to build a new test installation (which I often do multiple times
per day), I do not wish to wait around for the SGML docs to be built.
Please fix. Maybe installing the docs could be conditional on having
done "make distprep", instead?
That's pretty much how it is supposed to work. I can't reproduce the
problem you are describing.
Hmm ... configure on a machine that has docbook, "make" at top level,
then "make install" at top level.
regards, tom lane
Tom Lane wrote:
Sometime since Friday, somebody (probably Peter) "fixed" things so that
"make install" at the top level of the tree insists on building the SGML
documentation first. I regard this as utterly unacceptable; if I'm just
trying to build a new test installation (which I often do multiple times
per day), I do not wish to wait around for the SGML docs to be built.
Please fix. Maybe installing the docs could be conditional on having
done "make distprep", instead?
Doesn't seem to be happening for me:
shows this at the top:
make -C doc install
make[1]: Entering directory `/home/andrew/bf/root/HEAD/pgsql.13422/doc'
make -C src install
make[2]: Entering directory `/home/andrew/bf/root/HEAD/pgsql.13422/doc/src'
make -C sgml install
make[3]: Entering directory `/home/andrew/bf/root/HEAD/pgsql.13422/doc/src/sgml'
make[3]: Nothing to be done for `install'.
make[3]: Leaving directory `/home/andrew/bf/root/HEAD/pgsql.13422/doc/src/sgml'
make[2]: Leaving directory `/home/andrew/bf/root/HEAD/pgsql.13422/doc/src'
make[1]: Leaving directory `/home/andrew/bf/root/HEAD/pgsql.13422/doc'
cheers
andrew
Andrew Dunstan <andrew@dunslane.net> writes:
Tom Lane wrote:
Please fix. Maybe installing the docs could be conditional on having
done "make distprep", instead?
Doesn't seem to be happening for me:
<http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=dungbeetle&dt=2009-08-18%20064401&stg=make-install>
It happens for me on my Fedora box, but not on my HPUX box. I suppose
that the significant difference is the HPUX box doesn't have the docbook
tools installed. If you have evidence to the contrary, maybe there's
some subtle gmake version issue here?
regards, tom lane
On tis, 2009-08-18 at 12:17 -0400, Tom Lane wrote:
Andrew Dunstan <andrew@dunslane.net> writes:
Tom Lane wrote:
Please fix. Maybe installing the docs could be conditional on having
done "make distprep", instead?Doesn't seem to be happening for me:
<http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=dungbeetle&dt=2009-08-18%20064401&stg=make-install>It happens for me on my Fedora box, but not on my HPUX box. I suppose
that the significant difference is the HPUX box doesn't have the docbook
tools installed. If you have evidence to the contrary, maybe there's
some subtle gmake version issue here?
Assuming no tool bugs, the only way I can see this happening is if you
already have built the documentation. Then, make install might cause it
to be re-built if dependencies require it.
make -n --debug -C doc install might help analyze it.
Peter Eisentraut <peter_e@gmx.net> writes:
On tis, 2009-08-18 at 12:17 -0400, Tom Lane wrote:
It happens for me on my Fedora box, but not on my HPUX box.
Assuming no tool bugs, the only way I can see this happening is if you
already have built the documentation. Then, make install might cause it
to be re-built if dependencies require it.
Um, that might be it. I did what I usually do:
make distclean
cvs update
configure ...
make
make install
but now that you mention it, I might have built the docs in that
tree yesterday, and "make distclean" no longer cleans them out.
[ checks overnight backups ... ] Yup, that's it: html/ and html-stamp
were present in doc/src/sgml/ early this morning.
I could avoid the unwanted build by changing the first step to
"make maintainer-clean", but that's not tremendously satisfactory
either, given how slow it is to regenerate the derived ecpg files.
Is it sensible to split out docs installation to a separate target
"make install-docs"? Or is there some other solution?
regards, tom lane
On 8/18/09 10:43 AM, Tom Lane wrote:
Is it sensible to split out docs installation to a separate target
"make install-docs"? Or is there some other solution?
I'd like to have this. There are times I want to *only* build the docs.
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
On tis, 2009-08-18 at 13:43 -0400, Tom Lane wrote:
Peter Eisentraut <peter_e@gmx.net> writes:
On tis, 2009-08-18 at 12:17 -0400, Tom Lane wrote:
It happens for me on my Fedora box, but not on my HPUX box.
Assuming no tool bugs, the only way I can see this happening is if you
already have built the documentation. Then, make install might cause it
to be re-built if dependencies require it.Um, that might be it. I did what I usually do:
make distclean
cvs update
configure ...
make
make install
but now that you mention it, I might have built the docs in that
tree yesterday, and "make distclean" no longer cleans them out.
[ checks overnight backups ... ] Yup, that's it: html/ and html-stamp
were present in doc/src/sgml/ early this morning.
Still, the documentation should only be rebuilt if any of its
dependencies have changed, not every time you run make or make install.
On tis, 2009-08-18 at 10:50 -0700, Josh Berkus wrote:
On 8/18/09 10:43 AM, Tom Lane wrote:
Is it sensible to split out docs installation to a separate target
"make install-docs"? Or is there some other solution?I'd like to have this. There are times I want to *only* build the docs.
make html
Has nothing to do with this, really.
Peter Eisentraut <peter_e@gmx.net> writes:
On tis, 2009-08-18 at 13:43 -0400, Tom Lane wrote:
but now that you mention it, I might have built the docs in that
tree yesterday, and "make distclean" no longer cleans them out.
[ checks overnight backups ... ] Yup, that's it: html/ and html-stamp
were present in doc/src/sgml/ early this morning.
Still, the documentation should only be rebuilt if any of its
dependencies have changed, not every time you run make or make install.
Well, Teodor's commit today did include doc updates.
I'm leaning more towards the "make install-docs" solution after further
thought. One thing that's always been a bit bogus about make install
is that it installs the docs only if they're there. With a separate
top-level target, it would be reasonable to throw an error if the
docs aren't there and can't be built.
regards, tom lane
On tis, 2009-08-18 at 14:32 -0400, Tom Lane wrote:
I'm leaning more towards the "make install-docs" solution after further
thought. One thing that's always been a bit bogus about make install
is that it installs the docs only if they're there. With a separate
top-level target, it would be reasonable to throw an error if the
docs aren't there and can't be built.
I don't think we should impose an additional burden on the users because
of some glitches in the workflow of some developers. There can be
another solution. We can add an option or a make target or whatever to
refine the behavior in a developer environment.
I'm not exactly sure what the goal is, however. You built the
documentation at some point. Then it gets updated when necessary. You
can delete the documentation by running make -C doc maintainer-clean.
Then it's gone forever and never reappears unless you explicitly build
it again.
Peter Eisentraut <peter_e@gmx.net> writes:
On tis, 2009-08-18 at 14:32 -0400, Tom Lane wrote:
I'm leaning more towards the "make install-docs" solution after further
thought. One thing that's always been a bit bogus about make install
is that it installs the docs only if they're there. With a separate
top-level target, it would be reasonable to throw an error if the
docs aren't there and can't be built.
I don't think we should impose an additional burden on the users because
of some glitches in the workflow of some developers. There can be
another solution. We can add an option or a make target or whatever to
refine the behavior in a developer environment.
Well, having "make install" behave in a history-dependent fashion is just
as much a hazard for users as it is for developers.
regards, tom lane
On tis, 2009-08-18 at 15:13 -0400, Tom Lane wrote:
Peter Eisentraut <peter_e@gmx.net> writes:
On tis, 2009-08-18 at 14:32 -0400, Tom Lane wrote:
I'm leaning more towards the "make install-docs" solution after further
thought. One thing that's always been a bit bogus about make install
is that it installs the docs only if they're there. With a separate
top-level target, it would be reasonable to throw an error if the
docs aren't there and can't be built.I don't think we should impose an additional burden on the users because
of some glitches in the workflow of some developers. There can be
another solution. We can add an option or a make target or whatever to
refine the behavior in a developer environment.Well, having "make install" behave in a history-dependent fashion is just
as much a hazard for users as it is for developers.
That's kind of a built-in feature of make. Otherwise we could write the
build rules as shell scripts. ;-)
Anyway, a simple fix that doesn't upset too many things would be to
remove the dependencies
install-html: html
install-man: man
Peter Eisentraut <peter_e@gmx.net> writes:
On tis, 2009-08-18 at 15:13 -0400, Tom Lane wrote:
Well, having "make install" behave in a history-dependent fashion is just
as much a hazard for users as it is for developers.
That's kind of a built-in feature of make. Otherwise we could write the
build rules as shell scripts. ;-)
Well, no -- make is supposed to skip redundant build steps while
producing the specified outputs. It's not supposed to skip producing
the outputs.
Anyway, a simple fix that doesn't upset too many things would be to
remove the dependencies
install-html: html
install-man: man
That doesn't really make me feel more comfortable. It would
alleviate my immediate complaint, but also introduce the possibility of
accidentally installing obsolete docs. OTOH I suppose the probability
of an actual problem of that sort is low, and we've been living with
essentially equivalent install behavior for a long time.
regards, tom lane
Peter Eisentraut wrote:
I'm not exactly sure what the goal is, however. You built the
documentation at some point. Then it gets updated when necessary. You
can delete the documentation by running make -C doc maintainer-clean.
Then it's gone forever and never reappears unless you explicitly build
it again.
I think this bit is missing something; the html-stamp file is created on
the builddir, but maintainer-clean is trying to delete it from the
source dir.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
On Thu, 2009-10-01 at 15:17 -0400, Alvaro Herrera wrote:
Peter Eisentraut wrote:
I'm not exactly sure what the goal is, however. You built the
documentation at some point. Then it gets updated when necessary. You
can delete the documentation by running make -C doc maintainer-clean.
Then it's gone forever and never reappears unless you explicitly build
it again.I think this bit is missing something; the html-stamp file is created on
the builddir, but maintainer-clean is trying to delete it from the
source dir.
Yeah, I missed something there, apparently. I don't use vpath builds so
much, so if you find more things like that, please clean them up or tell
me.