Horton

Thread

Commits

  1. Use pkg-config, if available, to locate libxml2 during configure.

  1. [PATCH] Use PKG_CHECK_MODULES to detect the libxml2 library

    Hugh McMaster <hugh.mcmaster@outlook.com> — 2020-03-10T10:53:14Z

    Dear developers,

Debian (and Ubuntu) are beginning to remove foo-config legacy scripts.
Already, xml2-config has been flagged for removal, with packages being
asked to switch to pkg-config.

This patch uses pkg-config's PKG_CHECK_MODULES macro to detect libxml2
or, if pkg-config is not available, falls back to xml2-confg.

The patch was created against the master branch of git.

I have built PostgreSQL and run `make check`. All 196 tests passed.

Hugh

  2. Re: [PATCH] Use PKG_CHECK_MODULES to detect the libxml2 library

    Daniel Gustafsson <daniel@yesql.se> — 2020-03-10T11:41:51Z

    > On 10 Mar 2020, at 11:53, Hugh McMaster <hugh.mcmaster@outlook.com> wrote:

> Debian (and Ubuntu) are beginning to remove foo-config legacy scripts.
> Already, xml2-config has been flagged for removal, with packages being
> asked to switch to pkg-config.
> 
> This patch uses pkg-config's PKG_CHECK_MODULES macro to detect libxml2
> or, if pkg-config is not available, falls back to xml2-confg.

This was previously discussed in 20200120204715.GA73984@msg.df7cb.de which
ended without a real conclusion on what could/should be done (except that
nothing *had* to be done).

What is the situation on non-Debian/Ubuntu systems (BSD's, macOS etc etc)?  Is
it worth adding pkg-config support if we still need a fallback to xml2-config?

cheers ./daniel

  3. Re: [PATCH] Use PKG_CHECK_MODULES to detect the libxml2 library

    Peter Eisentraut <peter.eisentraut@2ndquadrant.com> — 2020-03-10T17:38:41Z

    On 2020-03-10 12:41, Daniel Gustafsson wrote:
>> On 10 Mar 2020, at 11:53, Hugh McMaster <hugh.mcmaster@outlook.com> wrote:
> 
>> Debian (and Ubuntu) are beginning to remove foo-config legacy scripts.
>> Already, xml2-config has been flagged for removal, with packages being
>> asked to switch to pkg-config.
>>
>> This patch uses pkg-config's PKG_CHECK_MODULES macro to detect libxml2
>> or, if pkg-config is not available, falls back to xml2-confg.
> 
> This was previously discussed in 20200120204715.GA73984@msg.df7cb.de which
> ended without a real conclusion on what could/should be done (except that
> nothing *had* to be done).
> 
> What is the situation on non-Debian/Ubuntu systems (BSD's, macOS etc etc)?  Is
> it worth adding pkg-config support if we still need a fallback to xml2-config?

Btw., here is an older thread for the same issue 
<https://www.postgresql.org/message-id/flat/1358164265.29612.7.camel%40vanquo.pezone.net>. 
  Might be worth reflecting on the issues discussed there.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

  4. Re: [PATCH] Use PKG_CHECK_MODULES to detect the libxml2 library

    Daniel Gustafsson <daniel@yesql.se> — 2020-03-10T20:49:49Z

    > On 10 Mar 2020, at 18:38, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote:
> 
> On 2020-03-10 12:41, Daniel Gustafsson wrote:
>>> On 10 Mar 2020, at 11:53, Hugh McMaster <hugh.mcmaster@outlook.com> wrote:
>>> Debian (and Ubuntu) are beginning to remove foo-config legacy scripts.
>>> Already, xml2-config has been flagged for removal, with packages being
>>> asked to switch to pkg-config.
>>> 
>>> This patch uses pkg-config's PKG_CHECK_MODULES macro to detect libxml2
>>> or, if pkg-config is not available, falls back to xml2-confg.
>> This was previously discussed in 20200120204715.GA73984@msg.df7cb.de which
>> ended without a real conclusion on what could/should be done (except that
>> nothing *had* to be done).
>> What is the situation on non-Debian/Ubuntu systems (BSD's, macOS etc etc)?  Is
>> it worth adding pkg-config support if we still need a fallback to xml2-config?
> 
> Btw., here is an older thread for the same issue <https://www.postgresql.org/message-id/flat/1358164265.29612.7.camel%40vanquo.pezone.net>.  Might be worth reflecting on the issues discussed there.

Thanks, didn't realize that the subject had been up for discussion earlier as
well.

For me, the duplication aspect is the most troubling, since we'd still need the
xml2-config fallback and thus won't be able to simplify the code.

cheers ./daniel

  5. Re: [PATCH] Use PKG_CHECK_MODULES to detect the libxml2 library

    Hugh McMaster <hugh.mcmaster@outlook.com> — 2020-03-11T10:24:10Z

    On Tue, 10 Mar 2020 at 22:41, Daniel Gustafsson wrote:
>
> > On 10 Mar 2020, at 11:53, Hugh McMaster <hugh.mcmaster@outlook.com> wrote:
> > This patch uses pkg-config's PKG_CHECK_MODULES macro to detect libxml2
> > or, if pkg-config is not available, falls back to xml2-confg.
>
> This was previously discussed in 20200120204715.GA73984@msg.df7cb.de which
> ended without a real conclusion on what could/should be done (except that
> nothing *had* to be done).
>
> What is the situation on non-Debian/Ubuntu systems (BSD's, macOS etc etc)?  Is
> it worth adding pkg-config support if we still need a fallback to xml2-config?

To the best of my knowledge, FreeBSD, macOS, OpenSUSE, Solaris etc.
all support detection of libxml2 via pkg-config.

One way or another, xml2-config is going away, whether by decision of
a package maintainer or upstream.

freetype-config was deprecated upstream a few years ago. Upstream ICU
will also disable the installation of icu-config by default from April
this year. Some systems, such as Debian, have not shipped icu-config
for a year or so.

The PHP project last year switched to using pkg-config by default for
all libraries supplying a .pc file. PHP's build scripts do not fall
back to legacy scripts.

Another reason for switching is that xml2-config incorrectly outputs
static libraries when called with `--libs`. You have to call `--libs
--dynamic` to output -lxml2 only. Debian patches the script to avoid
this unusual behaviour.

  6. Re: [PATCH] Use PKG_CHECK_MODULES to detect the libxml2 library

    Hugh McMaster <hugh.mcmaster@outlook.com> — 2020-03-11T10:37:01Z

    On Wed, 11 Mar 2020 at 07:49, Daniel Gustafsson wrote:
> > On 10 Mar 2020, at 18:38, Peter Eisentraut wrote:
> > Btw., here is an older thread for the same issue <https://www.postgresql.org/message-id/flat/1358164265.29612.7.camel%40vanquo.pezone.net>.  Might be worth reflecting on the issues discussed there.
>
> Thanks, didn't realize that the subject had been up for discussion earlier as
> well.

Interesting thread. The issue of precedence (e.g. pkg-config over
xml2-config) is still relevant, although arguably less so today, due
to the far greater availability of pkg-config. Some packages choose to
fall back to xml2-config, say, if they need to support old or
soon-to-be EOL systems lacking pkg-config. These situations are
increasingly rare.

The thread is correct on multi-arch header and library directories.
That said, pkg-config can handle this easily.

> For me, the duplication aspect is the most troubling, since we'd still need the
> xml2-config fallback and thus won't be able to simplify the code.

configure.in shows that ICU only uses the PKG_CHECK_MODULES macro.
libxml2, libxslt and other dependencies could also switch.

Using AC_CHECK_LIB to add libraries (such as -lxml2) to $LIBS isn't
probably the most ideal method (I'd recommend adding pkg-config's
native X_CFLAGS and X_LIBS variables as necessary to $LIBS, $CPPFLAGS
etc.), but that's a topic for another thread.

  7. Re: [PATCH] Use PKG_CHECK_MODULES to detect the libxml2 library

    Tom Lane <tgl@sss.pgh.pa.us> — 2020-03-11T16:39:10Z

    Daniel Gustafsson <daniel@yesql.se> writes:
> On 10 Mar 2020, at 18:38, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote:
>> Btw., here is an older thread for the same issue <https://www.postgresql.org/message-id/flat/1358164265.29612.7.camel%40vanquo.pezone.net>.  Might be worth reflecting on the issues discussed there.

> Thanks, didn't realize that the subject had been up for discussion earlier as
> well.
> For me, the duplication aspect is the most troubling, since we'd still need the
> xml2-config fallback and thus won't be able to simplify the code.

Yeah, but at least it's concentrated in a few lines in configure.in.

I think that the main objection to this is the documentation/confusion
issues raised by Noah in that old thread.  Still, we probably don't
have much choice given that some distros are going to remove xml2-config.
In that connection, Hugh's patch lacks docs which is entirely not OK,
but the doc changes in Peter's old patch look workable.

I wonder whether we ought to try to align this with our documented
procedure for falling back if you have no icu-config but want to
use ICU; that part of the docs suggests setting ICU_CFLAGS and ICU_LIBS
manually.  The patch as it stands doesn't seem to support manually
giving XML2_CFLAGS and XML2_LIBS, but it looks like it could easily
be adjusted to allow that.

Also, I see that pkg.m4 says

dnl Note that if there is a possibility the first call to
dnl PKG_CHECK_MODULES might not happen, you should be sure to include an
dnl explicit call to PKG_PROG_PKG_CONFIG in your configure.ac

which we are not doing.  We got away with that as long as there was only
one PKG_CHECK_MODULES call ... but with two, I'd expect that the second
one will fall over if the first one isn't executed.

			regards, tom lane

  8. Re: [PATCH] Use PKG_CHECK_MODULES to detect the libxml2 library

    Hugh McMaster <hugh.mcmaster@outlook.com> — 2020-03-11T22:19:35Z

    On Thu, 12 Mar 2020 at 03:39, Tom Lane wrote:

> Daniel Gustafsson writes:
> > For me, the duplication aspect is the most troubling, since we'd still
> need the
> > xml2-config fallback and thus won't be able to simplify the code.
>
> Yeah, but at least it's concentrated in a few lines in configure.in.
>
> I think that the main objection to this is the documentation/confusion
> issues raised by Noah in that old thread.  Still, we probably don't
> have much choice given that some distros are going to remove xml2-config.
> In that connection, Hugh's patch lacks docs which is entirely not OK,
> but the doc changes in Peter's old patch look workable.


Documentation can be added easily. :-)

I wonder whether we ought to try to align this with our documented
> procedure for falling back if you have no icu-config but want to
> use ICU; that part of the docs suggests setting ICU_CFLAGS and ICU_LIBS
> manually.


Unless your system has ICU installed in a non-standard location, there is
no need to set those variables, as PKG_CHECK_MODULES will handle that for
you. `./configure --help` also provides the relevant documentation on
overriding pkg-config’s X_CFLAGS and X_LIBS.

The patch as it stands doesn't seem to support manually
> giving XML2_CFLAGS and XML2_LIBS, but it looks like it could easily
> be adjusted to allow that.


What I said for ICU also applies here (in fact, to all use of
PKG_CHECK_MODULES). For the fallback, a minor rework is required.

The question is really whether we want to maintain a fallback to
xml2-config. To give more context, I gave a more detailed assessment of the
situation in an earlier email to this list. (Personally, I don’t think we
should.)

Do note also that xslt-config will also be a problem at some point.

Also, I see that pkg.m4 says
>
> dnl Note that if there is a possibility the first call to
> dnl PKG_CHECK_MODULES might not happen, you should be sure to include an
> dnl explicit call to PKG_PROG_PKG_CONFIG in your configure.ac
>
> which we are not doing.  We got away with that as long as there was only
> one PKG_CHECK_MODULES call ... but with two, I'd expect that the second
> one will fall over if the first one isn't executed.


Yes, that macro needs to be set.

Hugh

  9. Re: [PATCH] Use PKG_CHECK_MODULES to detect the libxml2 library

    Tom Lane <tgl@sss.pgh.pa.us> — 2020-03-11T22:33:42Z

    Hugh McMaster <hugh.mcmaster@outlook.com> writes:
> The question is really whether we want to maintain a fallback to
> xml2-config. To give more context, I gave a more detailed assessment of the
> situation in an earlier email to this list. (Personally, I don’t think we
> should.)

I think that that is not optional.  We try to maintain portability
to old systems as well as new.

			regards, tom lane

  10. Re: [PATCH] Use PKG_CHECK_MODULES to detect the libxml2 library

    Tom Lane <tgl@sss.pgh.pa.us> — 2020-03-12T16:39:41Z

    I poked at this issue a bit more and realized that Hugh's patch
flat-out breaks building --with-libxml in environments without
pkg-config, because PKG_CHECK_MODULES just gives up and dies
if there's no pkg-config (as we'd already found out in connection
with ICU).  That won't win us any friends, so the attached revision
doesn't call PKG_CHECK_MODULES unless we found pkg-config.  I also
concluded that if the user has set XML2_CONFIG, it's pretty clear
that her intent is to use whatever that is pointing at, so we should
not use pkg-config in that case either.

Also, I'd been going back and forth about whether it was worth
documenting XML2_CFLAGS/XML2_LIBS, but I realized that use of
PKG_CHECK_MODULES(XML2, ...) basically forces the issue for us:
it does AC_ARG_VAR on them, which puts them into configure's
--help output and makes configure picky about caching them.
So we can't really pretend they're boring implementation detail.

So the attached mostly adopts Peter's old suggested docs, but
I added discussion of XML2_CFLAGS/XML2_LIBS and dropped the mention
of forcing matters with --with-libs/--with-libraries (not because
that doesn't work anymore but because it seemed like we were offering
quite enough alternatives already).

I'd originally thought that we might back-patch this, but I'm now of
the opinion that we probably should not.  If pkg-config is present,
this can change the default behavior about where we get libxml from,
which seems like something not to do in minor releases.  (OTOH, it'd
only matter if the default pkg-config choice is different from the
default xml2-config choice, so maybe the risk of breakage is small
enough to be acceptable?)

			regards, tom lane

  11. Re: [PATCH] Use PKG_CHECK_MODULES to detect the libxml2 library

    Daniel Gustafsson <daniel@yesql.se> — 2020-03-12T21:00:33Z

    > On 12 Mar 2020, at 17:39, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> I also
> concluded that if the user has set XML2_CONFIG, it's pretty clear
> that her intent is to use whatever that is pointing at, so we should
> not use pkg-config in that case either.

+1

> I'd originally thought that we might back-patch this, but I'm now of
> the opinion that we probably should not.  If pkg-config is present,
> this can change the default behavior about where we get libxml from,
> which seems like something not to do in minor releases.  (OTOH, it'd
> only matter if the default pkg-config choice is different from the
> default xml2-config choice, so maybe the risk of breakage is small
> enough to be acceptable?)

I read this is as a preventative patch to stay ahead of future changes to
packaging.  If these changes do materialize, won't they be equally likely to
hit installations for backbranch minors as v13?  Changing behavior in a minor
release is however not ideal, but perhaps the risk/benefit analysis comes down
to releases not compiling being worse?

I haven't had the chance to test the patch, but the changes to configure.in
reads perfectly fine. In the docs though:

> +         To use a libxml installation that is in an unusual location, you

We refer to both libxml and libxml2 in these paragraphs.  Since upstream is
consistently referring to it as libxml2, maybe we should take this as
opportunity to switch to that for the docs?

cheers ./daniel

  12. Re: [PATCH] Use PKG_CHECK_MODULES to detect the libxml2 library

    Hugh McMaster <hugh.mcmaster@outlook.com> — 2020-03-13T12:26:03Z

    On Fri, 13 Mar 2020 at 03:39, Tom Lane wrote:
> I poked at this issue a bit more and realized that Hugh's patch
> flat-out breaks building --with-libxml in environments without
> pkg-config, because PKG_CHECK_MODULES just gives up and dies
> if there's no pkg-config (as we'd already found out in connection
> with ICU).

As you found out, that is by design. PKG_CHECK_MODULES actually checks
for pkg-config via PKG_PROG_PKG_CONFIG, but only in the first
expansion of PKG_CHECK_MODULES. If the first instance is in a
conditional, then the check for pkg-config is also in that
conditional. Once a build system begins using pkg-config without a
fallback (e.g. like for ICU), pkg-config becomes a build dependency
(and, yes, I realise ICU isn't mandatory here).

That won't win us any friends, so the attached revision
> doesn't call PKG_CHECK_MODULES unless we found pkg-config.

Did you mean to terminate configure if pkg-config cannot find
libxml-2.0 or the library is too old? Your doc changes don't indicate
that intent, nor was it prior behaviour, but some projects like that
behaviour and others don't.

> I also concluded that if the user has set XML2_CONFIG, it's pretty clear
> that her intent is to use whatever that is pointing at, so we should
> not use pkg-config in that case either.
>
> Also, I'd been going back and forth about whether it was worth
> documenting XML2_CFLAGS/XML2_LIBS, but I realized that use of
> PKG_CHECK_MODULES(XML2, ...) basically forces the issue for us:
> it does AC_ARG_VAR on them, which puts them into configure's
> --help output and makes configure picky about caching them.
> So we can't really pretend they're boring implementation detail.

You might consider this an edge case, but you override custom
XML2_CFLAGS/LIBS if xml2-config is detected.

> So the attached mostly adopts Peter's old suggested docs, but
> I added discussion of XML2_CFLAGS/XML2_LIBS and dropped the mention
> of forcing matters with --with-libs/--with-libraries (not because
> that doesn't work anymore but because it seemed like we were offering
> quite enough alternatives already).
>
> I'd originally thought that we might back-patch this, but I'm now of
> the opinion that we probably should not.  If pkg-config is present,
> this can change the default behavior about where we get libxml from,
> which seems like something not to do in minor releases.  (OTOH, it'd
> only matter if the default pkg-config choice is different from the
> default xml2-config choice, so maybe the risk of breakage is small
> enough to be acceptable?)

  13. Re: [PATCH] Use PKG_CHECK_MODULES to detect the libxml2 library

    Tom Lane <tgl@sss.pgh.pa.us> — 2020-03-13T16:06:24Z

    Hugh McMaster <hugh.mcmaster@outlook.com> writes:
> On Fri, 13 Mar 2020 at 03:39, Tom Lane wrote:
>> That won't win us any friends, so the attached revision
>> doesn't call PKG_CHECK_MODULES unless we found pkg-config.

> Did you mean to terminate configure if pkg-config cannot find
> libxml-2.0 or the library is too old? Your doc changes don't indicate
> that intent, nor was it prior behaviour, but some projects like that
> behaviour and others don't.

Yeah, a potential edge-case here is that pkg-config is in the PATH
but it has no information about libxml2 (I doubt we need to consider
the risk that it has info about a pre-2.6.23 version).  Looking
again at the generated configure code, I realize I shouldn't have
left off the ACTION-IF-NOT-FOUND argument --- the default is to
throw an error, but we'd rather fall through and try to use xml2-config.
The eventual AC_CHECK_LIB(xml2, ...) test will catch the situation
where the library isn't there.  Updated patch attached.

> You might consider this an edge case, but you override custom
> XML2_CFLAGS/LIBS if xml2-config is detected.

Yeah, if pkg-config fails and xml2-config is present, that's true.
Since those weren't there before, and we now document them as just
a fallback solution, I think that's fine.

			regards, tom lane

  14. Re: [PATCH] Use PKG_CHECK_MODULES to detect the libxml2 library

    Tom Lane <tgl@sss.pgh.pa.us> — 2020-03-13T16:14:52Z

    Daniel Gustafsson <daniel@yesql.se> writes:
>> On 12 Mar 2020, at 17:39, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I'd originally thought that we might back-patch this, but I'm now of
>> the opinion that we probably should not.  If pkg-config is present,
>> this can change the default behavior about where we get libxml from,
>> which seems like something not to do in minor releases.  (OTOH, it'd
>> only matter if the default pkg-config choice is different from the
>> default xml2-config choice, so maybe the risk of breakage is small
>> enough to be acceptable?)

> I read this is as a preventative patch to stay ahead of future changes to
> packaging.  If these changes do materialize, won't they be equally likely to
> hit installations for backbranch minors as v13?

Yeah, that's the argument *for* back-patching.  Question is whether it
outweighs the risk of silently breaking somebody's build by linking
to the wrong libxml2 version.

I could go either way, honestly.  The risk doesn't seem large, but
it's not zero.

> We refer to both libxml and libxml2 in these paragraphs.  Since upstream is
> consistently referring to it as libxml2, maybe we should take this as
> opportunity to switch to that for the docs?

I think we're kind of stuck with "--with-libxml".  Conceivably we
could introduce "--with-libxml2", redefine the old switch as an
obsolete alias, and start saying "libxml2" instead of "libxml".
But I'm not sure that's worth the trouble, and it seems like
material for a different patch anyway.

			regards, tom lane

  15. Re: [PATCH] Use PKG_CHECK_MODULES to detect the libxml2 library

    Hugh McMaster <hugh.mcmaster@outlook.com> — 2020-03-16T11:49:05Z

    On Sat, 14 Mar 2020 at 03:06, Tom Lane wrote:
> Looking again at the generated configure code, I realize I shouldn't have
> left off the ACTION-IF-NOT-FOUND argument --- the default is to
> throw an error, but we'd rather fall through and try to use xml2-config.
> The eventual AC_CHECK_LIB(xml2, ...) test will catch the situation
> where the library isn't there.  Updated patch attached.

The updated patch works fine. Thanks for working on this!

Hugh

  16. Re: [PATCH] Use PKG_CHECK_MODULES to detect the libxml2 library

    Daniel Gustafsson <daniel@yesql.se> — 2020-03-16T14:30:17Z

    > On 13 Mar 2020, at 17:14, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Daniel Gustafsson <daniel@yesql.se> writes:

>> I read this is as a preventative patch to stay ahead of future changes to
>> packaging.  If these changes do materialize, won't they be equally likely to
>> hit installations for backbranch minors as v13?
> 
> Yeah, that's the argument *for* back-patching.  Question is whether it
> outweighs the risk of silently breaking somebody's build by linking
> to the wrong libxml2 version.

Correct, my argument is that breakage can be expected equally across branches,
so I think back-patching should be seriously considered.

>> We refer to both libxml and libxml2 in these paragraphs.  Since upstream is
>> consistently referring to it as libxml2, maybe we should take this as
>> opportunity to switch to that for the docs?
> 
> I think we're kind of stuck with "--with-libxml".  Conceivably we
> could introduce "--with-libxml2", redefine the old switch as an
> obsolete alias, and start saying "libxml2" instead of "libxml".
> But I'm not sure that's worth the trouble, and it seems like
> material for a different patch anyway.

Absolutely, thats why I referred to changing mentions of libxml in the docs
only where we refer to the product and not the switch (the latter was not very
clear in my email though).  Also, shouldn't libxml2 be within <productname>
tags like OpenSSL and LLVM et.al?

cheers ./daniel

  17. Re: [PATCH] Use PKG_CHECK_MODULES to detect the libxml2 library

    Tom Lane <tgl@sss.pgh.pa.us> — 2020-03-16T16:12:52Z

    Daniel Gustafsson <daniel@yesql.se> writes:
> On 13 Mar 2020, at 17:14, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Yeah, that's the argument *for* back-patching.  Question is whether it
>> outweighs the risk of silently breaking somebody's build by linking
>> to the wrong libxml2 version.

> Correct, my argument is that breakage can be expected equally across branches,
> so I think back-patching should be seriously considered.

You're right that the risk of breakage (of either type) is about the same
across branches; but the project's conventions are not.  We try to avoid
unnecessary changes in back branches.

Still, after further reflection, I think the odds favor back-patching.
This patch could only break things on systems where

(a) There's more than one libxml2 installation, which is already a
tiny minority use-case.  It seems very unlikely to hurt any packagers
following typical build processes, for instance.

AND

(b) the default pkg-config and default xml2-config results differ.
That seems even more unlikely.

Now, breakage is certainly possible.  A counterexample to (b) is that
if you wanted to build using a non-default libxml2 installation, you
might've tried to select that by putting its xml2-config into your
PATH ahead of the system version, rather than setting XML2_CONFIG.
Post-patch, we'd consult pkg-config first and presumably end up
with the system libxml2.

Still, I think the number of people who'd get bit by that could be
counted without running out of fingers, while it seems quite likely
that many people will soon need to build our back branches on
platforms that won't have xml2-config.

So I'm now leaning to "back-patch and make sure to mention this in
the next release notes".  Barring objections, I'll do that soon.

> Absolutely, thats why I referred to changing mentions of libxml in the docs
> only where we refer to the product and not the switch (the latter was not very
> clear in my email though).  Also, shouldn't libxml2 be within <productname>
> tags like OpenSSL and LLVM et.al?

I don't have a problem with s/libxml/libxml2/ in the running text
(without changing the switch name).  Can't get too excited about
<productname> though.  I think we've only consistently applied
that tag to PostgreSQL itself.

			regards, tom lane

  18. Re: [PATCH] Use PKG_CHECK_MODULES to detect the libxml2 library

    Daniel Gustafsson <daniel@yesql.se> — 2020-03-16T21:04:05Z

    > On 16 Mar 2020, at 17:12, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Still, I think the number of people who'd get bit by that could be
> counted without running out of fingers, while it seems quite likely
> that many people will soon need to build our back branches on
> platforms that won't have xml2-config.

I agree with this assessment.

> So I'm now leaning to "back-patch and make sure to mention this in
> the next release notes".  Barring objections, I'll do that soon.

None from me.

> I don't have a problem with s/libxml/libxml2/ in the running text
> (without changing the switch name).

+1

> Can't get too excited about
> <productname> though.  I think we've only consistently applied
> that tag to PostgreSQL itself.

Fair enough.  Looking at a random sample it seems we use a bit of a mix of
nothing, <application /> and <productname /> (the latter ones being more or
less equal in DocBook IIRC) to mark up externals.

cheers ./daniel

  19. Re: [PATCH] Use PKG_CHECK_MODULES to detect the libxml2 library

    Tom Lane <tgl@sss.pgh.pa.us> — 2020-03-17T16:11:16Z

    Daniel Gustafsson <daniel@yesql.se> writes:
>> On 16 Mar 2020, at 17:12, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> So I'm now leaning to "back-patch and make sure to mention this in
>> the next release notes".  Barring objections, I'll do that soon.

> None from me.

Done.  In the event, it only seemed practical to back-patch as far as
v10.  9.x didn't use pkg-config for anything, so our infrastructure
for it isn't there.

			regards, tom lane