Hi, [EMAIL PROTECTED] wrote: > We are working with ClearCase. While developing a new driver etc. we're > creating a symbolic link from our dynamic ClearCase view to the acc. > build_XXXX/my_driver/my_application directory. This is to avoid to > building every time new tar.gz during the development phase. It makes > the development just faster. > If all changes / enhancements working well we commit the changes and > deliver them to the ClearCase integration stream. Within the integration > stream we finally build the tar.gz packages for the outside world. > Assuming your are changing something within the sources of the > build_XXXX directories they will be killed very soon ;-) by changing the > package Makefile etc. Therefore it's not a good idea to work within the > current build_XXXX sources. Dividing this stuff into the sources and > build dirs you will get a clean approach. This would help to use the > OpenWrt development not only as an integration framework but also as a > package development platform. To speed up the development of new features, I integrated 'quilt' support for the buildroot. If you unpack the package using 'make package/foo-prepare QUILT=1', it will apply all patches of that package using quilt and disable the automatic rebuild. You can use the regular quilt commands like push, pop, edit, etc. as described in http://www.suse.de/~agruen/quilt.pdf This has the advantage of allowing you to edit multiple patches for one package without forcing you to use multiple directories for that. When you're done editing, 'make package/foo-update' will copy the final patches back into the buildroot. I prefer that solution over splitting source directory and build directory, because it works for all packages without any extra code for handling the autoconf stuff. When editing files they have to be explicitly added using quilt add/edit, so binary junk is always ignored.
> There is a second reason. I've patched also the buildroot environment to > build in "parallel" multiple hardware platforms (based on the same > target arch). Means you have unpacked/patched the sources once but the > build output and the root file systems exist in parallel. This enables > you to boot several different hardware boards through NFS not leaving > the build environment. Just by switching the .config you switch between > the different board development. Sounds interesting, maybe we could make this an optional extension. It definitely shouldn't be enabled by default for all packages, because when I tested it quite some time ago, I found that quite a few packages didn't handle this properly. Cheers, - Felix _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
