Peter Tyser wrote: >> Before verifying MIPS builds, I'd like to make sure that why you take >> lib/$(ARCH)/ alternative, not $(ARCH)/lib/. If there were any >> discussion on #IRC, is there any chance we could share the summary or >> decision to follow? > > There was no discussion, /lib/$(ARCH) just made more sense to me and it > was functionally a direct translation from lib_$(ARCH) to lib/$(ARCH). > > Using $(ARCH)/lib wouldn't clean up the top-level directory structure > much and would open a can of worms that I'm not prepared to deal with at > this time. For example, if there was an architecture specific
Oops, I wanted to say "arch/$(ARCH)/lib/", not $(ARCH)/lib/, sorry. > directory, it would seem logical to put cpus of that $(ARCH) type in it > too, eg > ppc/ > lib/ > mpc8260 > mpc85xx/ > mpc86xx/ > > sh/ > lib/ > sh2/ > sh3/ > sh4/ > > ... > > My change was just meant to be an incremental improvement, but I could > see advantages to using the $(ARCH)/... structure if we wanted to make > larger changes. Anyway, I'd be curious to hear other's opinions about > other directory layouts. > > While we're talking about it, I'd always thought it would be nice to > split out all the cmd_* files from common/ into their own command/ > directory similar to u-boot-v2. Ack. The directory structure in u-boot-v2 looks nice, at least, to me, anyway. >> Please note that I agree with such cleanup, of course. I just would >> like to make sure that lib/$(ARCH)/ is an authorized policy or not. >> If authorized one, I'm fine. > > I was just scratching an itch, nothing official:) Got it. Thanks for the kind explanation, _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot