[OpenWrt-Devel] [OpenWrt-Commits] r48171 - trunk/include
nbd at openwrt.org
Mon Jan 11 18:12:59 EST 2016
On 2016-01-10 21:00, Daniel Curran-Dickinson wrote:
> Hi Felix,
> I sent this to the list, but since you seem to have taken an interest in
> this, I'm also sending direct; don't take that as a need to rush, just
> thought you might be interested.
Please don't send duplicate emails to me and the list separately, it
makes dealing with email threads really annoying. Think about whether
you want to Cc me or not before you hit send the first time...
If you sent something to the list and forgot to Cc me, you can also
point me at the mail on IRC. I'm already having a hard time keeping the
size of my inbox under control...
> I will try to try this patch soon, since you've got something out before
> me. I believe this resolves the issues I mentioned previously, bit not
> another issue I ran into when working on my own patch; namely the fact
> that if a package is not built then
> <staging_dir>/pkginfo(?)/<package>.provides is not generated and
> therefore the package-ipkg dependecy search logic fails to see that the
> dependency has been satisfied (e.g. kmod-cryptodev requires that e.g.
> kmod-crypto-authenc which depends on kmod-crypto-manager which depends
> on kmod-crypto-aead which supplies aead.ko be built during *this* build
> (i.e. by SDK, albeit by just packaging the *.ko shipped with SDK) so
> that kmod-aead.provides contains the text 'aead.ko', which gives the
> information package-ipkg needs to believe that kmod-cryptodev's
> dependencies have been met.
> The issue is legacy $(if $(SDK) in include/kernel.mk which actually
> prevents building of kernel packages from the SDK. Long term it would
> probably be better to have a way ship the .provides and create necessary
> stamp, since the kernel binaries themselves are not actually needed by
> the SDK; they exist only permit the build system to resolve dependencies
> (that is I see no reason ship .ko files in order for the SDK to create
> duplicate copies of packages already built elsewhere, nor am I aware of
> other reasons for the SDK to use .ko files, except that it's the easiest
> way to get the build machinery to acknowledge dependencies and deal with
> all the various stamps and such).
I disagree with your proposed long term plan. I want to have fewer SDK
related special cases, not more. I've taken care of the kmod-* build
issue that you described in r48206 and r48207.
Thanks for looking into this,
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
More information about the openwrt-devel