On 2012-12-05 2:44 PM, Roman Yeryomin wrote: > On 5 December 2012 14:29, Felix Fietkau <n...@openwrt.org> wrote: >> On 2012-12-05 1:02 PM, Roman Yeryomin wrote: >>> On 4 December 2012 19:04, Felix Fietkau <n...@openwrt.org> wrote: >>>> >>>> On 2012-11-27 2:28 PM, Roman Yeryomin wrote: >>>> > On 20 November 2012 21:45, Roman Yeryomin <leroi.li...@gmail.com >>>> > <mailto:leroi.li...@gmail.com>> wrote: >>>> > >>>> > When developing/debugging a package I would like to make >>>> > change/compile/try cycle to be shorter. >>>> > Of cause you can do something like: >>>> > - edit/save the code >>>> > - cd build_dir/target_something/package >>>> > - make clean >>>> > - rm -f .built* >>>> > - cd - >>>> > - make package/name/compile >>>> > >>>> > but this looks and feels much nicer and shorter: >>>> > - edit/save the code >>>> > - make package/name/cleansrc >>>> > - make package/name/compile >>>> > >>>> > >>>> > Use $(STAMP_BUILT) variable. Cleans some trailing spaces. >>>> On packages with reasonably sane build systems, there shouldn't be a >>>> need to run make clean for change/compile/try cycles, just use quilt and >>>> you won't need to remove the .built stamp (as every /compile call will >>>> trigger a configure+build). >>> >>> Using quilt looks to me as much longer way to go. >> If you run make package/<name>/compile QUILT=1, it will ensure that the >> build dir gets unpacked, a quilt patch stack is created, and from that >> point on, any call to make package/<name>/compile will ignore the >> .configured and the .built stamp and trigger an incremental build in the >> tree. The extra configure step can be avoided using NO_RECONFIGURE=1 >> How is this a much longer way to go? >> >>>> I'm worried about this having a default implementation that might be >>>> incomplete or defunct for many packages that overwrite the Build/Compile >>>> template, and this codepath is not going to be tested by many people. >>>> >>>> Wouldn't it be better to have a default implementation that is >>>> reasonably safe by removing all object files, libraries, etc. from the >>>> build tree? >>> >>> Well, I think that if someone is doing his own Build/Compile target he >>> should take care of cleaning too. >>> Also, in my opinion, if source code has a Makefile and doesn't >>> implement clean target or it is implemented but breaks something then >>> something is wrong with the source, not build system, and it should be >>> fixed anyway. >> It's only natural for a codepath that rarely gets tested to break much >> more easily than a codepath that is frequently used. >> I think it's too much to ask all package maintainers to add something >> that almost nobody uses and that does not, in my opinion, provide much >> value - at least not enough to justify the costs. >> >>>> What packages do you have in mind where this could be useful? >>>> For me the need to use make clean is extremely rare. Almost all of the >>>> times where I needed to clean the source tree, recreating it from >>>> scratch was a better choice anyway, as 'make clean' is unreliable with >>>> many packages >>> >>> I mostly use it (together with this one >>> http://patchwork.openwrt.org/patch/2940/) for my own packages and find >>> these 2 patches extremely useful, especially when using >>> package-version-override.mk features. >>> But I know other people using it (actually both of them), e.g. for >>> net-snmp. And, even more, originally it was their question - "how do >>> we do that?". >> By the way, package-version-override.mk is another thing that I have >> strong doubts about. What's wrong with just editing a makefile for >> testing different versions? >> >> It seems to me that you're going to great lengths to try to avoid a >> simple well-established workflow in favor of something much more fragile. >> >> For me, 'people want this' is not a good enough reason. >> Anything added to the build system encourages people to use it, and I >> don't want to add 10 different ways of doing the same thing, this would >> only lead to more confusion in the long run. >> >> If you really want these patches merged, then please be more specific >> and convince me that they're useful and not just based on a >> misunderstanding of the existing quilt based workflow. >> I promise I'll keep an open mind. > > Oook.. I thought you are talking about adding a new patch, didn't look > at OpenWrt meaning of quilt. Also NO_RECONFIGURE=1 is a good thing to > know of. > That eliminates the need for the second patch but not this one. How do > you test a clean make of package source with your local modifications > before actually releasing a patch? I make my patches using quilt. When I'm done with editing the patch stack, I do this: make package/<name>/update (copies the quilt patch stack to patches/) make package/<name>/{clean,compile} QUILT=1 V=s
This is for the workflow where I work on an OpenWrt patch for a package. If I have a package that is based on a git tree that I maintain, I have a different workflow. There is a CONFIG_SRC_TREE_OVERRIDE config option that allows you to add a git-src symlink in the package directory, pointing at a .git tree from a local clone. It allows me to commit from the build dir directly, which also works fine with the clean recompile command from above. Note that all of this is much more convenient than any workflow that involves having to run diff manually. - Felix _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
