[U-Boot] [PATCH v2 0/6] Clean up top-level directory structure

Shinya Kuribayashi skuribay at pobox.com
Sat Jul 11 03:20:45 CEST 2009


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,


More information about the U-Boot mailing list