[Buildroot] User-enabled host packages?

[Thomas De Schampheleire]

Hi Thomas,

On Fri, Sep 30, 2011 at 7:58 PM, Thomas Petazzoni
<thomas.petazzoni at free-electrons.com> wrote:
> Le Fri, 30 Sep 2011 18:46:17 +0200,
> Thomas De Schampheleire <patrickdepinguin+buildroot at 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