Hi Uwe, 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.
No, it doesn't. The current shell does not actively read/source a recently changed file (unless configured to do so) and /etc/makepkg.conf is never run by itself. I am not running my build script bare through my shell, so that is irrelevant anyhow.
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.
I am not sure what your point is - /usr/bin/makepkg starts with '#!/usr/bin/bash'. The shell that starts 'makepkg' is completely irrelevant, because 'makepkg' runs itself through BASH.
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").
I am saying that when you type a command in a shell, the shell forks its own process and runs the requested command in a child - Unix fork() and exec(). Therefore, the child in this case - makepkg - is a script that should source its own environment and use it as it needs. I guess what I am trying to say with all of this is the following - uncommenting and configuring MAKEFLAGS in /etc/makepkg.conf should be enough for the 'make' call in any PKGBUILD to know about the correct MAKEFLAGS. I can actually confirm the last bit by echo-ing the $MAKEFLAGS from within a PKGBUILD and then calling 'make' where the Makefile only calls '@echo ${MAKEFLAGS}'. So I am pretty sure that I did not and should not need to export anything anywhere (unless I run 'make' manually by myself, which is not what we're talking about), because it has already been set and available. 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)
I feel like you are talking about something different from what the conversation originally was about. Maybe I am wrong. I am only referring to the difference between 'make' and 'make $MAKEFLAGS' calls in a PKGBUILD as executed with /usr/bin/makepkg. The first option was failing for me consistently and this is why I added $MAKEFLAGS as an argument to the 'make' call. Maybe some packages "clean" makeflags through CMake. That was my argument. In other words - I will not be removing $MAKEFLAGS from the 'make' call in my PKGBUILDs untill I am sure I can consistently reproduce the build with the correct flags. Hopefully soon. Thanks for the help, though. Regards, Konstantin On Tue, Mar 28, 2017 at 11:11 PM, Uwe Koloska <kolewu@koloro.de> wrote:
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