[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