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,