>> I have never used the version part of this file actually, I use it >> solely to set the source path to a local tree. Same here. We actually used it to interface OpenWrt with SCM which are not supported natively by OpenWrt like P4.
> Right, that is a valid usecase, but package-version-override.mk is a very > poor and hackish way of doing that. I have just made a commit that adds back > support for overriding the package source directory, but in a different way: > make package/<name>/prepare USE_SOURCE_DIR=/path/to/source/dir > That way you won't have to add the package-version-override hack to any > package you want to use this on. You also don't need to make changes to make > menuconfig anymore. > What I don't like about the build directory override approach is the lack of > proper 'clean' handling. I have a different workflow that supports cleaning > packages just fine, described below: Agreed. It's actually better. Thanks for the pointer. > What I'm doing is this: I set CONFIG_SRC_TREE_OVERRIDE=y, and in the package > directory create a symlink git-src, pointing at the .git subdirectory of a > git clone of the package. > The build system creates a new build directory in the standard location, > creates the .git symlink and runs git checkout . > That way I can work on the same tree for multiple targets in multiple build > dirs and commit locally (just need to run git checkout . in the other > checkouts after I made some changes). Even better :) -----Original Message----- From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf Of Felix Fietkau Sent: Friday, April 18, 2014 8:02 AM To: Karl P; openwrt-devel@lists.openwrt.org Subject: Re: [OpenWrt-Devel] [PATCH 1/4] include: Restore package-version-override.mk On 2014-04-18 15:59, Karl P wrote: > > > On 04/18/2014 12:04 PM, Felix Fietkau wrote: >> On 2014-04-17 21:12, Mathieu Olivari wrote: >>> This feature is actually quite useful. Obviously it's an opt-in >>> approach from a package standpoint, but it's pretty useful to swap >>> package versions as well as pulling components TOT. In that case, >>> working directly on the GIT tree by enabling that option is >>> sometimes seen as a more flexible way than having to modify the >>> Makefile to point to the git tree location. >> How is it more flexible? Also, since this applies only to packages >> that include this file directly, it would be much better if the >> package would simply allow selection between a number of *supported* >> versions, rather than just letting the user put in arbitrary values. >> >> I considered the addition of this file a mistake from the very >> beginning, we only left it in for SDK collaboration with Lantiq >> (which has dried out). > > I have never used the version part of this file actually, I use it > solely to set the source path to a local tree. I use this for > packages that I develop both the application, and the packaging, as I > find it significantly simpler to do a "make menuconfig" step in my > primary build root, and enter a path, rather than making sure I have a > src-link in my feed to the package, and then modify the (revision > controlled) package makefile as well. Mostly because modifying a > package makefile to not download from version control but to build > from some local existing source requires multiple edits to the package > makefile, which I then need to make sure that I don't commit, even if I had > _other_ parts of the package makefile I did want to commit. Right, that is a valid usecase, but package-version-override.mk is a very poor and hackish way of doing that. I have just made a commit that adds back support for overriding the package source directory, but in a different way: make package/<name>/prepare USE_SOURCE_DIR=/path/to/source/dir That way you won't have to add the package-version-override hack to any package you want to use this on. You also don't need to make changes to make menuconfig anymore. What I don't like about the build directory override approach is the lack of proper 'clean' handling. I have a different workflow that supports cleaning packages just fine, described below: > As earlier, if someone can outline an alternative streamlined method > of working on application source directly, I'm happy to hear it, > especially if it's actually documented anywhere. However, failing > that, I felt that the removal of this as "lantiq only" was extremely > arbitrary, as it's now rather obviously getting used by other people too. What I'm doing is this: I set CONFIG_SRC_TREE_OVERRIDE=y, and in the package directory create a symlink git-src, pointing at the .git subdirectory of a git clone of the package. The build system creates a new build directory in the standard location, creates the .git symlink and runs git checkout . That way I can work on the same tree for multiple targets in multiple build dirs and commit locally (just need to run git checkout . in the other checkouts after I made some changes). - Felix _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
