Hi Konstantin, sorry for not being clear enough for you to understand what I wanted to say. I haven't looked at your PKGBUILD but just tried to give you some hints from where you may be able to find the cause of your trouble. Maybe I should try again ;-) PKGBUILD is just a bash script that is sourced by the bash-script makepkg. So all things true for a bash script are true for PKGBUILD. If a command started by the script is supposed to use some variable from the environment, this variable has to be exported in the script (anywhere in all the files that are sourced by makepkg). So, if make is not able to pick up the variable MAKEFLAGS from the environment, the only explanation is, that the variable is not part of the environment, when make is started. And this is only possible if it was never exported or the export is removed before make is started. And this removal is only possible from the shell that runs makepkg (and have sourced /etc/makepkg.conf and your PKGBUILD). No process started from the script (e.g. cmake, mentioned by you) is able to manipulate the environment of the script! That's all. And now it's your part to use this information and search for the reason, why MAKEFLAGS is not part of the environment, when make is started. In the meantime I have looked into the makepkg script. And there I found these two interesting pieces in run_function: # clear user-specified makeflags if requested if check_option "makeflags" "n"; then unset MAKEFLAGS fi and then # ensure all necessary build variables are exported export CPPFLAGS CFLAGS CXXFLAGS LDFLAGS MAKEFLAGS CHOST So MAKEFLAGS *is* exported and so should be available in the environment of make when started by the script -- *if not* the option "!makeflags" is given, then it always isempty (but exported!). So, if you don't have this option set, there is nothing in makepkg that unsets or unexports MAKEFLAGS and you have to search in all files that are under your control and sourced from the makepkg script. And if you knew all this before, than sorry for bothering, but I have had another impression. Hope this helps Uwe