| Summary: | Allow override of DL_DIR in extract step | ||
|---|---|---|---|
| Product: | buildroot | Reporter: | Danomi Mocelopolis <d_mo1234> |
| Component: | Other | Assignee: | unassigned |
| Status: | RESOLVED WONTFIX | ||
| Severity: | enhancement | CC: | buildroot |
| Priority: | P5 | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Host: | Target: | ||
| Build: | |||
| Attachments: | patch file | ||
Can you provide more details as to what you are trying to achieve, and how? If you are simply setting DL_DIR from the .mk file of an individual package, this won't work as expected because all subsequent packages will now have that DL_DIR too (non-recursive make). (In reply to comment #1) > Can you provide more details as to what you are trying to achieve, and how? We have internally developed proprietary packages that we maintain and release, as versioned tarballs. We keep the tarballs themselves in source control, in their own directory. The idea being that we have one DL_DIR with opensource code that could be freely given to anyone who wanted it, and a separate DL_DIR for internal stuff that stays proprietary. > If you are simply setting DL_DIR from the .mk file of an individual package, > this won't work as expected because all subsequent packages will now have that > DL_DIR too (non-recursive make). Actually, we do something like this in the .mk files of our internal packages: $($(PKG)_BUILD_DIR)/.stamp_% : DL_DIR=$(OUR_SPECIAL_DL_DIR) We've been doing this since 2011, and it has worked quite well - proprietary packages get pulled from one directory, opensource comes from / gets downloaded to another directory. The only penalty to us is that we have to add an extra "$" in the $(2)_EXTRACT_CMDS definition, as per the patch. This bug can be closed, really - this request is perhaps too specific to our use of buildroot. Besides, this was a change request, not really a bug - I was new to the buildroot community in 2011, and thought that the change process was driven by bugzilla rather than submitting patches to the mailing list. (The documentation on the BR website has improved tremendously since then, so I wouldn't make that mistake today.) Thanks. Other buildroot developers agree that this patch is very project specific and should not be applied to mainline buildroot. Please consider the following alternatives: * The "file" site method can be used to "download" tarballs from a local directory, when needed. * The licensing infrastructure allows to create a directory with all the open-source tarballs, keeping them separate from proprietary bits, for delivery to customers. * You may also be interested in the new BR2_EXTERNAL mechanism, introduced in buildroot 2014.02 (to be released at the end of this month). Also note that supporting highly-specific use cases in the package infrastructure is not a good idea, because we might very easily break them in the future if they are too specific and therefore not used by enough people to be tested when we make changes. |
Created attachment 3649 [details] patch file I am updating from an older version of buildroot to the latest. I find it useful to override the value of DL_DIR for certain packages, to sequester the downloaded package in a different area than all the other third party packages. However, I found that the [relatively] recent introduction of "$(2)_EXTRACT_CMDS" in package/Makefile.package.in broke this, because the definition is using $(DL_DIR) instead of $$(DL_DIR) like in other templates in the file. So I would like to add the extra $. Don't think that should be too controversial. Patch file is attached.