search

allyourcodebase / libpq

PostgreSQL's libpq ported to the zig build system
MIT License
4 stars 2 forks source link

Support more targets #7

Open agagniere opened 1 month ago

agagniere commented 1 month ago

Current state

For now only recent linux on amd64 and macos on intel and apple silicon are supported. It is done by dirty hacks: configuration is half hard-coded and a few generated headers are provided pre-generated.

Benefit of change

Not hard-coding configuration and generated headers would allow finally allow cross-compiling libpq on many more targets, and also make building the server code much easier.

Note that each PostgreSQL version has a different list of variable to provide for its configuration, so not hard-coding it would allow building more versions with less effort.

What should be done to get there

1. Generate configuration from the target

ALIGNOF_ TYPE

For now i've used @alignOf.

For cross-compiling we need to switch to std.Target.cTypeAlignment. Problem: it was called c_type_alignment up to zig 0.13.

I'll wait for 0.14 to release before doing that change.

SIZEOF_ TYPE

Same thing: i'll change from @sizeOf to std.Target.cTypeByteSize upon 0.14 release

HAVE_ FUNCTION

A mix of options for optional dependencies and writing a big switch.

There is also a need to know which GLIBC version is targeted. In the case of a version explicitely queried, it will appear in std.Build.ResolvedTarget's query, but in the other case, I don't know how to proceed yet, help would be welcomed

HAVE_ HEADER

Idem

DLSUFFIX

Not needed to set correctly as it it not used when building statically I guess

BLCKSZ ENABLE_THREAD_SAFETY ...

I haven't spent time understanding that, leaving it hard-coded until it breaks something

2. Generate headers at build-time

Certain headers are generated by perl scripts. They are not a function of the target OS and arch, but may change for each PostgreSQL version, so it is more about supporting different PostgreSQL versions and building the server code than about cross-compilation.

include/catalog/pg_tablespace_d.h

Generated by src/backend/catalog/genbki.pl, see src/include/catalog/Makefile. Not sure exactly what it does and what it depends on.

include/kwlist_d.h

Generated by src/tools/gen_keywordlist.pl, using module src/tools/PerfectHash.pm (see src/common/Makefile).

include/utils/errcodes.h

Generated by src/backend/utils/generate-errcodes.pl using src/backend/utils/errcodes.txt

TODO list

agagniere commented 1 month ago

Possible solutions for generated headers:

  1. Using the system's perl and call the scripts: least amount of effort
  2. Creating a build.zig for perl and using it as a build dependency: most useful for other projects like openSSL's build.zig as perl is used in lots of projects
  3. Rewrite the perl scripts in zig: most portable

Which way do we want to go ?

coolaj86 commented 1 month ago

From reading various issues on the mailing list, as well as my own interaction, I don't think that the core maintainers will be willing to help with a project like this, HOWEVER, I'd still suggest posting on the mailing list to show what you've done and get a feeler.

Assuming that they don't, I would say to pick the thing that seems like it will be easiest to maintain.

I, of course, would love to see this go full-zig (and not have to install perl on macOS through brew, when they remove it in a few releases). There may be potential to get more support from other Ziguanas with zig that perl.

But for the foreseeable future... it's just you maintaining this, so... whatever works for you best is what's best, right?