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 possible. -- Eli Schwartz
signature.asc
Description: OpenPGP digital signature
