On 2018-03-02 10:07, Yousong Zhou wrote: > On 1 March 2018 at 17:36, Felix Fietkau <n...@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 _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev