[Buildroot] [PATCH 5 of 7 v3] toolchain-external: change version from 'undefined' to 'virtual'

[Thomas De Schampheleire]

On Sun, Jun 8, 2014 at 6:10 PM, Thomas Petazzoni
<thomas.petazzoni at free-electrons.com> wrote:
> Dear Thomas De Schampheleire,
>
> On Sun, 8 Jun 2014 17:04:17 +0200, Thomas De Schampheleire wrote:
>
>> > I'm sorry, but I continue to disagree. toolchain-external is definitely
>> > *not* a virtual package. I've started using the
>> > TOOLCHAIN_EXTERNAL_VERSION field for musl external toolchains, and I
>> > will send a patch that use it for other toolchains as well.
>>
>> Ok, I understand your objections. Note that my main point is that it
>> shouldn't be 'undefined', not that it necessarily has to be 'virtual'.
>>
>> However, in your pending musl patch, you set
>> TOOLCHAIN_EXTERNAL_VERSION to 1.0.0 (for example), causing the 'build'
>> directory to be output/build/toolchain-external-1.0.0 and the messages
>> to be:
>> toolchain-external 1.0.0 Downloading
>>
>> The value 1.0.0 doesn't mean a lot here, you have no clue that this is
>> a musl, glibc, ... toolchain or which is the provider. Considering
>> only the messages for a moment, it would make more sense that they
>> would read:
>>
>> toolchain-external Sourcery ARM 2012.03 Downloading
>>
>> (for example), i.e. actually specify which is the external toolchain
>> we're using.
>>
>> This could be achieved in multiple ways:
>> - by setting the TOOLCHAIN_EXTERNAL_VERSION field to this value
>> (imposing the requirement of it not containing spaces as this value is
>> also used for the directory name).
>> - adding an extra field in the MESSAGE definition that can be set in
>> the toolchain-external package, with 'extra' info. The VERSION field
>> can then still be 1.0.0 or 2012.03, and the extra info would be
>> 'Sourcery ARM' for example.
>>
>> The second approach handles both my concern of not having 'undefined'
>> and is in line with your usage of 1.0.0 for VERSION.
>>
>> What do you think?
>
> While your second solution adds quite a bit of additional logic in
> MESSAGE just for the sake of toolchain-external, I don't really have a
> better suggestion right now. Or should we turn all these external
> toolchains into individual packages, which become providers for what
> would really become a virtual toolchain-external package? I'm not sure
> of the benefit, though.

I also think the second approach of creating individual external
toolchain packages is overkill.

I don't think that the MESSAGE solution adds a lot of complexity: the
current definition is:
MESSAGE     = echo "$(TERM_BOLD)>>> $($(PKG)_NAME) $($(PKG)_VERSION)
$(1)$(TERM_RESET)"
and this would become something like:
MESSAGE     = echo "$(TERM_BOLD)>>> $($(PKG)_NAME)
$($(PKG)_EXTRA_NAME) $($(PKG)_VERSION) $(1)$(TERM_RESET)"

where FOO_EXTRA_NAME is a new variabel (name to be discussed) that can
be set by any package (not only toolchain-external) if appropriate.
This variable is default empty.

This is not too complex, right?

In any case, I suggest we drop this patch from the series for now.

Best regards,
Thomas