Re: Reduce the number of special cases to build contrib modules on windows - Mailing list pgsql-hackers

From David Rowley
Subject Re: Reduce the number of special cases to build contrib modules on windows
Date
Msg-id CAApHDvq5e7RBro-rZjc4OviE5b8udnjthcoktKkoiqYnGk9a3w@mail.gmail.com
Whole thread Raw
In response to Re: Reduce the number of special cases to build contrib modules on windows  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: Reduce the number of special cases to build contrib modules on windows  (David Rowley <dgrowleyml@gmail.com>)
List pgsql-hackers
On Thu, 29 Jul 2021 at 00:05, David Rowley <dgrowleyml@gmail.com> wrote:
> I pushed the v9 0001 and 0005 patch after adjusting the AddFile($self,
> ...) to become $self->AddFile(...)

I pushed all the patches, apart from the 0004 patch.

One weird thing I noticed with the -D define patch (245de4845) and the
LOWER_NODE adjustment is that in crc32.c we do:

#ifdef LOWER_NODE
#include <ctype.h>
#define TOLOWER(x) tolower((unsigned char) (x))
#else
#define TOLOWER(x) (x)
#endif

meaning when LOWER_NODE Is defined that the CRC is hashed all in lower
case, effectively making it case-insensitive. Whereas in ltree.h we
do:

#ifdef LOWER_NODE
#define FLG_CANLOOKSIGN(x) ( ( (x) & ( LQL_NOT | LVAR_ANYEND |
LVAR_SUBLEXEME ) ) == 0 )
#else
#define FLG_CANLOOKSIGN(x) ( ( (x) & ( LQL_NOT | LVAR_ANYEND |
LVAR_SUBLEXEME | LVAR_INCASE ) ) == 0 )
#endif

So effectively if LOWER_NODE is defined then we *don't* pass the
LVAR_INCASE which makes the comparisons case-sensitive!  I've never
used ltree before, so might just be misunderstanding something, but
this does smell quite buggy to me. However, I just made it work how it
always has worked.

> 0004 still needs work.

I adjusted this one so that it does the right thing for all the
existing .l and .y files and correctly adds the relevant .c file when
required, but to be honest, I just made this work by checking that the
each of the vcxproj files match before and after the change.

There is code that parses the likes of the following in the cube
contrib module's Makefile:

# cubescan is compiled as part of cubeparse
cubeparse.o: cubescan.c

Here, since cubescan.c is not added to the project files for
compilation, I made that just call the: AddDependantFiles function,
which just searches for .l and .y files that exist with the same name,
but does not add the actual file passed to the function. This means
that we add cubescan.l to the project but not cubscan.c.

This is different from what happens with ecpg with pgc.l. We also add
pgc.c to the project in that case because it's mentioned in OBJS in
src/interfaces/ecpg/preproc/Makefile.

The only change in the outputted vcxproj files that the attached
produces is an order change in the AdditionalDependencies of
libpq_pipeline.vcxproj

I also managed to remove libpq_pipeline from contrib_uselibpgport and
contrib_uselibpgcommon. The parsing for SHLIB_LINK_INTERNAL and
PG_LIBS_INTERNAL only allowed for = not +=.

Does anyone have any thoughts on where we should draw the line on
parsing Makefiles?  I'm a little worried that I'm adding pasing just
for exactly how the Makefiles are today and that it could easily be
broken if something is adjusted later. I'm not all that skilled with
make, so I'm struggling to judge this for myself.

David

Attachment

pgsql-hackers by date:

Previous
From: Julien Rouhaud
Date:
Subject: Re: pg_upgrade does not upgrade pg_stat_statements properly
Next
From: "kuroda.hayato@fujitsu.com"
Date:
Subject: RE: [postgres_fdw] add local pid to fallback_application_name