[Buildroot] [RFC 1/1] toolchain-external/Config.in: Allow to select custom external-toolchain package

Arnout Vandecappelle arnout at mind.be
Mon Apr 15 08:54:03 UTC 2019

On 15/04/2019 08:57, Thomas Petazzoni wrote:
> Hello,
> On Sun, 14 Apr 2019 23:39:38 +0200
> Arnout Vandecappelle <arnout at mind.be> wrote:
>>> +	bool "Other"
>>> +	help
>>> +	  Use this option to use a external toolchain from custom package
>>> +	  (e.g. in external project).  
>>  So, the idea is to extend the choice with toolchains that come from
>> BR2_EXTERNAL and that you can't select here, right? And you need something like
>> that because it's a choice, and there's no way to extend the choice in a
>> different Kconfig file.
>>  I think this is a worthwhile idea, so I'd like to work it out a little more...
>> Adding Yann in Cc since he like that kind of external craziness :-)
>>  If kept like this, then I think you should make it depend on a new (blind)
>> BR2_TOOLCHAIN_EXTERNAL_OTHER_AVAILABLE option, and that an external toolchain
>> package should select that option. This way, the option is only available if
>> your external tree actually makes one available.

 I forgot to mention how this option should be constructed... In the
toolchain-external's Config.in, you would have


 And in the br2-external Config.in:

	default y

(Kconfig language allows the same symbol to be declared in different places, as
long as the definitions are consistent.)

>>  Also, it should be documented in docs/manual/customize-outside-br.txt.
>>  However, it's still pretty inconvenient for the user. So perhaps we could
>> explicitly extend the external infra to generate a .br2-external.toolchain.in
>> that is included from here. This file would be populated based on the file
>> toolchain/Config.in in the external.
>>  Thomas, is that idea over-engineered?
> It is over-engineered, but there is not much choice if we want to allow
> implementing external toolchains in BR2_EXTERNAL, which would
> definitely be useful.
> The downside of Vadim's approach is that it limits the BR2_EXTERNAL to
> implementing only one external toolchain, since it's only adding one
> entry to the choice. Your approach would be more flexible.

 Well, you *can* still add a second choice in the br2-external. But then having
multiple options from multiple br2-externals becomes difficult...


More information about the buildroot mailing list