MacOS: xsltproc fails with "warning: failed to load external entity"

Hi hackers,

At this point I could use a friendly piece of advice from the community.

I've found a solution:

```
export SGML_CATALOG_FILES=/usr/local/etc/xml/catalog
export XMLLINT="xmllint --catalogs"
export XSLTPROC="xsltproc --catalogs"
```

I will submit a patch for the documentation in a bit, after I'll check
it properly.

--
Best regards,
Aleksander Alekseev

Hi hackers,

I've found a solution:

```
export SGML_CATALOG_FILES=/usr/local/etc/xml/catalog
export XMLLINT="xmllint --catalogs"
export XSLTPROC="xsltproc --catalogs"
```

I will submit a patch for the documentation in a bit, after I'll check
it properly.

PFA the patch.

I don't have a strong opinion regarding any particular wording and
would like to ask the committer to change it as he sees fit.

--
Best regards,
Aleksander Alekseev

Aleksander Alekseev <aleksander@timescale.com> writes:

I've found a solution:

```
export SGML_CATALOG_FILES=/usr/local/etc/xml/catalog
export XMLLINT="xmllint --catalogs"
export XSLTPROC="xsltproc --catalogs"
```

Hmm, there is no such directory on my Mac, and indeed this recipe
does not work here. I tried to transpose it to MacPorts by
substituting /opt/local/etc/xml/catalog, which does exist --- but
the recipe still doesn't work.

I believe what is actually failing is that http://docbook.sourceforge.net
now redirects to https:, and the ancient xsltproc version provided by
Apple doesn't do https. What you need to do if you want to use their
xsltproc is install a local copy of the SGML catalog files and
stylesheets, preferably in the place that xsltproc would look by default
(/etc/xml/catalog seems to be the standard one). It would be good to
document how to do that, but this patch doesn't do so.

What we do actually have already is a recommendation to install
appropriate MacPorts or Homebrew packages:

https://www.postgresql.org/docs/devel/docguide-toolsets.html#DOCGUIDE-TOOLSETS-INST-MACOS

and it works okay for me as long as I use MacPorts' version of xsltproc.

regards, tom lane

Hi Tom,

Thanks for the feedback.

Hmm, there is no such directory on my Mac, and indeed this recipe
does not work here. I tried to transpose it to MacPorts by
substituting /opt/local/etc/xml/catalog, which does exist --- but
the recipe still doesn't work.

Well, that's a bummer.

What we do actually have already is a recommendation to install
appropriate MacPorts or Homebrew packages:

https://www.postgresql.org/docs/devel/docguide-toolsets.html#DOCGUIDE-TOOLSETS-INST-MACOS

and it works okay for me as long as I use MacPorts' version of xsltproc.

Unfortunately it doesn't work for Homebrew anymore and there seems to
be only one xsltproc in the system.

I believe what is actually failing is that http://docbook.sourceforge.net
now redirects to https:, and the ancient xsltproc version provided by
Apple doesn't do https. What you need to do if you want to use their
xsltproc is install a local copy of the SGML catalog files and
stylesheets, preferably in the place that xsltproc would look by default
(/etc/xml/catalog seems to be the standard one). It would be good to
document how to do that, but this patch doesn't do so.

Fair enough.

I would appreciate it if you could help figuring out how to do this
for MacPorts, since I'm not a MacPorts user. I'll figure out how to do
this for Homebrew.

Does something like:

```
ln -s /opt/local/etc/xml/catalog /etc/xml/catalog
```

... work for you? Does your:

```
xsltproc --help
```

... also say that it uses /etc/xml/catalog path by default?

--
Best regards,
Aleksander Alekseev

Aleksander Alekseev <aleksander@timescale.com> writes:

What we do actually have already is a recommendation to install
appropriate MacPorts or Homebrew packages:
https://www.postgresql.org/docs/devel/docguide-toolsets.html#DOCGUIDE-TOOLSETS-INST-MACOS
and it works okay for me as long as I use MacPorts' version of xsltproc.

Unfortunately it doesn't work for Homebrew anymore and there seems to
be only one xsltproc in the system.

Hmm. Seems unlikely that Homebrew would have dropped the package(s)
altogether. But ... poking at this, I discovered that there are
inaccuracies in our docs for MacPorts:

* /opt/local/bin/xsltproc is provided by libxslt, and
/opt/local/bin/xmllint is provided by libxml2, neither of which
will be installed by our recipe as given. You might have pulled
those ports in already to build Postgres with, but if you didn't, the
recipe will fail. I wonder if the Homebrew recipe has the same bug.

* At some point MacPorts renamed docbook-xsl to docbook-xsl-nons.
This is harmless at the moment, because if you ask for docbook-xsl
it will automatically install docbook-xsl-nons instead. I wonder
if that'll be true indefinitely, though.

I also wonder whether we shouldn't point at the meta-package docbook-xml
instead of naming a particular version here (and having to update
that from time to time). The extra disk space to install all the DTD
versions is entirely insignificant (< 2MB).

Does your:
xsltproc --help
... also say that it uses /etc/xml/catalog path by default?

Both /usr/bin/xsltproc and /opt/local/bin/xsltproc say

--catalogs : use SGML catalogs from $SGML_CATALOG_FILES
otherwise XML Catalogs starting from
file:///etc/xml/catalog are activated by default

However, this appears to be a lie for /opt/local/bin/xsltproc;
what it's apparently *actually* using is /opt/local/etc/xml/catalog,
which is what MacPorts provides.

I repeated the test I did this morning, and this time using --catalogs
with SGML_CATALOG_FILES set to /opt/local/etc/xml/catalog worked for me,
using either copy of xsltproc. I must've fat-fingered it somehow before.
Nonetheless, I doubt that that recipe is worth recommending to MacPorts
users: if they pull in the DTD packages they might as well pull in libxml2
and libxslt, and then they don't need to adjust anything.

In short, I think we need to update J.2.4 to say this for MacPorts:

sudo port install libxml2 libxslt docbook-xml docbook-xsl-nons fop

and I strongly suspect that the Homebrew recipe has a similar oversight.

regards, tom lane

On 30.01.23 20:04, Aleksander Alekseev wrote:

I would appreciate it if you could help figuring out how to do this
for MacPorts, since I'm not a MacPorts user. I'll figure out how to do
this for Homebrew.

I'm on macOS Monterey and Homebrew. I'm sure I have gone through many
variations of this setup, but checking what I happen to be using right
now, Makefile.global says

XMLLINT = /usr/bin/xmllint
XSLTPROC = /usr/bin/xsltproc

and in the environment there is

XML_CATALOG_FILES=/usr/local/etc/xml/catalog

Just testing this right now, you can avoid having to set this
environment variable by making the default catalog file /etc/xml/catalog
include /usr/local/etc/xml/catalog.

It also works for me to use the Homebrew-provided versions of these tools:

XMLLINT = /usr/local/opt/libxml2/bin/xmllint
XSLTPROC = /usr/local/opt/libxslt/bin/xsltproc

But I can't determine right now what catalog file they look at by
default. It appears that it's neither /etc/xml/catalog nor
/usr/local/etc/xml/catalog. So in this case, setting XML_CATALOG_FILES
is necessary.

For either sets of tools, the automatic download option doesn't appear
to work anymore. This probably has to do with either the https or the
redirects that have been mentioned.

Hi hackers,

/opt/local/bin/xsltproc is provided by libxslt, and
/opt/local/bin/xmllint is provided by libxml2, neither of which
will be installed by our recipe as given. You might have pulled
those ports in already to build Postgres with, but if you didn't, the
recipe will fail. I wonder if the Homebrew recipe has the same bug.

Right, I had libxml2 installed (which provides xmllint) but not
libxslt (which provides xsltproc). For this reason I could find only
the version of xsltproc shipped with macOS.

Both /usr/bin/xsltproc and /opt/local/bin/xsltproc say

--catalogs : use SGML catalogs from $SGML_CATALOG_FILES
otherwise XML Catalogs starting from
file:///etc/xml/catalog are activated by default

However, this appears to be a lie for /opt/local/bin/xsltproc;
what it's apparently *actually* using is /opt/local/etc/xml/catalog,
which is what MacPorts provides.

I repeated the test I did this morning, and this time using --catalogs
with SGML_CATALOG_FILES set to /opt/local/etc/xml/catalog worked for me,
using either copy of xsltproc. I must've fat-fingered it somehow before.
Nonetheless, I doubt that that recipe is worth recommending to MacPorts
users: if they pull in the DTD packages they might as well pull in libxml2
and libxslt, and then they don't need to adjust anything.

Got it, thanks.

In short, I think we need to update J.2.4 to say this for MacPorts:

sudo port install libxml2 libxslt docbook-xml docbook-xsl-nons fop

Agree. I decided to include libxml2 and libxslt for Homebrew as well.
The documentation above explains what these packages are needed for
and also says that some of the packages may be optional. E.g. fop is
actually not strictly required but we recommend installing it anyway.

But I can't determine right now what catalog file they look at by
default. It appears that it's neither /etc/xml/catalog nor
/usr/local/etc/xml/catalog. So in this case, setting XML_CATALOG_FILES
is necessary.

For either sets of tools, the automatic download option doesn't appear
to work anymore. This probably has to do with either the https or the
redirects that have been mentioned.

Peter, thanks for reporting this. I got the same results: neither
tools work without setting XML_CATALOG_FILES and setting this
environment variable work for both Homebrew and macOS versions.

Here is the summary of our findings. PFA the updated patch v2.

While on it, I noticed that the documentation says "On macOS, you can
build the HTML and man documentation without installing anything
extra." I strongly suspect this may not be true anymore. This is
somewhat difficult to check however. Some of the recommended packages
were installed as dependencies of other packages and I don't feel like
taking a risk of running:

```
brew uninstall --ignore-dependencies libxml2 libxslt docbook docbook-xsl
```

... right now. However maybe we should rephrase this to make sure
there are fewer supported/recommended ways of building the
documentation? The alternative ways may also work but if they don't
there will be no actions required from us.

I included the corresponding path as well.

--
Best regards,
Aleksander Alekseev

Aleksander Alekseev <aleksander@timescale.com> writes:

For either sets of tools, the automatic download option doesn't appear
to work anymore. This probably has to do with either the https or the
redirects that have been mentioned.

Peter, thanks for reporting this. I got the same results: neither
tools work without setting XML_CATALOG_FILES and setting this
environment variable work for both Homebrew and macOS versions.

Here is the summary of our findings. PFA the updated patch v2.

It's worse than that: I find that

export XML_CATALOG_FILES=/dev/null

breaks the docs build on RHEL8 and Fedora 37 (latest) too, with the
same "failed to load external entity" symptom. I conclude from this
that there is no version of xsltproc anywhere that can still download
the required files automatically. So we need to take out the advice
that says you can rely on auto-download for everybody, not just macOS.

If this is indeed the case, perhaps we ought to start inserting --nonet
into the invocations. There's not much use in allowing these tools to
perform internet access when the best-case scenario is that they fail.
(Worst-case, you could end up getting hacked, perhaps?)

regards, tom lane

I wrote:

It's worse than that: I find that
export XML_CATALOG_FILES=/dev/null
breaks the docs build on RHEL8 and Fedora 37 (latest) too, with the
same "failed to load external entity" symptom. I conclude from this
that there is no version of xsltproc anywhere that can still download
the required files automatically. So we need to take out the advice
that says you can rely on auto-download for everybody, not just macOS.

If this is indeed the case, perhaps we ought to start inserting --nonet
into the invocations. There's not much use in allowing these tools to
perform internet access when the best-case scenario is that they fail.

Concretely, I'm thinking something like the attached. Notes:

1. I have not tested the meson changes.

2. As this is written, you can't override the --nonet options very
easily in the Makefile build (you could do so at runtime by setting
XSLTPROC, but not at configure time); and you can't override them at
all in the meson build. Given the lack of evidence that it's still
useful to allow net access, I'm untroubled by that. I did intentionally
skip using "override" in the Makefile, though, to allow that case.

3. For consistency with the directions for other platforms, I made
the package lists for macOS just mention libxslt. That should
be enough to pull in libxml2 as well.

4. Use of --nonet changes the error message you get if xsltproc
can't find the DTDs. I copied the error I get from MacPorts'
version of xsltproc, but can you confirm it's the same on Homebrew?

regards, tom lane

Hi,

On 2023-01-31 18:54:31 -0500, Tom Lane wrote:

1. I have not tested the meson changes.

Works here.

2. As this is written, you can't override the --nonet options very
easily in the Makefile build (you could do so at runtime by setting
XSLTPROC, but not at configure time); and you can't override them at
all in the meson build. Given the lack of evidence that it's still
useful to allow net access, I'm untroubled by that. I did intentionally
skip using "override" in the Makefile, though, to allow that case.

I'm not troubled by this either.

I wonder if we should provide a build target to download the stylesheets
ourselves. The amount of packages our instructions download is quite
substantial. We could perhaps trim them a bit, but we intentionally are
including things to build pdfs etc as well, which does make sense...

Greetings,

Andres Freund

Hi hackers,

Concretely, I'm thinking something like the attached. Notes:

1. I have not tested the meson changes.

Works here.

Took me a while to figure out how to build the documentation with Meson:

```
XML_CATALOG_FILES=/usr/local/etc/xml/catalog ninja -C build alldocs
```

It works. Perhaps we should add:

```
ninja -C build alldocs
```

... command to installation.sgml file while on it, to the 17.4.1
Building and Installation with Meson / Short Version section.

2. As this is written, you can't override the --nonet options very
easily in the Makefile build (you could do so at runtime by setting
XSLTPROC, but not at configure time); and you can't override them at
all in the meson build. Given the lack of evidence that it's still
useful to allow net access, I'm untroubled by that. I did intentionally
skip using "override" in the Makefile, though, to allow that case.

I'm not troubled by this either.

Neither am I.

3. For consistency with the directions for other platforms, I made
the package lists for macOS just mention libxslt. That should
be enough to pull in libxml2 as well.

Fair enough.

4. Use of --nonet changes the error message you get if xsltproc
can't find the DTDs. I copied the error I get from MacPorts'
version of xsltproc, but can you confirm it's the same on Homebrew?

Yes, the message is the same.

--
Best regards,
Aleksander Alekseev

Hi,

On 2023-02-01 13:05:32 +0300, Aleksander Alekseev wrote:

Took me a while to figure out how to build the documentation with Meson:

```
XML_CATALOG_FILES=/usr/local/etc/xml/catalog ninja -C build alldocs
```

It works. Perhaps we should add:

```
ninja -C build alldocs
```

FWIW, just 'docs' would build just the multi-page html/man pages,
alldocs takes a lot longer...

And yes, adding that to the docs is a good idea.

Greetings,

Andres Freund

Andres Freund <andres@anarazel.de> writes:

On 2023-02-01 13:05:32 +0300, Aleksander Alekseev wrote:

It works. Perhaps we should add:
ninja -C build alldocs

FWIW, just 'docs' would build just the multi-page html/man pages,
alldocs takes a lot longer...

Hmm ... why does 'docs' include the man pages, and not just the html?
It's unlike what "make -C doc/src/sgml all" does in the Makefile
system, and I don't find it to be an improvement. I want the man
pages approximately never, so I don't care to wait around for them
to be built.

While I'm bitching ... section 17.1 doesn't mention that you need
ninja to use meson, much less mention the minimum version. And
the minimum version appears to be newer than RHEL8's 1.8.2,
which I find pretty unfortunate. On RHEL8, it fails with

$ ninja
ninja: error: build.ninja:6771: multiple outputs aren't (yet?) supported by depslog; bring this up on the mailing list if it affects you

I did manage to test this stuff on bleeding-edge Fedora,
but ...

regards, tom lane

Hi,

On 2023-02-01 12:23:27 -0500, Tom Lane wrote:

Andres Freund <andres@anarazel.de> writes:

On 2023-02-01 13:05:32 +0300, Aleksander Alekseev wrote:

It works. Perhaps we should add:
ninja -C build alldocs

FWIW, just 'docs' would build just the multi-page html/man pages,
alldocs takes a lot longer...

Hmm ... why does 'docs' include the man pages, and not just the html?

I think it's because the makefile is doing things a bit oddly, and I
didn't quite grok that in the right moment.

I probably just saw:
all: html man

but before that there's

# Make "html" the default target, since that is what most people tend
# to want to use.
html:

It's unlike what "make -C doc/src/sgml all" does in the Makefile
system, and I don't find it to be an improvement.

Well, that'd actually build the manpages too, afaics :). But I get the
point.

I really have no opinion on what we should should build under what
name. Happy to change what's included in 'docs', add additional targets,
etc.

I want the man pages approximately never, so I don't care to wait
around for them to be built.

While I'm bitching ... section 17.1 doesn't mention that you need
ninja to use meson, much less mention the minimum version.

Peter rewrote the requirements (almost?) entirely while committing the
docs from Samay and hasn't responded to my concerns about the new
form...

Normally the ninja version that's pulled in by meson should suffice. I
suspect that the problem you found can be worked around.

And the minimum version appears to be newer than RHEL8's 1.8.2, which
I find pretty unfortunate. On RHEL8, it fails with
$ ninja
ninja: error: build.ninja:6771: multiple outputs aren't (yet?) supported by depslog; bring this up on the mailing list if it affects you

What's in that line +- 2 lines? And/or what are the steps that got you
to that point?

I'll try building 1.8.2 and reproing.

I did manage to test this stuff on bleeding-edge Fedora,
but ...

Yea, I worked a fair bit to avoid requiring a too new version, I'll try
to figure out what went wrong. I did built on rhel8 not long ago, so I
suspect it's a corner case somewhere.

Greetings,

Andres Freund

Andres Freund <andres@anarazel.de> writes:

On 2023-02-01 12:23:27 -0500, Tom Lane wrote:

It's unlike what "make -C doc/src/sgml all" does in the Makefile
system, and I don't find it to be an improvement.

Well, that'd actually build the manpages too, afaics :). But I get the
point.

Ah, sorry, I too had forgotten that "all" isn't the default target
there. I actually just go into that directory and type "make".

I really have no opinion on what we should should build under what
name. Happy to change what's included in 'docs', add additional targets,
etc.

I think "docs" for just the html and "alldocs" for all supported
outputs is probably reasonable. If we ever get to the point of
building distribution tarballs with meson, we might need another
target for html+man, but I suppose that's a long way off.

And the minimum version appears to be newer than RHEL8's 1.8.2, which
I find pretty unfortunate. On RHEL8, it fails with
$ ninja
ninja: error: build.ninja:6771: multiple outputs aren't (yet?) supported by depslog; bring this up on the mailing list if it affects you

What's in that line +- 2 lines? And/or what are the steps that got you
to that point?

"meson setup build" is sufficient to see it --- apparently ninja
gets invoked at the end of that, and it's already unhappy. But
it repeats after "cd build; ninja".

It seems to be unhappy about the stanza for building sql_help.c?
Line 6771 is the blank line after "description" in this bit:

build src/bin/psql/sql_help.c src/bin/psql/sql_help.h: CUSTOM_COMMAND_DEP | ../src/bin/psql/create_help.pl /usr/bin/perl
DEPFILE = src/bin/psql/sql_help.dep
DEPFILE_UNQUOTED = src/bin/psql/sql_help.dep
COMMAND = /usr/bin/perl ../src/bin/psql/create_help.pl --docdir ../doc/src/sgml/ref --depfile src/bin/psql/sql_help.dep --outdir src/bin/psql --basename sql_help
description = Generating$ psql_help$ with$ a$ custom$ command

build src/bin/psql/psql.p/meson-generated_.._psqlscanslash.c.o: c_COMPILER src/bin/psql/psqlscanslash.c || src/bin/psql/sql_help.h src/include/catalog/pg_aggregate_d.h src/include/catalog/pg_am_d.h src/include/catalog/pg_amop_d.h src/include/catalog/pg_amproc_d.h src/include/catalog/pg_attrdef_d.h src/include/catalog/pg_attribute_d.h src/include/catalog/pg_auth_members_d.h src/include/catalog/pg_authid_d.h src/include/catalog/pg_cast_d.h src/include/catalog/pg_class_d.h src/include/catalog/pg_collation_d.h src/include/catalog/pg_constraint_d.h src/include/catalog/pg_conversion_d.h src/include/catalog/pg_database_d.h src/include/catalog/pg_db_role_setting_d.h src/include/catalog/pg_default_acl_d.h src/include/catalog/pg_depend_d.h src/include/catalog/pg_description_d.h src/include/catalog/pg_enum_d.h src/include/catalog/pg_event_trigger_d.h src/include/catalog/pg_extension_d.h src/include/catalog/pg_foreign_data_wrapper_d.h src/include/catalog/pg_foreign_server_d.h src/include/catalog/pg_foreign_table_d.h src/include/catalog/pg_index_d.h src/include/catalog/pg_inherits_d.h src/include/catalog/pg_init_privs_d.h src/include/catalog/pg_language_d.h src/include/catalog/pg_largeobject_d.h src/include/catalog/pg_largeobject_metadata_d.h src/include/catalog/pg_namespace_d.h src/include/catalog/pg_opclass_d.h src/include/catalog/pg_operator_d.h src/include/catalog/pg_opfamily_d.h src/include/catalog/pg_parameter_acl_d.h src/include/catalog/pg_partitioned_table_d.h src/include/catalog/pg_policy_d.h src/include/catalog/pg_proc_d.h src/include/catalog/pg_publication_d.h src/include/catalog/pg_publication_namespace_d.h src/include/catalog/pg_publication_rel_d.h src/include/catalog/pg_range_d.h src/include/catalog/pg_replication_origin_d.h src/include/catalog/pg_rewrite_d.h src/include/catalog/pg_seclabel_d.h src/include/catalog/pg_sequence_d.h src/include/catalog/pg_shdepend_d.h src/include/catalog/pg_shdescription_d.h src/include/catalog/pg_shseclabel_d.h src/include/catalog/pg_statistic_d.h src/include/catalog/pg_statistic_ext_d.h src/include/catalog/pg_statistic_ext_data_d.h src/include/catalog/pg_subscription_d.h src/include/catalog/pg_subscription_rel_d.h src/include/catalog/pg_tablespace_d.h src/include/catalog/pg_transform_d.h src/include/catalog/pg_trigger_d.h src/include/catalog/pg_ts_config_d.h src/include/catalog/pg_ts_config_map_d.h src/include/catalog/pg_ts_dict_d.h src/include/catalog/pg_ts_parser_d.h src/include/catalog/pg_ts_template_d.h src/include/catalog/pg_type_d.h src/include/catalog/pg_user_mapping_d.h src/include/catalog/postgres.bki src/include/catalog/schemapg.h src/include/catalog/system_constraints.sql src/include/catalog/system_fk_info.h src/include/nodes/nodetags.h src/include/utils/errcodes.h
DEPFILE = src/bin/psql/psql.p/meson-generated_.._psqlscanslash.c.o.d
DEPFILE_UNQUOTED = src/bin/psql/psql.p/meson-generated_.._psqlscanslash.c.o.d
ARGS = -Isrc/bin/psql/psql.p -Isrc/bin/psql -I../src/bin/psql -Isrc/include -I../src/include -Isrc/interfaces/libpq -I../src/interfaces/libpq -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -O3 -fno-strict-aliasing -fwrapv -fexcess-precision=standard -D_GNU_SOURCE -Wmissing-prototypes -Wpointer-arith -Werror=vla -Wendif-labels -Wmissing-format-attribute -Wimplicit-fallthrough=3 -Wcast-function-type -Wshadow=compatible-local -Wformat-security -Wdeclaration-after-statement -Wno-format-truncation -Wno-stringop-truncation -pthread

I did manage to test this stuff on bleeding-edge Fedora,
but ...

Yea, I worked a fair bit to avoid requiring a too new version, I'll try
to figure out what went wrong. I did built on rhel8 not long ago, so I
suspect it's a corner case somewhere.

Oh, interesting. Let me know if you want me to test anything in
particular.

regards, tom lane

Hi,

On 2023-02-01 09:49:00 -0800, Andres Freund wrote:

On 2023-02-01 12:23:27 -0500, Tom Lane wrote:

And the minimum version appears to be newer than RHEL8's 1.8.2, which
I find pretty unfortunate. On RHEL8, it fails with
$ ninja
ninja: error: build.ninja:6771: multiple outputs aren't (yet?) supported by depslog; bring this up on the mailing list if it affects you

What's in that line +- 2 lines? And/or what are the steps that got you
to that point?

I'll try building 1.8.2 and reproing.

I did manage to test this stuff on bleeding-edge Fedora,
but ...

Yea, I worked a fair bit to avoid requiring a too new version, I'll try
to figure out what went wrong. I did built on rhel8 not long ago, so I
suspect it's a corner case somewhere.

Unfortunately the test script accidentally pulled in ninja from epel,
hence not noticing the issue.

There's three issues:

One is easy enough, albeit slightly annoying: 1.8.2 wants the
"depending" file only be named once in a dependency file. Slightly
uglier code in snowball_create.pl, but whatever.

The second is one case of multiple outputs with a depfile:
create_help.pl creates both sql_help.c and sql_help.h. Not immediately
sure what a good solution here is. The brute force solution would be to
invoke it twice, but I don't like that at all.

The last case is the various man directories. That'd be easy enough to
avoid if we generated them inside a man/ directory.

Greetings,

Andres Freund

Andres Freund <andres@anarazel.de> writes:

On 2023-02-01 09:49:00 -0800, Andres Freund wrote:

On 2023-02-01 12:23:27 -0500, Tom Lane wrote:

And the minimum version appears to be newer than RHEL8's 1.8.2, which
I find pretty unfortunate.

Unfortunately the test script accidentally pulled in ninja from epel,
hence not noticing the issue.

Ah. For myself, pulling the newer version from epel would not be a big
problem. I think what we need to do is figure out what is the minimum
ninja version we want to support, and then see if we need to make any
of these changes. I don't have hard data on which distros have which
versions of ninja, but surely somebody checked that at some point?

regards, tom lane

Hi,

Here are my two cents.

the minimum version appears to be newer than RHEL8's 1.8.2,
which I find pretty unfortunate. On RHEL8, it fails with

$ ninja
ninja: error: build.ninja:6771: multiple outputs aren't (yet?) supported by depslog; bring this up on the mailing list if it affects you

[...] I don't have hard data on which distros have which
versions of ninja, but surely somebody checked that at some point?

I'm using three different systems at the moment and the minimum
version of Ninja that is known to work is 1.10.1.

Normally the ninja version that's pulled in by meson should suffice.

There are several ways to install Meson one of which, if you want the
latest version, is just using PIP:

```
pip3 install --user meson
```

Naturally Ninja will not be pulled in this case.

--
Best regards,
Aleksander Alekseev

Hi,

On 2023-02-01 14:20:19 -0500, Tom Lane wrote:

Andres Freund <andres@anarazel.de> writes:

On 2023-02-01 09:49:00 -0800, Andres Freund wrote:

On 2023-02-01 12:23:27 -0500, Tom Lane wrote:

And the minimum version appears to be newer than RHEL8's 1.8.2, which
I find pretty unfortunate.

Unfortunately the test script accidentally pulled in ninja from epel,
hence not noticing the issue.

Ah. For myself, pulling the newer version from epel would not be a big
problem. I think what we need to do is figure out what is the minimum
ninja version we want to support, and then see if we need to make any
of these changes. I don't have hard data on which distros have which
versions of ninja, but surely somebody checked that at some point?

I did survey available meson versions, and chose what features to
use. But not really ninja, since I didn't know about this specific issue
and other than this the ninja version differences were handled by meson.

As all the issues are related to more precise dependencies, I somehwat
wonder if it'd be good enough to use less accurate dependencies with
1.8.2. But I don't like it.

Greetings,

Andres Freund