On 2 March 2018 at 17:19, Felix Fietkau <n...@nbd.name> wrote: > 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). >
Well, I thought for autotools we the autoreconf fixup can workaround this, but it seems maybe the situation is just not that simple ;) >> 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 Got it. At least the current behaviour provides a consistent configure environment for each package. That's a good feature to have. Thanks, yousong _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev