Re: split func.sgml to separated individual sgml files
От | Peter Eisentraut |
---|---|
Тема | Re: split func.sgml to separated individual sgml files |
Дата | |
Msg-id | 0198ec0f-0269-4cf4-b4a7-22c05b3047cb@eisentraut.org обсуждение исходный текст |
Ответ на | Re: split func.sgml to separated individual sgml files (Nazir Bilal Yavuz <byavuz81@gmail.com>) |
Ответы |
Re: split func.sgml to separated individual sgml files
|
Список | pgsql-hackers |
On 06.10.25 10:29, Nazir Bilal Yavuz wrote: > Hi, > > On Fri, 3 Oct 2025 at 18:47, Andrew Dunstan <andrew@dunslane.net> wrote: >> >> On 2025-10-03 Fr 10:41 AM, Tom Lane wrote: >> >> Peter Eisentraut <peter@eisentraut.org> writes: >> >> If you look at this more closely, creating postgres-full.xml and running >> the syntax check perform the same operations, except that the latter >> throws away the output. So it seems redundant to build a whole new code >> path for this. I think you can make the check target dependent on >> postgres-full.xml and be done, kind of like this (starting from >> pre-b2922562726): >> >> Would it be unreasonable to discard the "check" target altogether? >> It made sense back in the day when actually building the html docs >> took many minutes. But I haven't used it in years, so I wonder >> if anyone else has either. >> >> I have no objection. We'll need to work out what we're doing on the meson side, which is kinda where we came in ... > > I can work on this but I want to clarify it first. Which one do you prefer: > > 1- We won't have any command to do syntax checks (including tab and > nbsp), these checks will automatically run when we generate docs. > > 2- We will have a 'check' target but it will only do tab and nbsp > checks; xmllint will run only when generating the docs. I don't know, people have a lot of individual workflows, and they are not reading this thread. I still don't know what we are actually trying to fix here, I just noticed that what was committed is flawed. I would prefer that b2922562726 be reverted, and then someone start a new thread with a descriptive change proposal.
В списке pgsql-hackers по дате отправления: