Hello,
I have a bash script (too advanced for sh) that generates files for testing my project by defining a wrapper function for a command and calling it multiple times with different arguments.
Previously I have done that with a Makefile that called the prepare.sh.
I have already figured out how to call shell commands from build.zig, but not the script.
For this reason I ask:
Is it feasible to replace that script with the zig build system?
If not, how can I call the script?
Why you can’t just write some script.zig instead of script.sh?
Great, then you can just use the shell command bash prepare.sh to run the bash script.
Yeah should be trivally easy to run a bash script via b.addSystemCommand. Couple things to keep in mind, it’s probably better to not include bash itself in the command but rather use the shebang header within the script (the #!/usr/bin/env sh line at the top of the script). Also keep in mind this will mean your project can only be built on systems that have BASH available (i.e. RIP windows).
Also, addSystemCommand creates a Run step which has some automatic caching logic based on the command-line parameters. When you add arguments to a RunStep you can specify whether they are strings/files/directories etc. If they are all strings, if you run the same command with the exact same strings, it won’t run it a second time. If you run it with filenames, then RunStep will read/hash the contents of those files and only run that command if those files have changed. You can disable this caching behavior by settings the has_side_effects field, but this can make rebuilds a bummer because if any steps depend on its output then those steps will have to be re-executed every time you run the build. To summarize, the best way to make this work is to make sure all the inputs for this tool can be derived from the command-line arguments you pass to it…and there are some tricks of the trade for this if you’re having trouble figuring out how to do that.
I would if I knew how.
Right now I am starting with the basics but this probably is the best approach.
I will do that for now.
If a shebang is specified then the shell calls the shebang command.
If there is none then the current shell is used.
That would mean that running bash script.bash on a script with no shebang will be the best.
My previous project was GNU/Linux only so this still is an improvement.
I think that in the future I would like to improve the portability and I do not feel like rewriting this in POSIX sh so prepare.zig is probably a good idea.
Another benefit would be that I could use the variables from the script directly in the unit tests.
By it do you mean the script executable…?
Right now all the output files are hardcoded and it ignores the arguments.
By it do you mean the script executable…?
Right now all the output files are hardcoded and it ignores the arguments.
Yes exactly. Move all the hardcoded paths from inside the script to your build.zig and pass them on the command-line instead.
Relevant section of the Zig Build System guide: Generating Files > Running System Tools