Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build system improvements #86

Merged
merged 2 commits into from
Jul 30, 2024
Merged

Build system improvements #86

merged 2 commits into from
Jul 30, 2024

Conversation

urso
Copy link
Collaborator

@urso urso commented Jul 29, 2024

Closes: #56

Move PGBuild.target and PGBuild.optimize to PGBuild.options struct.

Introduce PGBuild.modules struct to load a the exported modules via simple function calls like pgbuild.modules.pgzx().

Rename Run to RunExec to better indicate what that step does.

Simplify addRegress by removing the RunRegress type.

Introduce addExtensionLib to the shared lib to compile without installing it right away. This allows users to modify/use the lib with other targets that are not required to install the extension. For example a check target or build source documentation without linking and installation.

Introduce Project to combine the meta-data into a common type that can be used to create the different project resources within the build script. E.g. In order to create build/check/docs only steps one is required to redeclare the extension library to have an independent resource. Using the Project type we can use proj.extensionLib to create multiple instance of the build configuration (including dependencies).

Update the example build scripts:

Move `PGBuild.target` and `PGBuild.optimize` to `PGBuild.options`
struct.

Introduce `PGBuild.modules` struct to load a the exported modules via
simple function calls like `pgbuild.modules.pgzx()`.

Rename `Run` to `RunExec` to better indicate what that step does.

Simplify addRegress by removing the RunRegress type.

Introduce `addExtensionLib` to the shared lib to compile without
installing it right away. This allows users to modify/use the lib with
other targets that are not required to install the extension. For
example a check target or build source documentation without linking and
installation.

Introduce `Project` to combine the meta-data into a common type that can
be used to create the different project resources within the build
script. E.g. In order to create build/check/docs only steps one is
required to redeclare the extension library to have an independent
resource. Using the `Project` type we can use `proj.extensionLib` to
create multiple instance of the build configuration (including
dependencies).

Update the example build scripts:
- improve structure by pre-declaring build steps
- Use new `Project` type.
- Add `zig build check` command that compiles and type checks, but
  ommits LLVM and linking. Use with ZLS to improve developer experience
  like: https://kristoff.it/blog/improving-your-zls-experience/
@urso urso requested a review from tsg July 29, 2024 14:29
@urso urso changed the title Build system improvements: Build system improvements Jul 29, 2024
@urso urso merged commit 14fb83f into xataio:main Jul 30, 2024
1 check passed
@urso urso deleted the build-proj branch July 30, 2024 10:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Build system: Separate build from install
1 participant