From mboxrd@z Thu Jan  1 00:00:00 1970
From: Shinya Kuribayashi <skuribay@pobox.com>
Date: Sat, 11 Jul 2009 10:20:45 +0900
Subject: [U-Boot] [PATCH v2 0/6] Clean up top-level directory structure
In-Reply-To: <1247272852.32367.241.camel@localhost.localdomain>
References: <1247241800-29059-1-git-send-email-ptyser@xes-inc.com>
	<4A57D6EE.1020601@pobox.com>
	<1247272852.32367.241.camel@localhost.localdomain>
Message-ID: <4A57E8ED.3040604@pobox.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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,