[Buildroot] [PATCHv2 1/4] core: introduce the BR2_EXTERNAL variable

[Arnout Vandecappelle <arnout@mind.be>]

On 17/09/13 06:26, Thomas Petazzoni wrote:
> Dear Arnout Vandecappelle,
>
> On Mon, 16 Sep 2013 23:30:49 +0200, Arnout Vandecappelle wrote:
>> On 14/09/13 21:03, Thomas Petazzoni wrote:
>>> This commit introduces the BR2_EXTERNAL environment variable, which
>>> will allow to keep Buildroot customization (board-specific
>>> configuration files or root filesystem overlays, package Config.in
>>> and makefiles, as well as defconfigs) outside of the Buildroot tree.
>>>
>>> This commit only introduces the variable itself, and ensures that it
>>> is available within Config.in options, so that string options used
>>> to specify paths to directories or files can use $BR2_EXTERNAL as a
>>
>>    $(BR2_EXTERNAL). The $ is expanded by make. Same comment applies to
>> other places in the commit message as well. You did put it correctly
>> in the manual.
>
> Right, true.
>
>>>    * Ensures that the path given in BR2_EXTERNAL is an absolute
>>> path, or if not path is given, ensures that BR2_EXTERNAL points to
>>> a dummy implementation in $(TOPDIR)/support/dummy-external/. This
>>> last part is not directly useful in this commit, but is needed to
>>> properly support Config.in options declared in BR2_EXTERNAL (next
>>> commit).
>>
>>    It would make more sense to do it in that commit then, but that's
>> just nitpicking.
>
> Yeah, but since it was really part of the same chunk of code, it was
> annoying to split further. But I can certainly split that up further.
>
>>>    * Passes the BR2_EXTERNAL into the *config environment, so that
>>> its value is found when parsing/evaluating Config.in files
>>> and .config values.
>>
>>    That's pretty useless in this commit, since it anyway doesn't end
>> up in .config and isn't used in Config.in.
>
> Right, could be moved to the next commit then (but to me the separation
> of the commits is relatively artificial, since the patch set really
> only makes sense if everything is applied).

  Fair enough.


>>    If you agree to store the value in the .config file, it could look
>> something like this.
>>
>> -------
>>
>> config BR2_EXTERNAL_FROM_ENV
>>           string
>>           option env="BR2_EXTERNAL"
>>
>> # This condition forces the user to set BR2_EXTERNAL from the
>> # command line the first time.
>> if BR2_EXTERNAL_FROM_ENV != ""
>> config BR2_EXTERNAL
>>           string "External buildroot add-ons"
>>           default BR2_EXTERNAL_FROM_ENV
>>           help
>>             List of directories with buildroot add-ons. ...
>> endif
>>
>> if BR2_EXTERNAL != BR2_EXTERNAL_FROM_ENV
>> comment "You need to re-run the config to see the new packages"
>> endif
>>
>>
>> -------
>
> I don't know. Do we really want to do that? Isn't it simpler to always
> pass it as an environment variable?
>
> I mean, if an user changes the value of BR2_EXTERNAL in menuconfig, he
> has to exit / re-run menuconfig to anyway see the updated set of
> configuration options after the BR2_EXTERNAL value change. Does it
> really makes sense to set in menuconfig a configuration option that by
> itself changes the available configuration options, but which requires
> exiting/re-runnning menuconfig?

  The primary way of setting BR2_EXTERNAL would still be through the 
environment - in fact, the code above forces you to set it through the 
environment the first time, otherwise the option won't be visible.


>>    It doesn't really work, though, because currently the .config is
>> not read in when doing 'make menuconfig', so that
>> BR2_EXTERNAL_FROM_ENV will always be "". But I'm sure we'll be able
>> to find something that works with a little more effort.
>
> Hum, the .config is not read when doing 'make menuconfig'? Then how can
> 'make menuconfig' show the current state of enabled options?

  I mena that it isn't read by the Makefile.

  Regards,
  Arnout


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
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:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F