Re: [PATCH 02/23] x86, realmode: realmode.bin infrastructure

[H. Peter Anvin]

On 05/09/2012 12:57 PM, Jarkko Sakkinen wrote:
> 
> diff --git a/arch/x86/realmode/Makefile b/arch/x86/realmode/Makefile
> index f22a4f8..615878e 100644
> --- a/arch/x86/realmode/Makefile
> +++ b/arch/x86/realmode/Makefile
> @@ -15,6 +15,3 @@ $(obj)/rmpiggy.o: $(obj)/rm/realmode.relocs
> $(obj)/rm/realmode.bin
> 
>  $(obj)/rm/realmode.bin: FORCE
>         $(Q)$(MAKE) $(build)=$(obj)/rm $@
> -
> -$(obj)/rm/realmode.relocs: FORCE
> -       $(Q)$(MAKE) $(build)=$(obj)/rm $@
> diff --git a/arch/x86/realmode/rm/Makefile b/arch/x86/realmode/rm/Makefile
> index de40bc4..1c1d3d3 100644
> --- a/arch/x86/realmode/rm/Makefile
> +++ b/arch/x86/realmode/rm/Makefile
> @@ -48,7 +48,7 @@ $(obj)/realmode.elf: $(obj)/realmode.lds
> $(REALMODE_OBJS) FORCE
> 
>  OBJCOPYFLAGS_realmode.bin := -O binary
> 
> -$(obj)/realmode.bin: $(obj)/realmode.elf
> +$(obj)/realmode.bin: $(obj)/realmode.elf $(obj)/realmode.relocs
>         $(call if_changed,objcopy)
> 
>  quiet_cmd_relocs = RELOCS  $@
> 
> Would this resolve the existing issues or not?
> 

That should would work, although it is definitely a hack.  It all really
comes down to make not having a good way to deal with a single process
generating more than one output.  I discussed this about a decade(!) ago
with the GNU make maintainers, and they said that make *can* be made to
do the right thing by doing a pattern rule:

%.foo %.bar: %.baz

... as pattern rules with multiple targets are handled differently than
non-pattern rules with multiple targets.  They were -- and still are --
reluctant to actually fix the problem since it wouldn't be backwards
compatible, but of course that is true with any new Make feature.

Not sure how to use the pattern rule in this case, so I guess we might
as well go with the hack.  Can you send it as a proper patch (with a
description and Signed-off-by:), please?

	-hpa

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/