-
Notifications
You must be signed in to change notification settings - Fork 479
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: fix the build system #212
Conversation
Currently, the logo is always printed when the build script is executed, resulting in the logo being printed twice with `zig build -h` and `zig build -l`. Make the logo a build step, so that the logo is printed to stderr only when necessary. Closes ratfactor#211
That's ok, but I will do the automatic tests. |
The version check for Zig 0.6.0 was incorrect since commit 971ab7f (Use a zig build script to run ziglings). Move compatibility support to a separate file, in order to simplify build.zig. In case of incompatible version, exit with code 3 instead of 0, in order to detect the case of failure in a test (to be implemented). Remove the use of comptime when checking compatibility at the start of the build function, since it is not necessary. Closes ratfactor#210.
Good. I'm planning to add some simple tests, starting with testing that old versions of zig will fail to build |
Remove the logo step, and use PrintStep for the header step. The logo step was added as a quick fix after the Builder.addLog function was removed. Now the logo is no longer shown when running `zig build -l` or `zig build -h`.
Replace the description of the named_install step from "Install {s} to zig-cache/bin" to "Copy {s} to prefix path". The latter has been adapded from the description of the builtin install step. Ad an empty line before the build_step variable, in order to improve readability. Closes ratfactor#213
If you think the code is good and it works correctly, you can merge into |
I assume it only works right with some of your PRs in Zig, right? |
Another question: To start a exercise specifically, the command e.g. |
It works once the branch in the PR is merged. |
I checked out your |
What I can change is renaming the option to |
Yes, I think that would be better (nicer). |
Done. Another possible solution is to remove the chain, and instead add an executable (the driver) that it is build and run by the Zig build system. The driver will keep the exercise state on the filesystem. |
You mean the first call of |
|
What do you mean? |
You write "The default step is zigling (note the singular form)." but when I run |
I checked again more carefully, and it is indeed a bug, sorry. I will try to fix it. |
The new parallel build support in Zig broke the exercise chain, so that each esercise check is no longer strictly serialized. 1. Add the Dexno option, in order to isolate the chain starting from a named exercise from the normal chain, thus simplify the code. The current code have an additional issue: it added 4 x n steps, making reading the help message or the list of steps very hard. Add only the `install`, `uninstall`, `zigling`, `test` and `start` steps. The last three steps match the old steps `n`, `n_test` and `n_start`. The default step is zigling (note the singular form). The `install` step override the builtin install step, showing a custom description and matches the old `n_install` step. The uninstall step was added for consistency, so that the description is consistent. Setup a new chain starting at `zig build -Dexno=n start` so that it is stricly serialized. The behavior should be the same as the old one. 2. Handle the code for all the exercises separately. Add only the `ziglings step`, making it the default step, in addition to the install and uninstall steps. Setup a new chain starting at the first exercise, to that it is strictly serialized. The behavior should be the same as the old one. The current code has a know issue: the messages from the ZiglingStep and the ones from the compiler compilation progress are interleaved, but each message is written atomically, due to the use of `std.debug.getStderrMutex()`. Update the README.md file. Closes ratfactor#202
I removed all the unnecessary no-op custom steps that where present in the previous code. During my tests, the behavior seems correct, but, again, this needs more people to check the code. |
I noted now that the last commit in this PR broke the compatibility support for old Zig compilers. The problem is the use of the new for loop syntax, that is causing the grammar parsing step to fail. Fortunately there is a simple solution, without the need to use a variable for the loop index. I will apply after the branch has been merged. |
This is primarily to make users aware that there has been a change in the call for individual exercises.
@perillo Thank you very much for your great effort! |
Thanks to you for noticing that I forgot to update the message. However, was updating the needed version really necessary? |
Yes I think so, because the users have now all started with BTW, in the README there are the following additional hints: Advanced usage |
They are already available: $ zig build -Dn=1 -l
|
Ok, I have not tested that. Then I just have to rewrite the README. |
build: make the logo a build step
build: make the logo a build step
In this branch I plan to simplify, improve and fix the ziglings build system.
Tasks
build.zig: incorrect handling of the ziglings logo #211
build: using zig 0.6.0 will cause a compiler error #210
Tested
zig build
with 0.6.0 to 0.10.0.build: incorrect description of the named_install step #213
I forgot to mark build: incorrect description of the named_install step #213 as closed; I will have to update the commit message and force push it.
Note that the comment of making Zig 0.5.0 compatible with the version check by moving the code to a separate file is incorrect, since the compiler will parse all the files.
ATTENTION: Ziglings currently only works manually with the new build system of Zig since 0.11.0-dev.2157 #202
This is the last commit of this branch. There are still several issues I would like to solve, and I will use a different branch.