Hi Konstantin, Am 28.03.2017 um 13:26 schrieb Konstantin Gizdov:
So I edited my /etc/makepkg.conf to have the following: ... MAKEFLAGS="-j$(nproc)" ...
this by itself only creates a variable in the current shell and not in the environment. So if you want to use the variable from a process started by this shell script, you have to export it.
I assumed every time 'makepkg' is run, it would source it's environment and that file as well. I am not sure why it would be otherwise.
It does. Without sourcing, the commands inside the script/file would be executed in their own context and can't change the context of the current script.
I normally use ZSH as my shell, but I fail to see the significance in this case. It being a bash script or not,
It's relevant, because it explains the syntax and semantic used. So if you know how (ba)sh-scripts work and know the special variables and command defined for makepkg, you are fine.
ABS should require BASH (or whatever shell it needs) to be installed and run it as needed. Both BASH and ZSH normally source their environment on load, thus I still would expect this file to be read on every 'makepkg' call, because that command forks and creates a new child process with its own envir. Correct me if I am wrong.
That's correct (but I don't understand what you wanna say by the sentence about "forks and creates a new child"). As I have said, this was only a shot in the dark. My point is (and it may not be related to your problem, because I don't know your entire buildscript) that MAKEFLAGS has to be exported if it should be used by a process started from the buildscript (make in this case). If 'make' is started in the buildscript with a commandline like make $MAKEFLAGS other options then it will work, but if make is expecting this variable in the environment, then you have to export it before. (For some scripts it looks like it's working without export, but then the export has been done before -- it's just a flag on the variable) Hope this helps Uwe