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

Eli Schwartz eschwartz93 at gmail.com
Thu Mar 23 21:33:43 UTC 2017

On 03/23/2017 04:32 PM, Konstantin Gizdov wrote:
> You pointed out that "make" already reads "MAKEFLAGS" on its own. Well,
> I only added this, because it didn't for me for some reason. Maybe this
> was a bug in the build scripts and has since been fixed. But when I
> picked up ROOT and the rest of the packages, I had to manually add
> "${MAKEFLAGS}" in order for "make" to accept "-j${nproc}". I will try it
> again.

`make -j$(nproc)` should be left as a user decision anyway IMHO -- smart
build systems know how to scale up for the number of cores already, and
makepkg.conf *exists* for users to declare things like that.

Note that the default makepkg.conf has a commented-out MAKEFLAGS
variable... you don't get this automatically.

> You also point out the "hacky" way of dealing with, what I call,
> optional make dependencies. So the optional dependencies that you
> mention can be uninstalled fine and the packages will continue to work
> (excluding the relevant features, of course). However, if the packages
> are not present at build time, there is no way to enable those features
> in the first place. Since this is AUR and we don't ship binaries, I was
> not sure how better to deal with this. Any ideas?

That would be "in which case you should simply add them as makedepends."
That way they will be present at build-time and support will be compiled
in, but the user can then uninstall them (e.g. using `makepkg -sr`)
without harm, and they will be notified via optdepends that they might
want to have them installed at runtime as well to actually make use of
that support.

As a general rule of thumb, Arch policy is that there are no optional
makedepends and we like to compile things with support for everything

Eli Schwartz

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20170323/363059a2/attachment.asc>

More information about the aur-general mailing list