Dear Mike Frysinger,
In message 201012271511.54110.vapier@gentoo.org you wrote:
Nobuhiro Iwamatsu wrote:
This move linker option used by the last of u-boot in LDFLAGS_u-boot variable. And the option to use in ld uses LDFLAGS variable.
Can you please explain why this would be needed?
he explained in the previous thread why we need to split things. there are flags that are needed for all linker options and there are flags needed just for the final u-boot link.
Such an explanation belongs into the commit message.
yes, but that isnt what you asked
This is just your quibblerish interpretation.
it isnt inconsistent. the convention is $(XFLAGS_$(@F)) and we just happen to
Can you please point me to an example where this has been used in U-Boot before? Or why do you call this a convention?
(1) it's what's used in Linux and every build system based on that (kbuild)
So let's out on record that this is NOT an accepted convention in U-Boot.
(2) u-boot is slowly moving to the conventions already in use by Linux
Oh, is it?
(3) u-boot already uses this specific convention for every .c/.s/.S file --> simply look at the bottom of config.mk
Well, applying your strict interpretation I see this:
... 258 ######################################################################### 259 260 # If the list of objects to link is empty, just create an empty built-in.o 261 cmd_link_o_target = $(if $(strip $1),\ 262 $(LD) -r -o $@ $1 ,\ 263 rm -f $@; $(AR) rcs $@ ) 264 265 #########################################################################
And I see no trace of any $(XFLAGS_$(@F)) there.
Actually I see no trace of any $(XFLAGS_$(@F)) anywhere; the closest we have is this:
245 ALL_AFLAGS = $(AFLAGS) $(AFLAGS_$(BCURDIR)/$(@F)) $(AFLAGS_$(BCURDIR)) 246 ALL_CFLAGS = $(CFLAGS) $(CFLAGS_$(BCURDIR)/$(@F)) $(CFLAGS_$(BCURDIR))
it makes perfect sense to keep the existing syntax and extend LDFLAGS behavior to it rather than coming up with some new specific variable that only applies to the final link of u-boot. otherwise every other final link we have in u- boot will need its own random style (examples, standalone, spl, ...).
Maybe you a are even right. But you might find it easier to get your arguments considered if you'd use a more constructive way to present it.
And in any way, my statementt was and is that such explanations must be included with the commit message. Period.
Best regards,
Wolfgang Denk