Hi Eli,
I am aware of the '/etc/makepkg.conf'. I read the Wiki. That's not what I
am talking about. A make command in a PKGBUILD build() did not accept my
tweaked $MAKEFLAGS. I had to explicitly give 'make $MAKEFLAGS' to get my
options to work. So I added it to the PKGBUILD of my packages. Maybe it
works now without it, but it didn't.
About the makedepends - for Pythia, most of the available flags don't even
have packages in the Arch universe, so I cannot simply declare them
makedepends. The ones that exist are on AUR and I would overstate it if I
said they were maintained. So if I add them as makedepends, no one will be
able to install my package. I don't think this is the answer. I will see
what else can be done.
Regards,
Konstantin
On Thu, Mar 23, 2017 at 10:33 PM, Eli Schwartz <eschwart...@gmail.com>
wrote:
> 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
>
>
