[aur-general] Review and a bit of other help request

[Konstantin Gizdov]

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 at 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
>