Using prebuilt binaries in SDK builds

[Eric Montellese]

Hello all,

As I'm sure those on this list are aware, OpenWrt is used extensively in the commercial router world.

At NETGEAR, I am working to find a satisfactory solution to an annoying little corporate problem -- but I think the solution to that problem may be of value to the greater open-source community.

The situation is this:
When building a particular source package using the SDK, I need to rebuild any dependent packages from source as well

This has two problems:
1. It takes unnecessary time (since the package has already been built before).
2. More importantly for my use case, code sharing is not always possible within the corporate world.  Source code to a dependency may not be available.

(2) has led to some 'ugly' solutions to make it possible for companies to share libraries with one another and enable a source build.

Given that this seems like a common-enough problem I wonder if (a) the problem has already been solved (and I just haven't been able to find) or (b) if it is a problem that the community is interested in solving (rather than me going off in a hole and solving it for just our use case).  Even in the open-source world, "it'd be nice" if a user could make a change to a package without (for example) needing to rebuild openssl just to get the required files available in the staging_dir.

My suggested solution is to generate two outputs from the build:
1. The IPK, as normal
2. A staging_tarball which includes all of the files copied during the Build/InstallDev phase.

The 'staging_tarball' could be created by changing the $(1) parameter passed to Build/InstallDev to a new temporary directory which (after InstallDev returns) can be overlayed onto the actual staging_dir as well as tarred up for future use.  All of these 'staging_tarballs' would use the same naming convention as the IPKs and go into another directory under the 'bin' output directory.

I recognize that this solution is not one that is usable in all circumstances.  For example, if the package you're building changes a CONFIG rule that would have an effect on the dependent build, this would not work -- however, the same problem already exists for IPKs.

Thoughts on this proposed solution, or any alternatives, are appreciated.

Best Regards,
Eric
This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately.