[Buildroot] [RFC 0/3] Adding software stacks

Angelo Compagnucci angelo.compagnucci at gmail.com
Fri Oct 13 08:34:03 UTC 2017


Dear Arnout Vandecappelle,

2017-10-13 8:31 GMT+02:00 Arnout Vandecappelle <arnout at mind.be>:
>
>
> On 12-10-17 08:13, Angelo Compagnucci wrote:
>> Dear Arnout Vandecappelle
>>
>> 2017-10-11 23:38 GMT+02:00 Arnout Vandecappelle <arnout at mind.be>:
>>>  Hi Angelo,
>>>
>>> On 10-10-17 22:43, Angelo Compagnucci wrote:
>>>> Software stacks are a way to define a group of options that should be used together and they are orthogonal to configs: a software stack can indeed be shared among several configs.
>>>
>>>  Wow, you always come with the innovative ideas, don't you?
>>
>> Could you point me where I said it's innovative?
>
>  You didn't say it, but I thought it was innovative. Sorry, I probably didn't
> express myself clearly. When I saw your patch series the first time, I
> immediately thought "hey, this is nice" and started composing this answer (but
> only this sentence). But then I realized we had discussed something like this
> before both on the list and in face-to-face meetings, so I left it to have a
> sleep on it before continuing. I realize now that the rest of my mail can come
> over pretty critical. With my

Sorry Arnout for having intended your sentence in a critical way, I
know my patch series could be controversial at first and I was
expecting negative reactions.
So thank you for your appreciation! So let's go!

>  So to clarify (hopefully :-): I really like the idea of adding software stacks
> (good name BTW, because I was thinking of "packages of packages" which sounds
> awful). I also like the idea of making it very easy for people to add those
> stacks together. But only if there is a real added value compared to calling
> merge_config.sh directly. Some of my comments in patch 2/3 are meant to go in
> that direction.

My POV is that the intended way to go should be codified in software
and not only in the manual.


>  Also, I only give my own opinion. This may or may not represent the position of
> most of the community.

Well, of course it's your own, but a really inspiring one!

>>>  We discussed such a feature before, but never came up with an elegant way to do
>>> it, and that was better than just calling merge_config.sh.
>>
>> I'm only proposing my POV.
>>
>>>> Having a stack system like the one envisioned in this patch series make possible to do something like this:
>>>>
>>>> make imx6-sabresd_defconfig; make mesa3d-etnaviv_stack qt5-fb_stack qt5-demos_stack; make
>>>
>>>  So yeah, is this really better than
>>>
>>> ./utils/merge_config.sh configs/imx6-sabresd_defconfig
>>> stacks/mesa3d-etnaviv_stack stacks/qt5-fb_stack stacks/qt5-demos_stack; make
>>>
>>> ? Yes, it is significantly shorter, but you can at least use tab-completion.
>>
>> Well, the difference is that on the mailing list or the documentation
>> you can say "there's a defined way in buildroot to do this thing"
>> instead of "you should merge your configurations manually". Explicit
>> is better than implicit!
>
>  Very true. But calling merge_config.sh is also a defined way, isn't it?

Not documented anywhere:

$ rgrep "merge_config" docs/manual/ || echo nothing found
nothing found

>>>  That said, I'm not absolutely opposed to the idea. But I'm not convinced either.
>>
>> It's not a problem for me to have a makefile target or not, I really
>> want to know if it's an acceptance to the idea and if I should spend
>> some time to refine it. If it's a no go, please tell me!
>
>  I don't want to say you shouldn't spend time on it. Perhaps the best approach
> is to start with the stacks themselves and document how to use them, and we can
> add make rules or scripts later on.

Ok, why not. But if the feature is interesting and can be discussed
more, why not starting right from the begging instead of patching
over?

There a feature I included that I really like: if you do a make
list-stacks the first line of the stack will be printed as a
description of the stack. I think this feature should be here right
from the start instead of having the user looking for help file by
file manually. I was thinking to refine it more, having printed the
first commented lines of a stack with something like:

$ make qt5-fb_stack --help
QT5 stack based on the Linux famebuffer

This stack provides a complete QT5 with OPENGL enabled environment.
Of course you should have included an opengl capable driver stack
like mesa3d-etnaviv_stack

>>>  Adding stacks, on the other hand, seems like a worthwhile endeavour.
>>>
>>>> In this way we can declutter redundant configs (ex: imx6-sabresd_qt5_defconfig) and decouple software packages side related symbols from hardware related defconfigs.
>>>
>>>  Not the best example, because imx6-sabresd_qt5_defconfig contains quite a few
>>> board-specific adaptions: a kconfig fragment and a rootfs overlay. And of course
>>> increasing the ext2 rootfs size.
>>>
>>>  A better example would be atmel_sama5d4_xplained_dev_defconfig which is purely
>>> a collection of packages.
>>
>> It was an example. Obviously for the sama5d4, we can have a stack for
>> each board variant to be merged with a base one.
>
>  My point is, the "dev" stack (a collection of development/debug tools +
> enabling BR2_PTHREAD_DEBUG=y) is a more convincing example of why these stacks
> are useful.

Well yes, a stack could be anything. In my POV stacks should be used
at first to declutter config files from packages configurations
before, then I would very see stacks for each sort of complex
configuration that could be tricky to do right like a lamp stack or a
QT5 one.

Stack could also be used to build products and distribute it outside
buildroot (ex on an internal git of a corporate environment). I
imagine a software products that runs on several boards: having a
stack ready made make easy to port it beetween boards without too much
fuss.

Obviously, merge_confg.sh could do the same thing, but hey, having
included such a feature in buildroot looks cool to me!

>
>  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:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF



-- 
Profile: http://it.linkedin.com/in/compagnucciangelo


More information about the buildroot mailing list