[Buildroot] [git commit master] buildroot; move defconfigs to configs/ and print in help

[Buildroot] [git commit master] buildroot; move defconfigs to configs/ and print in help

[Peter Korsgaard]

commit: http://git.buildroot.net/buildroot/commit/?id=58fd779a4355e5bfa2bc0b15ed9c4664f44c7a0f
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master

As discussed earlier on the mailing list. It simplifies code, gives more
sensible error message on typos and makes the defconfigs easier to find
for users.

Furthermore, update documentation to match.

Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>

Patch is too large, so refusing to show it

[Buildroot] [git commit master] buildroot; move defconfigs to configs/ and print in help

[Thomas Petazzoni]

Le Sun, 4 Oct 2009 22:20:28 +0200,
Peter Korsgaard <jacmet@sunsite.dk> a ?crit :

> As discussed earlier on the mailing list. It simplifies code, gives
> more sensible error message on typos and makes the defconfigs easier
> to find for users.

I have to say I'm not necessarly a big fan of this change. The
_defconfig files used to be stored together with the kernel
configuration, busybox configuration, uClibc configuration and target
skeleton specific to a target (in target/device/<vendor>/<board>).

Now, the _defconfig files are in a separate location, which makes it
slightly less logical/easy for people to add new targets.

Cheers!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com

[Buildroot] [git commit master] buildroot; move defconfigs to configs/ and print in help

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

Hi,

 >> As discussed earlier on the mailing list. It simplifies code, gives
 >> more sensible error message on typos and makes the defconfigs easier
 >> to find for users.

 Thomas> I have to say I'm not necessarly a big fan of this change. The
 Thomas> _defconfig files used to be stored together with the kernel
 Thomas> configuration, busybox configuration, uClibc configuration and target
 Thomas> skeleton specific to a target (in target/device/<vendor>/<board>).

 Thomas> Now, the _defconfig files are in a separate location, which makes it
 Thomas> slightly less logical/easy for people to add new targets.

True - This change makes it slightly harder for developers, but easier
for users to find (and for us to do a test build of all defconfigs prior
to release).

The stuff in target/device/ tends to get stale over time, so a bit more
visibility is imho good.

I obviously like it, and I never had any comments when I proposed it
back in September:

http://lists.busybox.net/pipermail/buildroot/2009-September/029269.html

-- 
Bye, Peter Korsgaard

[Buildroot] [git commit master] buildroot; move defconfigs to configs/ and print in help

[Thomas Petazzoni]

Hello,

Coming back on this old topic, because I really don't like the new way.

Le Mon, 05 Oct 2009 09:09:29 +0200,
Peter Korsgaard <jacmet@uclibc.org> a ?crit :

> True - This change makes it slightly harder for developers, but easier
> for users to find (and for us to do a test build of all defconfigs
> prior to release).

For developers, it's a mess. You have to explain to developers that
they have to put some stuff in this directory, some other stuff into
this directory. (BTW the documentation at
http://buildroot.org/buildroot.html#board_support hasn't been updated
accordingly).

Moreover, it breaks the idea of having out-of-tree board support.
Before this change, it was relatively easy since the stuff needed to
support one board was centralized in one directory (see my proposal at
http://git.buildroot.net/~tpetazzoni/git/buildroot/commit/?id=ed47f42a598c665bf42c4e797187f233b955e285).
Now, it's split between a directory in target/device and a file in
configs/.

To make them more visible to users, I suggest to reorganize target/. All
board-stuff should be moved to a top-level boards/ directory. This
directory would have roughly the same architecture as the current
target/device/ directory.

And then, to make the defconfig files visible to users, just show them
in "make help".

> The stuff in target/device/ tends to get stale over time, so a bit
> more visibility is imho good.

Let's move it to boards/ then.

> I obviously like it, and I never had any comments when I proposed it
> back in September:
> 
> http://lists.busybox.net/pipermail/buildroot/2009-September/029269.html

True, I forgot to send my comments at that time. Or maybe didn't
realized what the impact of the change would be.

Is it possible to re-discuss this topic before the 2008.11 release ?

Sincerly,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com

[Buildroot] [git commit master] buildroot; move defconfigs to configs/ and print in help

[Thiago A. Corrêa]

Hi,

On Wed, Nov 11, 2009 at 12:03 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
>
> Moreover, it breaks the idea of having out-of-tree board support.
> Before this change, it was relatively easy since the stuff needed to
> support one board was centralized in one directory (see my proposal at
> http://git.buildroot.net/~tpetazzoni/git/buildroot/commit/?id=ed47f42a598c665bf42c4e797187f233b955e285).
> Now, it's split between a directory in target/device and a file in
> configs/.

Well, I haven't checked the new implementation, but I guess it's in
the line of changing find with ls. If a fallback to the out-of-tree
board support can't be implemented, then I think what we are losing
greatly outweights what we are gaining here.
Currently I have to implement my own board support in a very crude
way, as I'm sticking with the tagged versions to update my SVN
repository. In my crude implementation, I just extended the find to
also look up in my board folder. Having out-of-tree board support
would allow me to get much closer to vanilla buildroot.

Just my 2cts.

Kind Regards,
    Thiago A. Correa

[Buildroot] [git commit master] buildroot; move defconfigs to configs/ and print in help

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 Thomas> Hello,

 Thomas> Coming back on this old topic, because I really don't like the
 Thomas> new way.

I'm sorry to hear. I do kind of like it ;)

 >> True - This change makes it slightly harder for developers, but easier
 >> for users to find (and for us to do a test build of all defconfigs
 >> prior to release).

 Thomas> For developers, it's a mess. You have to explain to developers that
 Thomas> they have to put some stuff in this directory, some other stuff into
 Thomas> this directory. (BTW the documentation at
 Thomas> http://buildroot.org/buildroot.html#board_support hasn't been updated
 Thomas> accordingly).

It hasn't? I did update it, and it imho is pretty clear:

You can furthermore create one or more preconfigured configuration
files, referencing those files. These config files are named
something_defconfig and are stored in the toplevel configs/
directory. Your users will then be able to run make something_defconfig
and get the right configuration for your project

Do you have a suggestion for a clearer wording?

I don't see the different directory as a big problem (E.G. it doesn't
seem to be an issue for other projects doing the same, like the Linux
kernel or U-Boot). If people add packages and/or patches for their
custom stuff (I know people at the company I work for do this) they'll
need to look outside their target/device/company/board dir anyway.

Similary, I don't believe name clashes in configs/ are a big problem
(like in Linux/U-Boot).

 Thomas> Moreover, it breaks the idea of having out-of-tree board support.
 Thomas> Before this change, it was relatively easy since the stuff needed to
 Thomas> support one board was centralized in one directory (see my proposal at
 Thomas> http://git.buildroot.net/~tpetazzoni/git/buildroot/commit/?id=ed47f42a598c665bf42c4e797187f233b955e285).

Did you rebase? The link doesn't seem to work any more :/

 Thomas> To make them more visible to users, I suggest to reorganize
 Thomas> target/. All board-stuff should be moved to a top-level boards/
 Thomas> directory. This directory would have roughly the same
 Thomas> architecture as the current target/device/ directory.

I agree, but that's imho not directly related to where to put
_defconfigs.

 Thomas> And then, to make the defconfig files visible to users, just show them
 Thomas> in "make help".

With a find-all-files-ending-in-_defconfig-under-here thing? Could be
done, but is kind of ugly - Same for make <foo>_defconfig.

 >> The stuff in target/device/ tends to get stale over time, so a bit
 >> more visibility is imho good.

 Thomas> Let's move it to boards/ then.

Optimist! ;) I don't think that will significantly change the staleness
of it though.

 Thomas> True, I forgot to send my comments at that time. Or maybe didn't
 Thomas> realized what the impact of the change would be.

 Thomas> Is it possible to re-discuss this topic before the 2008.11 release ?

Yes, but I'm about to put out -rc1, so we have limited time.

-- 
Bye, Peter Korsgaard

[Buildroot] [git commit master] buildroot; move defconfigs to configs/ and print in help

[Thomas Petazzoni]

Hello,

Le Sun, 22 Nov 2009 22:05:09 +0100,
Peter Korsgaard <jacmet@uclibc.org> a ?crit :

>  Thomas> Coming back on this old topic, because I really don't like
>  Thomas> the new way.
> 
> I'm sorry to hear. I do kind of like it ;)

Argh, I still don't like it ;)

> It hasn't? I did update it, and it imho is pretty clear:

Sorry for the mistake, it has been updated. I apologize.

> I don't see the different directory as a big problem (E.G. it doesn't
> seem to be an issue for other projects doing the same, like the Linux
> kernel or U-Boot). If people add packages and/or patches for their
> custom stuff (I know people at the company I work for do this) they'll
> need to look outside their target/device/company/board dir anyway.

Sure, but the things in packages and/or patches are not board-specific.
While the Buildroot configuration files and the associated kernel/u-boot
configuration are board/project specific. Therefore, they should be in
the same location.

> Similary, I don't believe name clashes in configs/ are a big problem
> (like in Linux/U-Boot).

I don't think I raised name clashes as an issue, since I don't think
it's one (even in my solution, the names of the _defconfig files should
be unique).

>  Thomas> Moreover, it breaks the idea of having out-of-tree board
>  Thomas> support. Before this change, it was relatively easy since
>  Thomas> the stuff needed to support one board was centralized in one
>  Thomas> directory (see my proposal at
>  Thomas> http://git.buildroot.net/~tpetazzoni/git/buildroot/commit/?id=ed47f42a598c665bf42c4e797187f233b955e285).
> 
> Did you rebase? The link doesn't seem to work any more :/

Strange, because it works here. Just in case, I've pasted the patch at
http://free-electrons.com/~thomas/external-boards-proposal.patch.

The patch is *very* simple because all board-specific things are
concentrated into one directory. With your new solution, I have no idea
how I could implement out-of-tree board support, which is something our
users have been asking for.

>  Thomas> To make them more visible to users, I suggest to reorganize
>  Thomas> target/. All board-stuff should be moved to a top-level
>  Thomas> boards/ directory. This directory would have roughly the same
>  Thomas> architecture as the current target/device/ directory.
> 
> I agree, but that's imho not directly related to where to put
> _defconfigs.

It is not directly. But it would really, really look odd to have :

 boards
  - atmel
    - at91sam9263ek with kernel/uClibc/Busybox config files
    - at91sam9260ek with kernel/uClibc/Busybox config files
  - armadeus
    - apf27 with kernel/uClibc/Busybox config files
  - calao
    - usb-a9263 with kernel/uClibc/Busybox config files
 configs
   at91sam9263ek_defconfig
   at91sam9260ek_defconfig
   armadeus_apf27_defconfig
   calao_usb-a9263_defconfig

The _defconfig files really belong to the boards directory. IMO, having
the _defconfig files in a separate directory makes them disconnected
from their corresponding kernel/uClibc/Busybox configuration files.

>  Thomas> And then, to make the defconfig files visible to users, just
>  Thomas> show them in "make help".
> 
> With a find-all-files-ending-in-_defconfig-under-here thing? Could be
> done, but is kind of ugly - Same for make <foo>_defconfig.

Come on, kind of ugly ? It's a one liner for <foo>_defconfig (something
we already had) :

%_defconfig: $(CONFIG)/conf
	cp $(shell find ./target/ -name $@) .config

The "make help" thing is probably of the same one-liner style.

>  >> The stuff in target/device/ tends to get stale over time, so a bit
>  >> more visibility is imho good.
> 
>  Thomas> Let's move it to boards/ then.
> 
> Optimist! ;) I don't think that will significantly change the
> staleness of it though.

For sure moving things around will not prevent staleness. But:

 * That will make board support more visible, and easier to use for
   board vendors ;

 * We could have a maintainer for each board. At -rc1, all board
   maintainers are asked to check their board support. If they don't
   answer before the final release, the board is marked as broken. And
   removed in the next release if no news.

> Yes, but I'm about to put out -rc1, so we have limited time.

-rc1 is out. But I still don't like this change. I usually don't have a
strong opinion on most changes, but I really don't understand this one.

Sincerely,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com

[Buildroot] [git commit master] buildroot; move defconfigs to configs/ and print in help

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

Hi,

 >> I'm sorry to hear. I do kind of like it ;)

 Thomas> Argh, I still don't like it ;)

:/

I'll get back to you on this in more detail tomorrow, but just wanted to
reply to one thing now:

 >> With a find-all-files-ending-in-_defconfig-under-here thing? Could be
 >> done, but is kind of ugly - Same for make <foo>_defconfig.

 Thomas> Come on, kind of ugly ? It's a one liner for <foo>_defconfig (something
 Thomas> we already had) :

 Thomas> %_defconfig: $(CONFIG)/conf
 Thomas> 	cp $(shell find ./target/ -name $@) .config

But that's without error handling! If the user mistypes the defconfig
name he gets a very odd error:

make blah_defconfig
cp .config
cp: missing destination file operand after `.config'
Try `cp --help' for more information.

Whereas with a real dest: target rule like what we have now you get a
sensible error message:

make blah_defconfig
make: *** No rule to make target `blah_defconfig'.  Stop.

That's what I mean about ugly.

-- 
Bye, Peter Korsgaard