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

[Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>]

On 23:39 Tue 14 Jul     , Peter Tyser wrote:
> On Wed, 2009-07-15 at 12:38 +0900, Shinya Kuribayashi wrote:
> > Peter Tyser wrote:
> > > On Sun, 2009-07-12 at 14:54 +0200, Jean-Christophe PLAGNIOL-VILLARD
> > > wrote:
> > >> On 22:42 Fri 10 Jul     , Mike Frysinger wrote:
> > >>> On Friday 10 July 2009 21:20:45 Shinya Kuribayashi wrote:
> > >>>> 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.
> > >>> i thought that originally, but i dont care much either way.  having 
> > >>> arch/$(ARCH)/ would line up with u-boot-v2 and the linux kernel though.
> > >>>
> > >>> i dont understand needing a lib/ subdir under arch/$(ARCH)/ though.
> > >>>
> > >>>>> 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.
> > >> I prefer the
> > >> arch/$(ARCH)/lib
> > >> so will could also move the cpu stuff there too
> > > 
> > > I like the Linux and u-boot-v2 directory layout too the more I think
> > > about it too.  How about if I resend this series but with the final
> > > directory structure looking like:
> > > 
> > > /arch/$(ARCH)/lib/<source files currently in lib_$(ARCH)
> > > 
> > > /lib/
> > > 	/<source files currently in lib_generic>
> > > 	/libfdt/
> > > 	/lzma/
> > > 	/lzo/
> > > 
> > > /examples/
> > > 	/api/
> > > 	/standalone/
> > > 
> > > 
> > > That will lay the groundwork for moving additional files
> > > into /arch/$(ARCH)/ down the road.  eg I think it would be nice to move
> > > the directories in /cpu/* into their respective /arch/$(ARCH)/
> > > directory, and possibly the /include/asm-$(ARCH) directories in the long
> > > run.
> > > 
> > > What do others think of this?
> > 
> > There were some discussions we'd better to reflect back on about this
> > topic.
> > 
> > I can't toss the URLs of them at the moment as I'm behind a firewall,
> > but these might help:
> > 
> >     Date: Thu, 13 Sep 2007 17:28:47 -0600
> >     From: "Grant Likely" <grant.likely@secretlab.ca>
> >     To: uboot <u-boot-users@lists.sourceforge.net>,
> >         "Jon Loeliger" <jdl@jdl.com>,
> >         "Wolfgang Denk" <wd@denx.de>
> >     Subject: [U-Boot-Users] [RFC] u-boot migration to kconfig
> 
> Jean-Christophe submitted some patches for consideration earlier this
> year.  No one really bit as far as taking the necessary steps to get the
> Kbuild system fully functional if my memory is correct.  I don't think
> those patches are going to make it into the upcoming release in any
> case.
> 
> I'd vote to get the directory structure changed as desired (in this
> release), then integrate the Kconfig-based build system in the next
> release once the directory layout is stable.  Jean-Christophe is the
> most familiar with the Kbuild system and might have a better idea what
> its state is, how hard it would be to adapt to a new directory layout,
> etc.  Do you have any input Jean-Christophe?
more we will be close to the linux organisation more easier it will be to
integrate it and update it
the only really important think is to merge to KConfig first.

Please note that the Kconfig is already ready I just not have the time to
rebase the patch before tomorow as I've to do my custudian work first

Best Regards,
J.