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
