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

Peter Tyser
2009-07-18T16:52:56Z

Hi Rafal,

> > 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/
> > /
> > /libfdt/
> > /lzma/
> > /lzo/
> >
> > /examples/
> > /api/
> > /standalone/
>
> Not directly answering your question, but rather a minor naming nit:
> strictly speaking the 'api' subdir contents are also standalone
> applications... so the above naming scheme is not clear cut, although
> I don't have much better suggestions :-) The 'standalone' above use
> the legacy jumptable calls method, so maybe 'jumptable' dirname would
> work? Other thoughts?

I see your point. <nitpick>Its a bit confusing as U-Boot documentation
seems to refer to "Standalone applications" alot, and in general that
documentation is specifically referring jumptable applications. eg
"doc/README.standalone" and "Standalone HOWTO" in README. If you dig
you can find the API applications mentioned in api/README - I don't see
it referenced much in either the standard location of /doc/* or /README.
I guess my only point is that it would be great if the application
documentation was consistent between the jumptable and API method, then
it would be a a no brainer as far as naming /examples directory layout.
As is, documentation implies "standalone application" means jumptable
application.</nitpick>

In any case, I'm OK with a different directory layout. /examples/[api|
jumptable] is fine, or we could even add an apps subdir,
eg: /examples/apps/[api|jumptable]. I'm also fine with leaving it the
way I had it initially as all documentation currently implies standalone
== jumptable, api = API method.

Let me know if you or others have arguments for 1 convention over
another.

Thanks,
Peter