Re: Add support for automatically updating Unicode derived files

From: John Naylor <john(dot)naylor(at)2ndquadrant(dot)com>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add support for automatically updating Unicode derived files
Date: 2019-12-19 22:48:39
Message-ID: CACPNZCv2jmjpqkatr-NBJ8wpP6trY8MPBbW8nhqi--hL-0+dgQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Oct 29, 2019 at 6:06 AM Peter Eisentraut
<peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
>
> Continuing the discussion from [0] and [1], here is a patch that
> automates the process of updating Unicode derived files. Summary:
>
> - Edit UNICODE_VERSION and/or CLDR_VERSION in src/Makefile.global.in
> - Run make update-unicode
> - Commit

Hi Peter,

I gave "make update-unicode" a try. It's unclear to me what the state
of the build tree should be when a maintainer runs this, so I'll just
report what happens when running naively (on MacOS).

After only running configure, "make update-unicode" gives this error
at normalization-check:

ld: library not found for -lpgcommon
clang: error: linker command failed with exit code 1 (use -v to see invocation)

After commenting that out, the next command "$(MAKE) -C
contrib/unaccent $@" failed, seemingly because $(PYTHON) is empty
unless --with-python was specified at configure time.

> Open questions that are currently not handled consistently:
>
> - Should the downloaded files be listed in .gitignore?

These files are transient byproducts of a build, and we don't want
them committed, so they seem like a normal candidate for .gitignore.

> - Should the downloaded files be cleaned by make clean (or distclean or
> maintainer-clean or none)?

It seems one would want to make clean without removing these files,
and maintainer clean is for removing things that are preserved in
distribution tarballs. So I would go with distclean.

> - Should the generated files be excluded from pgindent? Currently, the
> generated files will not pass pgindent unchanged, so that could cause
> annoying whitespace battles when these files are updated and re-indented
> around release time.

I see what you mean in the norm table header. I think generated files
should not be pgindent'd, since creating them is already a consistent,
mechanical process, and their presentation is not as important as
other code.

Other comments:

+print "/* generated by
src/common/unicode/generate-unicode_combining_table.pl, do not edit
*/\n\n";

I would print out the full boilerplate like for other generated headers.

Lastly, src/common/unicode/README is outdated (and possibly no longer
useful at all?).

--
John Naylor https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2019-12-19 23:05:34 Condition variables vs interrupts
Previous Message Jehan-Guillaume de Rorthais 2019-12-19 22:41:36 Re: Fetching timeline during recovery