Utilize make_build macro. JB#61933

[martyone]

No description provided.

[monich]

The problem with %make_build is that it makes the .spec file incompatible with older rpm versions which didn't have this macro. Although it should be possible to fix this problem in a manner similar to how the license macro is dealt with, may I ask what's the problem with make %{_smp_mflags}?

[pvuorela]

Well this is Sailfish packaging, if other environments need things done differently, they can do their own packaging.

Seems like %make_build has been there from 4.12, 2014, which which in my books is long enough time not to care about backwards compatibility anymore either.

[monich]

I was considering this repo as an upstream rather than a Sailfish OS specific packaging.

I can somewhat understand people who don't care about backwards compatibility - laziness is a good enough reason for that. What I find strange is why to spend efforts on breaking it.

Or well, I guess if I want to remain backward compatible, I have no choice but to find a way to detect the presence of make_build macro at build time.

[martyone]

may I ask what's the problem with make %{_smp_mflags}?

As stated in the commit message, using make_build allows the build system to override the way make is invoked specifically for building. It could be done other ways, e.g. like the SDK does it, but the effort to implement that on OBS side could hardly be justified. Hence the choice to use this well established macro.

[monich]

Actually, I see %make_build turning into e.g. /usr/bin/make -O -j6 in OBS, so it's not exactly equivalent to make %{_smp_mflags}. Now this starts making some amount of sense. Especially given that the backward compatibility workaround turned out to be quite trivial. Cheers!

[pvuorela]

I was considering this repo as an upstream rather than a Sailfish OS specific packaging.

Repo definitely is, but on packaging it gets blurrier. I would at least assume that usually distros would do their own packaging even if there exists .spec on upstream which can be used as a starting point.

I can somewhat understand people who don't care about backwards compatibility - laziness is a good enough reason for that. What I find strange is why to spend efforts on breaking it.

One reason is keeping things clean and tidy. Sure backwads compatiblity should be considered but it's also about where to draw the line. For rpm are there really really any parties using ancient rpm but wanting newer things like this?