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? Regards, Roman _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
