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

move the list of installation files from CMakeLists.txt into build.zig #2874

Closed
2 tasks
andrewrk opened this issue Jul 12, 2019 · 0 comments · Fixed by #2892
Closed
2 tasks

move the list of installation files from CMakeLists.txt into build.zig #2874

andrewrk opened this issue Jul 12, 2019 · 0 comments · Fixed by #2892
Labels
enhancement Solving this issue will likely involve adding new logic or components to the codebase. frontend Tokenization, parsing, AstGen, Sema, and Liveness. stage1 The process of building from source via WebAssembly and the C backend. zig build system std.Build, the build runner, `zig build` subcommand, package management
Milestone

Comments

@andrewrk
Copy link
Member

CMakeLists.txt has a giant list of files that we want to ship with zig. This is annoying for several reasons:

  • It's data in the middle of code. It obscures the rest of the build script.
  • If you edit this file, it triggers a rebuild of the c++ compiler even though that shouldn't be necessary.
  • CMake has no way to disable printing all the files to stdout, even when nothing is changed. This causes make install to take a long time even when the file system operations complete quickly.
  • Really those should be recursive globs. But CMake's gobbing is problematic for a few reasons, one of which is that new files are not detected.
  • The list of files is not available to stage2.

All of these issues can be solved by moving this from CMakeLists.txt to build.zig.

  • implement globbing of installation files in zig build scripts (properly, with detection of new files)
  • instead of cmake doing the install, it will call zig0 build install-the-files (or a better named step), just like it already does to build libuserland.

Another reason we list files explicitly is that there are some large test files that we wish to not install. For example std/special/compiler_rt/udivmodti4_test.zig is 9.8 MiB.

This can be solved with the zig build glob feature supporting a list of exceptions. Or perhaps even a globbed list of exceptions and we can except *_test.zig.

@andrewrk andrewrk added enhancement Solving this issue will likely involve adding new logic or components to the codebase. frontend Tokenization, parsing, AstGen, Sema, and Liveness. stage1 The process of building from source via WebAssembly and the C backend. zig build system std.Build, the build runner, `zig build` subcommand, package management labels Jul 12, 2019
@andrewrk andrewrk added this to the 0.5.0 milestone Jul 12, 2019
andrewrk added a commit that referenced this issue Jul 15, 2019
This moves the installation of shipped source files from large
CMakeLists.txt lists to zig build recursive directory installation.

On my computer a cmake `make install` takes 2.4 seconds even when it has
to do nothing, and prints a lot of unnecessary lines to stdout that say
"up-to-date: [some file it is installing]".

After this commit, the default output of `make` is down to 1
second, and it does not print any junk to stdout. Further, a `make
install` is no longer required and `make` is sufficient.

This closes #2874.

It also closes #2585. `make` now always invokes `zig build` for
installing files and libuserland.a, and zig's own caching system makes
that go fast.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Solving this issue will likely involve adding new logic or components to the codebase. frontend Tokenization, parsing, AstGen, Sema, and Liveness. stage1 The process of building from source via WebAssembly and the C backend. zig build system std.Build, the build runner, `zig build` subcommand, package management
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant