Dear Mike Frysinger, In message <201012271511.54110.vap...@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 -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Bei genauerem Hinsehen ist die Arbeit weniger langweilig als das Vergnügen. -- Charles Baudelaire _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
