> On 27 Mar 2023, at 16:33, Tom Lane wrote:
>
> Julien Rouhaud writes:
>> On Mon, Mar 27, 2023 at 02:06:34PM +0200, Daniel Gustafsson wrote:
>> On 27 Mar 2023, at 14:04, Dagfinn Ilmari Mannsåker wrote:
Doesn't this apply to Apple Silicon generally, not just M1? M2 already
exists,
Julien Rouhaud writes:
> On Mon, Mar 27, 2023 at 02:06:34PM +0200, Daniel Gustafsson wrote:
> On 27 Mar 2023, at 14:04, Dagfinn Ilmari Mannsåker wrote:
>>> Doesn't this apply to Apple Silicon generally, not just M1? M2 already
>>> exists, and M3 etc. will presumably also appear at some point. The
On Mon, Mar 27, 2023 at 02:06:34PM +0200, Daniel Gustafsson wrote:
> > On 27 Mar 2023, at 14:04, Dagfinn Ilmari Mannsåker
> > wrote:
> > Daniel Gustafsson writes:
>
> >> Applied with a tiny but of changes to make it look like the rest of the
> >> paragraph more. Thanks!
> >
> > Doesn't this appl
> On 27 Mar 2023, at 14:04, Dagfinn Ilmari Mannsåker wrote:
> Daniel Gustafsson writes:
>> Applied with a tiny but of changes to make it look like the rest of the
>> paragraph more. Thanks!
>
> Doesn't this apply to Apple Silicon generally, not just M1? M2 already
> exists, and M3 etc. will pre
Daniel Gustafsson writes:
>> On 27 Mar 2023, at 10:41, Julien Rouhaud wrote:
>> On Mon, Mar 27, 2023 at 10:32:52AM +0200, Daniel Gustafsson wrote:
On 27 Mar 2023, at 10:24, Julien Rouhaud wrote:
>
FTR the documented XML_CATALOG_FILES environment variable is only valid for
Intel b
> On 27 Mar 2023, at 10:41, Julien Rouhaud wrote:
> On Mon, Mar 27, 2023 at 10:32:52AM +0200, Daniel Gustafsson wrote:
>>> On 27 Mar 2023, at 10:24, Julien Rouhaud wrote:
>>> FTR the documented XML_CATALOG_FILES environment variable is only valid for
>>> Intel based machines, as homebrew install
On Mon, Mar 27, 2023 at 10:32:52AM +0200, Daniel Gustafsson wrote:
> > On 27 Mar 2023, at 10:24, Julien Rouhaud wrote:
> >
> > Hi,
> >
> > On Wed, Feb 08, 2023 at 05:18:13PM -0500, Tom Lane wrote:
> >> I pushed the discussed documentation improvements, and changed the
> >> behavior of "ninja docs"
> On 27 Mar 2023, at 10:24, Julien Rouhaud wrote:
>
> Hi,
>
> On Wed, Feb 08, 2023 at 05:18:13PM -0500, Tom Lane wrote:
>> I pushed the discussed documentation improvements, and changed the
>> behavior of "ninja docs" to only build the HTML docs. However,
>> I've not done anything about documen
Hi,
On Wed, Feb 08, 2023 at 05:18:13PM -0500, Tom Lane wrote:
> I pushed the discussed documentation improvements, and changed the
> behavior of "ninja docs" to only build the HTML docs. However,
> I've not done anything about documenting what is the minimum
> ninja version.
FTR the documented X
Andres Freund writes:
> On February 9, 2023 8:45:20 PM PST, Tom Lane wrote:
>> Yeah. Well, we were intending to maintain the autoconf build system for
>> several years more anyway. Guess we have to plan on keeping it going
>> until those platforms are EOL or nearly so.
> Both could be supporte
Hi,
On February 9, 2023 8:45:20 PM PST, Tom Lane wrote:
>Andres Freund writes:
>> The only not sufficient ones that bother me to some degree are Ubuntu 20.04
>> and RHEL 8. The issues are different, oddly enough. Ubuntu has a new enough
>> ninja, but meson is too old, RHEL has it the other way
Andres Freund writes:
> The only not sufficient ones that bother me to some degree are Ubuntu 20.04
> and RHEL 8. The issues are different, oddly enough. Ubuntu has a new enough
> ninja, but meson is too old, RHEL has it the other way around.
Yeah. Well, we were intending to maintain the autocon
Hi,
On 2023-02-05 16:52:07 -0800, Andres Freund wrote:
> 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.
RHEL world confuses me a
Hi,
On 2023-02-09 13:48:46 -0500, Tom Lane wrote:
> Andres Freund writes:
> > I think this misunderstanding is again due to the confusion between the
> > 'all'
> > target in doc/src/sgml and the default target, just like earlier in the
> > thread
> > / why I ended up with the prior set of targe
Andres Freund writes:
> I think this misunderstanding is again due to the confusion between the 'all'
> target in doc/src/sgml and the default target, just like earlier in the thread
> / why I ended up with the prior set of targets under 'docs'.
> # Make "html" the default target, since that is
Hi,
On 2023-02-09 09:57:42 -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> > On 08.02.23 23:18, Tom Lane wrote:
> >> I pushed the discussed documentation improvements, and changed the
> >> behavior of "ninja docs" to only build the HTML docs.
>
> > I don't like this change. Now the default s
Peter Eisentraut writes:
> On 08.02.23 23:18, Tom Lane wrote:
>> I pushed the discussed documentation improvements, and changed the
>> behavior of "ninja docs" to only build the HTML docs.
> I don't like this change. Now the default set of docs is different
> between the make builds and the mes
On 08.02.23 23:18, Tom Lane wrote:
I pushed the discussed documentation improvements, and changed the
behavior of "ninja docs" to only build the HTML docs.
I don't like this change. Now the default set of docs is different
between the make builds and the meson builds. And people will be less
Hi,
On 2023-02-08 17:18:13 -0500, Tom Lane wrote:
> However, I've not done anything about documenting what is the minimum ninja
> version.
Sorry, plan to tackle work around this tomorrow. Got stuck for much longer
than I had hoped to debug flapping tests (parts resolved, several others not).
My
I pushed the discussed documentation improvements, and changed the
behavior of "ninja docs" to only build the HTML docs. However,
I've not done anything about documenting what is the minimum
ninja version.
regards, tom lane
Andres Freund writes:
> 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 dependenc
Hi,
On 2023-02-01 14:20:19 -0500, Tom Lane wrote:
> Andres Freund 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.
>
> > U
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
Andres Freund 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 ep
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
Andres Freund 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 fo
Hi,
On 2023-02-01 12:23:27 -0500, Tom Lane wrote:
> Andres Freund 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
Andres Freund 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 no
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
> ```
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. P
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'
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 downloa
Aleksander Alekseev 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 w
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 wond
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
Aleksander Alekseev 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 o
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 w
Aleksander Alekseev 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
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
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 b
Hi hackers,
I'm having some difficulties building the documentation on MacOS.
I'm using ./full-build.sh script from [1] repository. It worked just
fine for many years but since recently it started to fail like this:
```
/usr/bin/xsltproc --path . --stringparam pg.version '16devel'
/Users/eax/pro
41 matches
Mail list logo
