On 10/05/2016 11:16, Andrew Jones wrote: > On Tue, May 10, 2016 at 10:09:49AM +0200, Laurent Vivier wrote: >> >> >> On 08/05/2016 15:18, Wei Yang wrote: >>> In x86 Makefile, each elf target has a rule for its dependent, which shares >>> the same pattern. We could let makefile to handle this job instead of >>> writing a specific rule for each elf target. By doing so, the makefile rule >>> looks clear and would be easy for adding new cases. >>> >>> This patch does several cleanup: >>> 1. add $(cstart.o) in *.elf dependent >>> 2. remove all those elf rules which share the same pattern >>> 3. remove the *.o dependent in the elf rule who has extra dependent >>> 4. move the vmx.elf rule to Makefile.x86_64 since this is not a common case >>> 5. remove elf rules in Makefile.i386 >>> 6. Add %.elf and %.o in .PRECIOUS to keep them after make >>> >>> Signed-off-by: Wei Yang <richard.weiyang@xxxxxxxxx> >>> >>> --- >>> v2: >>> add .PRECIOUS special target to keep those intermediate files >> >> I think keeping the .o is useless, as it will be recreated each time >> (the source changes). > > The .o's may be useful for disassembly. You can generate them on demand, for instance: make x86/vmexit.o >> >> If .elf need to be kept, they should be in the targets, something like: > > The elfs are definitely useful for disassembly. > >> >> -- a/x86/Makefile.x86_64 >> +++ b/x86/Makefile.x86_64 >> @@ -6,14 +6,19 @@ CFLAGS += -mno-red-zone >> cflatobjs += lib/x86/setjmp64.o >> >> tests = $(TEST_DIR)/access.flat $(TEST_DIR)/apic.flat \ >> + $(TEST_DIR)/access.elf $(TEST_DIR)/apic.elf \ >> $(TEST_DIR)/emulator.flat $(TEST_DIR)/idt_test.flat \ >> + $(TEST_DIR)/emulator.elf $(TEST_DIR)/idt_test.elf \ >> ... > > This is ugly. > >> >> We don't need some magic here. > > Why choose ugliness over a special make target? What is ugly or beautiful is a question of point of view :) I like to rely on explicit rules rather than on an obscure GNU make property. But it is just my opinion, so let's go with ".PRECIOUS" Laurent -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
