configure and DocBook XML
Hi,
I always compile PostgreSQL from source and never install a pre-compiled package. When I run configure, the last check, which is for DocBook XML always takes very long compared to all others. It's about 15 to 20 secs or so. I noticed that with many configure scripts, not only the one of PostgreSQL. Why is that?
Cheers,
Paul
On 2020-Nov-26, Paul F�rster wrote:
Hi,
I always compile PostgreSQL from source and never install a pre-compiled package. When I run configure, the last check, which is for DocBook XML always takes very long compared to all others. It's about 15 to 20 secs or so. I noticed that with many configure scripts, not only the one of PostgreSQL. Why is that?
My guess is that it's related to trying to obtain stylesheets from
remote Internet locations that are missing locally.
Hi Alvaro,
On 26. Nov, 2020, at 14:47, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
My guess is that it's related to trying to obtain stylesheets from
remote Internet locations that are missing locally.
I don't know DocBook at all, so I can't say. But it takes about the same time, whether I run configure on a machine that is connected to the internet or one that isn't.
Whatever it does, it's more out of curiosity. PostgreSQL compiles fine and this is what counts. :-)
Cheers,
Paul
On 2020-Nov-26, Paul F�rster wrote:
Hi Alvaro,
On 26. Nov, 2020, at 14:47, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
My guess is that it's related to trying to obtain stylesheets from
remote Internet locations that are missing locally.I don't know DocBook at all, so I can't say. But it takes about the
same time, whether I run configure on a machine that is connected to
the internet or one that isn't.
It might be timing out, then. (The docbook test takes well under a
second for me, but that's probably because I have all stylesheets
locally).
One way to know for sure would be to run it under strace, and see where
it takes a large number of seconds. Maybe something like
strace -f -etrace=%network -T -tt -o/tmp/configure.trace ./configure <opts>
Whatever it does, it's more out of curiosity. PostgreSQL compiles fine
and this is what counts. :-)
Well, it is what it is partly because people have struggled to polish
these little annoyances :-)
Hi Alvaro,
On 26. Nov, 2020, at 15:19, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
One way to know for sure would be to run it under strace, and see where
it takes a large number of seconds. Maybe something like
strace -f -etrace=%network -T -tt -o/tmp/configure.trace ./configure <opts>
ok, I'll try this. Thanks very much.
Well, it is what it is partly because people have struggled to polish
these little annoyances :-)
it's not an annoyance for me with a thing I do 3 or 4 times a year. I'm a DBA, not a developer, so I just build new packages when new versions are released. I don't have to build a couple of times per day. :-)
Cheers,
Paul
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
On 2020-Nov-26, Paul Förster wrote:
On 26. Nov, 2020, at 14:47, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
My guess is that it's related to trying to obtain stylesheets from
remote Internet locations that are missing locally.
I don't know DocBook at all, so I can't say. But it takes about the
same time, whether I run configure on a machine that is connected to
the internet or one that isn't.
It might be timing out, then. (The docbook test takes well under a
second for me, but that's probably because I have all stylesheets
locally).
On machines where I don't have the stylesheets installed, it always
takes several seconds (2 or 3, I think, though I've not put a stopwatch
on it). 15 to 20 sec does seem like a lot, so it makes me wonder if
Paul's network environment is well-configured.
There's a nearby thread in which I was suggesting that we should just
not bother with this configure test [1]/messages/by-id/E2EE6B76-2D96-408A-B961-CAE47D1A86F0@yesql.se.
regards, tom lane
[1]: /messages/by-id/E2EE6B76-2D96-408A-B961-CAE47D1A86F0@yesql.se
Hi Tom,
On 26. Nov, 2020, at 17:21, Tom Lane <tgl@sss.pgh.pa.us> wrote:
On machines where I don't have the stylesheets installed, it always
takes several seconds (2 or 3, I think, though I've not put a stopwatch
on it). 15 to 20 sec does seem like a lot, so it makes me wonder if
Paul's network environment is well-configured.
can't complain here. The net and all other stuff run smoothly. No timeouts, no things being slow or any other problem.
There's a nearby thread in which I was suggesting that we should just
not bother with this configure test [1].
[1] /messages/by-id/E2EE6B76-2D96-408A-B961-CAE47D1A86F0@yesql.se
I haven't installed DocBook at all. So the check for DocBook naturally always fails. Could that be the reason?
Cheers,
Paul
=?utf-8?Q?Paul_F=C3=B6rster?= <paul.foerster@gmail.com> writes:
On 26. Nov, 2020, at 17:21, Tom Lane <tgl@sss.pgh.pa.us> wrote:
There's a nearby thread in which I was suggesting that we should just
not bother with this configure test [1].
[1] /messages/by-id/E2EE6B76-2D96-408A-B961-CAE47D1A86F0@yesql.se
I haven't installed DocBook at all. So the check for DocBook naturally always fails. Could that be the reason?
If you don't have the docbook stylesheets, but you do have xmllint,
configure's probe will cause xmllint to try to download those
stylesheets off the net. For me, that always succeeds, but it
takes two or three seconds. I find it curious that it seems to be
timing out for you.
regards, tom lane
Hi Tom,
On 26. Nov, 2020, at 17:48, Tom Lane <tgl@sss.pgh.pa.us> wrote:
If you don't have the docbook stylesheets, but you do have xmllint,
configure's probe will cause xmllint to try to download those
stylesheets off the net. For me, that always succeeds, but it
takes two or three seconds. I find it curious that it seems to be
timing out for you.
well, openSUSE 15.2 Leap here:
paul@weasel:~$ xmllint --version
xmllint: using libxml version 20907
compiled with: Threads Tree Output Push Reader Patterns Writer SAXv1 FTP HTTP DTDValid HTML Legacy C14N Catalog XPath XPointer XInclude Iconv ISO8859X Unicode Regexps Automata Expr Schemas Schematron Modules Debug Zlib Lzma
paul@weasel:~$ type -a xmllint
xmllint is /usr/bin/xmllint
paul@weasel:~$ zypper se 'xmllint*'
Loading repository data...
Reading installed packages...
No matching items found.
I wonder why zypper tells me, it's not there. If I use yast2 (GUI) to search it, it's there.
Anyway, DocBook XML is definitely not there, neither in zypper se, nor in yast2.
So why would xmllint try to download DocBook XML stylesheets if DocBook is not installed? I'm not a developer but such a thing doesn't make sense to me.
Cheers,
Paul
=?utf-8?Q?Paul_F=C3=B6rster?= <paul.foerster@gmail.com> writes:
So why would xmllint try to download DocBook XML stylesheets if DocBook is not installed? I'm not a developer but such a thing doesn't make sense to me.
You'd have to ask the authors of those programs.
To me, it makes sense to have an option to do that, but I do find it
surprising that it's the default.
regards, tom lane
On 2020-11-26 17:48, Tom Lane wrote:
=?utf-8?Q?Paul_F=C3=B6rster?= <paul.foerster@gmail.com> writes:
On 26. Nov, 2020, at 17:21, Tom Lane <tgl@sss.pgh.pa.us> wrote:
There's a nearby thread in which I was suggesting that we should just
not bother with this configure test [1].
[1] /messages/by-id/E2EE6B76-2D96-408A-B961-CAE47D1A86F0@yesql.seI haven't installed DocBook at all. So the check for DocBook naturally always fails. Could that be the reason?
If you don't have the docbook stylesheets, but you do have xmllint,
configure's probe will cause xmllint to try to download those
stylesheets off the net. For me, that always succeeds, but it
takes two or three seconds. I find it curious that it seems to be
timing out for you.
Correction: xmllint is interested in the DocBook XML DTD, which is
downloadable from
<http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd>. This is what
might be in a package named "docbook" or "docbook-xml". xsltproc is
interested in the DocBook XSLT stylesheets, which are at
<http://docbook.sourceforge.net/release/xsl/current/xhtml/chunk.xsl>, or
locally in a package named something like "docbook-xsl".
AFAICT, configure only runs an xmllint test, so your download issues (at
that point) are likely related to the DTD, not the stylesheets.
Hi Tom,
On 27. Nov, 2020, at 16:29, Tom Lane <tgl@sss.pgh.pa.us> wrote:
To me, it makes sense to have an option to do that, but I do find it
surprising that it's the default.
ok, last question: is there an option for configure to not check for DocBook? It's not installed and PostgreSQL doesn't need it to compile and run just fine.
As I said, it's not an annoyance or something as I only need to build new binaries after the versions (major and minor) are released, which is not often enough to call it an annoyance. :-) I just would like to switch it off if possible, but it's ok if it's not.
Cheers,
Paul
=?utf-8?Q?Paul_F=C3=B6rster?= <paul.foerster@gmail.com> writes:
ok, last question: is there an option for configure to not check for DocBook? It's not installed and PostgreSQL doesn't need it to compile and run just fine.
See the other thread I pointed to.
regards, tom lane
Hi Tom,
On 27. Nov, 2020, at 18:54, Tom Lane <tgl@sss.pgh.pa.us> wrote:
See the other thread I pointed to.
ok, thanks.
Cheers,
Paul
On Fri, Nov 27, 2020 at 10:29:24AM -0500, Tom Lane wrote:
To me, it makes sense to have an option to do that, but I do find it
surprising that it's the default.
But there is no need for an option, right? It is already possible to
override the location where xmllint looks for the catalogs by setting
SGML_CATALOG_FILES and XML_CATALOG_FILES. Not sure for SUSE, but one
can use /etc/{sgml,xml}/catalog on Debian, allowing the configure
check to rely on what's stored locally, making configure not rely on
any external resource.
--
Michael
Michael Paquier <michael@paquier.xyz> writes:
On Fri, Nov 27, 2020 at 10:29:24AM -0500, Tom Lane wrote:
To me, it makes sense to have an option to do that, but I do find it
surprising that it's the default.
But there is no need for an option, right? It is already possible to
override the location where xmllint looks for the catalogs by setting
SGML_CATALOG_FILES and XML_CATALOG_FILES.
But the issue here is about what happens when you don't have a local
copy of the DTD. I don't think adjusting those variables will
change that.
Anyway, I think that the other thread is coming to the conclusion
that it's okay to just document how to inject --nonet via configure,
so we don't need to touch the makefiles. As long as we get rid of
the unrequested network fetch during configure, it's okay by me if an
actual attempt to build the docs will possibly cause a network fetch.
regards, tom lane