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

[Peter Tyser <ptyser@xes-inc.com>]

On Sat, 2009-07-11 at 09:03 +0900, Shinya Kuribayashi wrote:
> Hi,
> 
> Peter Tyser wrote:
> > This series moves api_examples to api/examples and moves all
> > lib* directories into a common lib/ directory.  It also
> > moves the <ARCH>_config.mk files into their corresponding
> > lib directory.
> > 
> > Seeing 12 lib_<ARCH> directories and 12 <ARCH>_config.mk
> > files in U-Boot's top level always annoyed me,
> 
> Me, too.
> 
> 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
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.

> 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:)

Best,
Peter