[Buildroot] User-enabled host packages?

[Buildroot] User-enabled host packages?

[Luca Ceresoli]

Hi buildroot developers,

the current policy for host packages is that they do not appear in
menuconfig: they are automatically activated based on the dependencies
whenever thay are needed for building an image.

However, in a recent discussion between me and Thomas Petazzoni
(http://lists.busybox.net/pipermail/buildroot/2011-September/045821.html)
we noticed that some host packages might be worth being available as
user options, even though they are not used to produce any imge.

In the cited thread the following examples emerged:

Luca Ceresoli wrote about omap-u-boot-utils:
 >
 > OTOH, ucmd "sends a command and expects a provided matching response
 > from target", and is aimed at creating automated scripts to interact
 > with a commandline program over a serial line. This can be used in any
 > architecture. I have board-specific scripts that use it to write
 > bootloader + kernel + rootfs onto a new (or bricked) board from files in
 > output/images.
(http://lists.busybox.net/pipermail/buildroot/2011-September/045638.html)

Thomas Petazzoni wrote:
 > I must admit there are other cases for which being able to show host
 > packages to users would be useful. For example, on AT91 platforms,
 > there is an host utility called SAM-BA which allows to reflash an AT91
 > device through the USB device port. This host utility could be
 > conveniently downloaded, extracted and installed into $(HOST_DIR) by
 > Buildroot, but we have currently no way of doing this.
 >
 > Some thing for OpenOCD. Jean-Christophe has recently added support for
 > it for the target, but being able to build OpenOCD on the host and
 > install it in $(HOST_DIR) would also be useful for those of us who want
 > to build ready-to-use development environments with Buildroot.
(http://lists.busybox.net/pipermail/buildroot/2011-September/045821.html)

All of these examples are about tools that could generally be
downloaded, built and installed by each developer on their own machine.
Nevertheless any developer may benefit from having them built inside
buildroot: it would be more handy and quick to build them, and also
guarantee that the version used in buildroot is somehow tested by other
buildroot users.

Moreover, some packages (such as omap-u-boot-utils for which I posted a
patch) have their own right of being inside buildroot because they also
contribute to building the BR images. Having a user option to build
them, even if they are not required for image generation, would require
little effort.

So the big question is: do we want some host packages to be enabled
vie a user option?

Where do we want these user options?
How about a newly created "Host tools" menu at top level?

Does anybody have additional examples in favor or against?

Thanks,
Luca

[Buildroot] User-enabled host packages?

[Thomas Petazzoni]

Le Wed, 21 Sep 2011 15:00:49 +0200,
Luca Ceresoli <luca@lucaceresoli.net> a ?crit :

> All of these examples are about tools that could generally be
> downloaded, built and installed by each developer on their own
> machine. Nevertheless any developer may benefit from having them
> built inside buildroot: it would be more handy and quick to build
> them, and also guarantee that the version used in buildroot is
> somehow tested by other buildroot users.
> 
> Moreover, some packages (such as omap-u-boot-utils for which I posted
> a patch) have their own right of being inside buildroot because they
> also contribute to building the BR images. Having a user option to
> build them, even if they are not required for image generation, would
> require little effort.
> 
> So the big question is: do we want some host packages to be enabled
> vie a user option?
> 
> Where do we want these user options?
> How about a newly created "Host tools" menu at top level?
> 
> Does anybody have additional examples in favor or against?

And also:

If we decide to show /some/ host tools (but not all) in menuconfig, what
is the boundary between host tools visible in menuconfig and those not
visible in menuconfig ?

Regards,

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

[Buildroot] User-enabled host packages?

[Luca Ceresoli]

Thomas Petazzoni wrote:
> Le Wed, 21 Sep 2011 15:00:49 +0200,
> Luca Ceresoli<luca@lucaceresoli.net>  a ?crit :
>
>> All of these examples are about tools that could generally be
>> downloaded, built and installed by each developer on their own
>> machine. Nevertheless any developer may benefit from having them
>> built inside buildroot: it would be more handy and quick to build
>> them, and also guarantee that the version used in buildroot is
>> somehow tested by other buildroot users.
>>
>> Moreover, some packages (such as omap-u-boot-utils for which I posted
>> a patch) have their own right of being inside buildroot because they
>> also contribute to building the BR images. Having a user option to
>> build them, even if they are not required for image generation, would
>> require little effort.
>>
>> So the big question is: do we want some host packages to be enabled
>> vie a user option?
>>
>> Where do we want these user options?
>> How about a newly created "Host tools" menu at top level?
>>
>> Does anybody have additional examples in favor or against?
>
> And also:
>
> If we decide to show /some/ host tools (but not all) in menuconfig, what
> is the boundary between host tools visible in menuconfig and those not
> visible in menuconfig ?

My opinion is that this would be based on user needs.

Whenever a BR user feels the need of adding a host tool here, he would
propose a patch to do so. If nobody will feel the need for host-foo,
then nobody will write a patch to add it.

That's what happens with regular packages, ain't that true?

Luca

[Buildroot] User-enabled host packages?

[Arnout Vandecappelle]

On Wednesday 21 September 2011 15:31:33, Thomas Petazzoni wrote:
> > So the big question is: do we want some host packages to be enabled
> > vie a user option?

 We already have one: BR2_PACKAGE_GDB_HOST.

 Other possible candidates are the installers for boot loaders (grub, 
syslinux), target image manipulation programs (parted, fdisk, e2fsprogs, 
uboot-tools), tools to communicate with the target (openocd, tftpd), and maybe 
even scripting languages for running test suites (expect, python).

 However, I'm not sure of the value of having these in the .config.  If I need 
them, it's anyway for use in build scripts that run on top of buildroot, and 
then I can just run a "make world host-e2fsprogs".  The paths to the host 
tools are anyway so long that even when you need them in your shell, typing an 
additional make host-xxx first is really no effort.


> > Where do we want these user options?
> > How about a newly created "Host tools" menu at top level?

 That would mean they don't sit in their package's Config.in.  Still, it would 
be the most logical place.  Anyway there normally is no impact on the 
package's makefile since the config option is taken care of by GENTARGETS.


> > Does anybody have additional examples in favor or against?

 I don't have anything against it.  But no real driving reason for it either.


> And also:
> 
> If we decide to show some host tools (but not all) in menuconfig, what
> is the boundary between host tools visible in menuconfig and those not
> visible in menuconfig ?

 Similar as for the boundary between when to have a configuration option for 
different versions of a package.  Depends on what users need.


 Can someone summarize the arguments that were used when this discussion took 
place a few years ago?


 Regards,
 Arnout
-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  31BB CF53 8660 6F88 345D  54CC A836 5879 20D7 CF43

[Buildroot] User-enabled host packages?

[Thomas Petazzoni]

Hello,

Le Thu, 22 Sep 2011 22:53:42 +0200,
Arnout Vandecappelle <arnout@mind.be> a ?crit :

> On Wednesday 21 September 2011 15:31:33, Thomas Petazzoni wrote:
> > > So the big question is: do we want some host packages to be enabled
> > > vie a user option?
> 
>  We already have one: BR2_PACKAGE_GDB_HOST.

Right. And also binutils uses the package infrastructure, and its host
variant is visible in menuconfig. But we can argue that binutils/gdb
being part of the toolchain, those are "special".

>  Other possible candidates are the installers for boot loaders (grub, 
> syslinux), target image manipulation programs (parted, fdisk, e2fsprogs, 
> uboot-tools), tools to communicate with the target (openocd, tftpd), and maybe 
> even scripting languages for running test suites (expect, python).

Right.

>  However, I'm not sure of the value of having these in the .config.  If I need 
> them, it's anyway for use in build scripts that run on top of buildroot, and 
> then I can just run a "make world host-e2fsprogs".  The paths to the host 
> tools are anyway so long that even when you need them in your shell, typing an 
> additional make host-xxx first is really no effort.

Well, I guess it's slightly more convenient. I regularly ship
customized Buildroot configurations as development environment for
embedded projects, and it would definitely be nice to be able to keep
the simple :

	make blabla_defconfig
	make

documentation, and allow the user to have all needed host tools in
$(HOST_DIR), including tools to reflash the firmware on the device, or
other utilities as you mentioned. Of course, I can document to run
"make world host-foobar", but that sounds less integrated. But I have
no strong opinion here.

>  That would mean they don't sit in their package's Config.in.  Still, it would 
> be the most logical place.  Anyway there normally is no impact on the 
> package's makefile since the config option is taken care of by GENTARGETS.

For those packages, we could have a separate Config.in.host in the
package directory, which would be included by the top-level
package/Config.in to make the host package appear in this new "Host
tools" menu.

> > And also:
> > 
> > If we decide to show some host tools (but not all) in menuconfig, what
> > is the boundary between host tools visible in menuconfig and those not
> > visible in menuconfig ?
> 
>  Similar as for the boundary between when to have a configuration option for 
> different versions of a package.  Depends on what users need.

Ok, but I'd for example like to avoid having the myriad of X11
libraries that we need to build for the host visible in the menuconfig.

>  Can someone summarize the arguments that were used when this discussion took 
> place a few years ago?

As far as I remember, host utilities have almost never been visible
into menuconfig, besides a few exceptions (fakeroot comes to mind). At
the time, there was only the AUTOTARGETS infrastructure (non-autotools
packages were handled by hand-written makefiles) and the AUTOTARGETS
infrastructure did support only target packages (host autotools
packages were handled by hand-written makefiles). When we started
to support host packages into the package infrastructure, we clearly
stated that those would not be visible, as they were only necessary as
mere dependencies for the rest of the build process, and that for this
reason, the user had no need to see them, because he wouldn't
use/interact with them directly.

Regards,

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

[Buildroot] User-enabled host packages?

[Thomas De Schampheleire]

Hi,

On Fri, Sep 23, 2011 at 9:46 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> Le Thu, 22 Sep 2011 22:53:42 +0200,
> Arnout Vandecappelle <arnout@mind.be> a ?crit :
>
>> On Wednesday 21 September 2011 15:31:33, Thomas Petazzoni wrote:
>> > > So the big question is: do we want some host packages to be enabled
>> > > vie a user option?
>>
>> ?We already have one: BR2_PACKAGE_GDB_HOST.
>
> Right. And also binutils uses the package infrastructure, and its host
> variant is visible in menuconfig. But we can argue that binutils/gdb
> being part of the toolchain, those are "special".
>
>> ?Other possible candidates are the installers for boot loaders (grub,
>> syslinux), target image manipulation programs (parted, fdisk, e2fsprogs,
>> uboot-tools), tools to communicate with the target (openocd, tftpd), and maybe
>> even scripting languages for running test suites (expect, python).
>
> Right.
>
>> ?However, I'm not sure of the value of having these in the .config. ?If I need
>> them, it's anyway for use in build scripts that run on top of buildroot, and
>> then I can just run a "make world host-e2fsprogs". ?The paths to the host
>> tools are anyway so long that even when you need them in your shell, typing an
>> additional make host-xxx first is really no effort.
>
> Well, I guess it's slightly more convenient. I regularly ship
> customized Buildroot configurations as development environment for
> embedded projects, and it would definitely be nice to be able to keep
> the simple :
>
> ? ? ? ?make blabla_defconfig
> ? ? ? ?make
>
> documentation, and allow the user to have all needed host tools in
> $(HOST_DIR), including tools to reflash the firmware on the device, or
> other utilities as you mentioned. Of course, I can document to run
> "make world host-foobar", but that sounds less integrated. But I have
> no strong opinion here.

I also prefer this simple approach. If for a certain project, host
tool X is needed, putting that dependency in the defconfig file:
* makes the build steps easy and short
* avoids putting too much knowledge in the build scripts that sit on
top of buildroot

>
>> ?That would mean they don't sit in their package's Config.in. ?Still, it would
>> be the most logical place. ?Anyway there normally is no impact on the
>> package's makefile since the config option is taken care of by GENTARGETS.
>
> For those packages, we could have a separate Config.in.host in the
> package directory, which would be included by the top-level
> package/Config.in to make the host package appear in this new "Host
> tools" menu.

I'm currently in need of the dtc compiler, which is only really
relevant to the host. I followed the approach suggested above of a
Config.in.host file that includes the appropriate dtc/dtc.mk file.
Config.in.host is then included from the top-level Config.in.
I can submit a patch with this if you like.

>
>> > And also:
>> >
>> > If we decide to show some host tools (but not all) in menuconfig, what
>> > is the boundary between host tools visible in menuconfig and those not
>> > visible in menuconfig ?
>>
>> ?Similar as for the boundary between when to have a configuration option for
>> different versions of a package. ?Depends on what users need.
>
> Ok, but I'd for example like to avoid having the myriad of X11
> libraries that we need to build for the host visible in the menuconfig.
>
>> ?Can someone summarize the arguments that were used when this discussion took
>> place a few years ago?
>
> As far as I remember, host utilities have almost never been visible
> into menuconfig, besides a few exceptions (fakeroot comes to mind). At
> the time, there was only the AUTOTARGETS infrastructure (non-autotools
> packages were handled by hand-written makefiles) and the AUTOTARGETS
> infrastructure did support only target packages (host autotools
> packages were handled by hand-written makefiles). When we started
> to support host packages into the package infrastructure, we clearly
> stated that those would not be visible, as they were only necessary as
> mere dependencies for the rest of the build process, and that for this
> reason, the user had no need to see them, because he wouldn't
> use/interact with them directly.

Best regards,
Thomas

[Buildroot] User-enabled host packages?

[Arnout Vandecappelle]

On Friday 30 September 2011 14:50:03, Thomas De Schampheleire wrote:
> I'm currently in need of the dtc compiler, which is only really
> relevant to the host. I followed the approach suggested above of a
> Config.in.host file that includes the appropriate dtc/dtc.mk file.
> Config.in.host is then included from the top-level Config.in.
> I can submit a patch with this if you like.

 I like!

 Regards,
 Arnout

-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  31BB CF53 8660 6F88 345D  54CC A836 5879 20D7 CF43
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20110930/71b6c749/attachment.html>

[Buildroot] User-enabled host packages?

[Thomas Petazzoni]

Hello,

In this e-mail, I'll try to summarize what I understand to be the
consensus on this issue and also what I, as a Buildroot contributor,
consider acceptable for integration :

 * It is desirable to have *some* host packages visible in the
   menuconfig interface, but *most* host packages should remain
   invisible as they are today, when those are solely used as build
   dependencies.

   The criteria on deciding whether an host package should be made
   visible or not depends on whether this host package contains
   utilities that are directly useful for development. Things like
   image generators, debugging or flashing utilities that run on the
   host but interact with a target, etc. are the typical types of
   host packages that are expected to be visible.

 * From a .mk file perspective, exposing some host packages requires no
   change to the existing infrastructure. All host packages must be
   stored in the package/ subdirectory, just like any other package. So
   even the omap-u-boot-utils proposed by Luca should be in
   package/omap-u-boot-utils, just like package/uboot-tools.

 * From a Config.in perspective, the host packages that need to be
   visible should implement a package/<foo>/Config.in.host file
   describing the configuration options. Those configuration options
   should have the BR2_HOST_PACKAGE_* prefix. All these Config.in.host
   files are included in a single "Packages -> Host utitities" submenu,
   from package/Config.in. There is no need to create subsections in
   this menu at the moment, since the number of utilities shown here is
   suspected to remain limited.

 * The package infrastructure is modified so that when a
   BR2_HOST_PACKAGE_<foo> option is enabled, then host-foo is added to
   the global TARGETS variable.

What do others think of this proposal? Peter, what is your feeling
about the general idea and this proposal? Can we go ahead and implement
something like proposed in this e-mail?

Regards,

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

[Buildroot] User-enabled host packages?

[Thomas De Schampheleire]

On Fri, Sep 30, 2011 at 4:04 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> In this e-mail, I'll try to summarize what I understand to be the
> consensus on this issue and also what I, as a Buildroot contributor,
> consider acceptable for integration :
>
> ?* It is desirable to have *some* host packages visible in the
> ? menuconfig interface, but *most* host packages should remain
> ? invisible as they are today, when those are solely used as build
> ? dependencies.

Agreed.

>
> ? The criteria on deciding whether an host package should be made
> ? visible or not depends on whether this host package contains
> ? utilities that are directly useful for development. Things like
> ? image generators, debugging or flashing utilities that run on the
> ? host but interact with a target, etc. are the typical types of
> ? host packages that are expected to be visible.

Agreed.

>
> ?* From a .mk file perspective, exposing some host packages requires no
> ? change to the existing infrastructure. All host packages must be
> ? stored in the package/ subdirectory, just like any other package. So
> ? even the omap-u-boot-utils proposed by Luca should be in
> ? package/omap-u-boot-utils, just like package/uboot-tools.

Agreed.

>
> ?* From a Config.in perspective, the host packages that need to be
> ? visible should implement a package/<foo>/Config.in.host file
> ? describing the configuration options. Those configuration options
> ? should have the BR2_HOST_PACKAGE_* prefix.

Is this really needed?
If you use BR2_PACKAGE_HOST_FOO, then the existing infrastructure will
add host-foo to the targets.
Of course, explicit host packages will be treated the same way as
dependency-host-packages on Config.in level, but I don't think this is
a problem.

> All these Config.in.host
> ? files are included in a single "Packages -> Host utitities" submenu,
> ? from package/Config.in. There is no need to create subsections in
> ? this menu at the moment, since the number of utilities shown here is
> ? suspected to remain limited.

If you want to add the new menu under Packages, then the description
of that menu should change. Currently it is:
"Package Selection for the target"
A proposal is simply:
"Package selection"

The alternative is as proposed earlier: to put the menu at top-level.

>
> ?* The package infrastructure is modified so that when a
> ? BR2_HOST_PACKAGE_<foo> option is enabled, then host-foo is added to
> ? the global TARGETS variable.

Unless I'm misunderstanding the infrastructure, this would not be
needed if the option name is different, as I wrote above.

>
> What do others think of this proposal? Peter, what is your feeling
> about the general idea and this proposal? Can we go ahead and implement
> something like proposed in this e-mail?

Best regards,
Thomas

[Buildroot] User-enabled host packages?

[Thomas Petazzoni]

Le Fri, 30 Sep 2011 18:46:17 +0200,
Thomas De Schampheleire <patrickdepinguin+buildroot@gmail.com> a ?crit :

> > ?* From a Config.in perspective, the host packages that need to be
> > ? visible should implement a package/<foo>/Config.in.host file
> > ? describing the configuration options. Those configuration options
> > ? should have the BR2_HOST_PACKAGE_* prefix.
> 
> Is this really needed?
> If you use BR2_PACKAGE_HOST_FOO, then the existing infrastructure will
> add host-foo to the targets.

Ah, ah, you're right! This works well unless there are packages whose
names starts with host-, but this would be strange and we can just
state that it is not supported.

> Of course, explicit host packages will be treated the same way as
> dependency-host-packages on Config.in level, but I don't think this is
> a problem.

Not sure what you mean here, but that raises the question of
dependencies between host packages.

I would say that there shouldn't be dependencies of non-visible host
packages on visible host packages (what I call 'visible' are host
packages that we list in menuconfig).

When there is a dependency of a visible host package on another visible
host package, then the dependency must be expressed in both the
Config.in.host *and* the .mk file, as we do for target packages.

When there is a dependency of a visible host package on another
invisible host package, then the dependency is only expressed in
the .mk file, as we do for the dependency of current host packages.

When there is a dependency of an invisible host package on another
invisible host package, then the dependency is also only expressed in
the .mk file, as we do for the dependency of current host packages.

Does that sounds correct?

> > All these Config.in.host
> > ? files are included in a single "Packages -> Host utitities"
> > submenu, from package/Config.in. There is no need to create
> > subsections in this menu at the moment, since the number of
> > utilities shown here is suspected to remain limited.
> 
> If you want to add the new menu under Packages, then the description
> of that menu should change. Currently it is:
> "Package Selection for the target"
> A proposal is simply:
> "Package selection"
> 
> The alternative is as proposed earlier: to put the menu at top-level.

No strong opinion here. Perhaps a new top-level menu is better, I don't
know.

> > ?* The package infrastructure is modified so that when a
> > ? BR2_HOST_PACKAGE_<foo> option is enabled, then host-foo is added
> > to the global TARGETS variable.
> 
> Unless I'm misunderstanding the infrastructure, this would not be
> needed if the option name is different, as I wrote above.

Yes, sure.

Thanks for your feedback!

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

[Buildroot] User-enabled host packages?

[Thomas De Schampheleire]

Hi Thomas,

On Fri, Sep 30, 2011 at 7:58 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Le Fri, 30 Sep 2011 18:46:17 +0200,
> Thomas De Schampheleire <patrickdepinguin+buildroot@gmail.com> a ?crit :
>
>> > ?* From a Config.in perspective, the host packages that need to be
>> > ? visible should implement a package/<foo>/Config.in.host file
>> > ? describing the configuration options. Those configuration options
>> > ? should have the BR2_HOST_PACKAGE_* prefix.
>>
>> Is this really needed?
>> If you use BR2_PACKAGE_HOST_FOO, then the existing infrastructure will
>> add host-foo to the targets.
>
> Ah, ah, you're right! This works well unless there are packages whose
> names starts with host-, but this would be strange and we can just
> state that it is not supported.

I agree.

>
>> Of course, explicit host packages will be treated the same way as
>> dependency-host-packages on Config.in level, but I don't think this is
>> a problem.
>
> Not sure what you mean here, but that raises the question of
> dependencies between host packages.
>
> I would say that there shouldn't be dependencies of non-visible host
> packages on visible host packages (what I call 'visible' are host
> packages that we list in menuconfig).

That sounds reasonable, given the intention of using visible host
packages only for utility-like tools.

>
> When there is a dependency of a visible host package on another visible
> host package, then the dependency must be expressed in both the
> Config.in.host *and* the .mk file, as we do for target packages.
>
> When there is a dependency of a visible host package on another
> invisible host package, then the dependency is only expressed in
> the .mk file, as we do for the dependency of current host packages.
>
> When there is a dependency of an invisible host package on another
> invisible host package, then the dependency is also only expressed in
> the .mk file, as we do for the dependency of current host packages.
>
> Does that sounds correct?

All of the above sounds correct to me.

>
>> > All these Config.in.host
>> > ? files are included in a single "Packages -> Host utitities"
>> > submenu, from package/Config.in. There is no need to create
>> > subsections in this menu at the moment, since the number of
>> > utilities shown here is suspected to remain limited.
>>
>> If you want to add the new menu under Packages, then the description
>> of that menu should change. Currently it is:
>> "Package Selection for the target"
>> A proposal is simply:
>> "Package selection"
>>
>> The alternative is as proposed earlier: to put the menu at top-level.
>
> No strong opinion here. Perhaps a new top-level menu is better, I don't
> know.

What do others think?

>
>> > ?* The package infrastructure is modified so that when a
>> > ? BR2_HOST_PACKAGE_<foo> option is enabled, then host-foo is added
>> > to the global TARGETS variable.
>>
>> Unless I'm misunderstanding the infrastructure, this would not be
>> needed if the option name is different, as I wrote above.
>
> Yes, sure.
>
> Thanks for your feedback!
>

You're very welcome,

~Thomas

[Buildroot] User-enabled host packages?

[Luca Ceresoli]

Hi Thomas,

Thomas Petazzoni wrote:

>
>> Of course, explicit host packages will be treated the same way as
>> dependency-host-packages on Config.in level, but I don't think this is
>> a problem.
> Not sure what you mean here, but that raises the question of
> dependencies between host packages.
I'm also unsure about what Thomas (De Schampheleire) means here, but this
could be read as a feature as well.
A package such as omap-u-boot-utils can be required to build an OMAP-signed
image, thus being a dependency-host-package, or standalone to interact with
the target, thus being an explicit host package.
"Being treated in the same way" means it would work in both cases without
additional effort...


>>> All these Config.in.host
>>>    files are included in a single "Packages ->  Host utitities"
>>> submenu, from package/Config.in. There is no need to create
>>> subsections in this menu at the moment, since the number of
>>> utilities shown here is suspected to remain limited.
>> If you want to add the new menu under Packages, then the description
>> of that menu should change. Currently it is:
>> "Package Selection for the target"
>> A proposal is simply:
>> "Package selection"
>>
>> The alternative is as proposed earlier: to put the menu at top-level.
> No strong opinion here. Perhaps a new top-level menu is better, I don't
> know.

I personally feel a top-level menu would be better, leaving the "packages"
menu to list what has to be on the target.

Luca

[Buildroot] User-enabled host packages?

[Arnout Vandecappelle]

On Friday 30 September 2011 19:58:05, Thomas Petazzoni wrote:
> > > All these Config.in.host
> > >   files are included in a single "Packages -> Host utitities"
> > > submenu, from package/Config.in. There is no need to create
> > > subsections in this menu at the moment, since the number of
> > > utilities shown here is suspected to remain limited.
> >
> > 
> >
> > If you want to add the new menu under Packages, then the description
> > of that menu should change. Currently it is:
> > "Package Selection for the target"
> > A proposal is simply:
> > "Package selection"
> >
> > 
> >
> > The alternative is as proposed earlier: to put the menu at top-level.
> 
> No strong opinion here. Perhaps a new top-level menu is better, I don't
> know.

 I also prefer a new top-level menu.

 However, what do we do with the bootloader installers (i.e. host-grub and 
friends)?  It would feel a little strange to move them out of the bootloader 
menu...


 Regards,
 Arnout

-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  31BB CF53 8660 6F88 345D  54CC A836 5879 20D7 CF43
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20111001/77812ddc/attachment.html>