[LEDE-DEV] [PATCH] metadata: compile dependencies only when the package is selected

[Felix Fietkau]

On 2018-03-02 10:07, Yousong Zhou wrote:
> On 1 March 2018 at 17:36, Felix Fietkau <nbd at nbd.name> wrote:
>> To give you a better example, I just took another look at our packages
>> and found one that would directly be affected by your change:
>>
>> Take a look at libs/elektra/Makefile in packages.git
>> It has various plugins with their own dependencies.
>> One depends on boost, one on python, one on openssl, etc.
>> No PKG_BUILD_DEPENDS or PKG_CONFIG_DEPENDS.
>>
>> Let's run the same scenario as above:
>> - do a clean build with just libelektra-core selected
>> - select libelektra-boost and run make again
>>
>> Now there's two possibilities. Either the build fails on the first round
>> already, because the package was expecting to be built with boost, which
>> isn't available.
>> Or, the build fails on the second round because the first one had built
>> elektra without the boost plugins and there's nothing that triggers a
>> rebuild.
> 
> I see.  I can fix the 2nd case by letting STAMP_CONFIGURED depend on
> selection state of subpackages.  It's indeed pain if packagers need to
> guess whether they should put each CONFIG_PACKAGE_xx symbol into
> PKG_CONFIG_DEPENDS.
That will not work in all cases. For some packages, using
STAMP_CONFIGURED might not be enough (it might cache previous values).
Different packages need different ways of dealing with this, which is a
strong reason to not use this patch and keep the behavior opt-in (either
via the existing conditional depend syntax, or by adding some new
syntactic sugar).

> As for PKG_BUILD_DEPENDS, if any error happens it's not "random"
> right?  Can we be more strict here by requiring packagers to put
> correct values for this symbol?
I don't know of any case where we need to add PKG_BUILD_DEPENDS, it
could only serve as a workaround for breakage caused by your patch. But
I don't think we should go that route.

- Felix