On 15/12/14 14:55, Martin Lucina wrote: >>>> I would first like to have a unified configure/build interface on all of >>>> the platforms. Furthermore, makekernlib uses a different make. There >>>> might be unnecessary trouble with cross-exporting parameters (e.g. >>>> destdir/filename/objdir) and dealing with things if they change. >>>> >>>> What is the goal of making everything Makefile-driven? >>> >>> I would like to be able to rebuild at least the parts that directly depend >>> on changes to Mini-OS / rumprun with just "make clean" and "make". At the >>> moment if I change something in the lower layers I have to rebuild by >>> blowing away the whole build tree and re-running buildxen.sh. >> >> What's wrong with re-running buildxen.sh without blowing away the whole >> build tree? > > Nothing, its just slower than I'd like -> I don't test it as often.
It's slow because building hundreds of megs of source code organized into different directories with make is slow ;) (compare to how long e.g. glibc "make" from the top level takes when there's nothing to rebuild -- and we're building quite a bit more than just libc) I don't think a build system should go to exceeding lengths to be clever enough to meet the needs of developers working on a specific part of the source tree. The build system will always fall short and be annoyingly slow and you anyway have to come up with specialized methods to build the parts you need. I do think it's perfectly acceptable to leave full testing to CI/autotest *when there is a reasonable suspicion that nothing will be broken*. ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk _______________________________________________ rumpkernel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
