Message ID | 1507668210-5427-1-git-send-email-angelo.compagnucci@gmail.com |
---|---|
Headers | show |
Series | Adding software stacks | expand |
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? 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. > 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. That said, I'm not absolutely opposed to the idea. But I'm not convinced either. 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 releated 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. Regards, Arnout > > > Angelo Compagnucci (3): > support/kconfig/merge_config.sh: merge also buildroot config files > Makefile: add handling of software stacks > stacks: add a bunch of stacks > > Makefile | 40 ++++++++++++++++++++++++++++++++++++++-- > stacks/lamp_stack | 10 ++++++++++ > stacks/mesa3d-etnaviv_stack | 7 +++++++ > stacks/qt5-demos_stack | 7 +++++++ > stacks/qt5-fb_stack | 11 +++++++++++ > support/kconfig/merge_config.sh | 16 +++++++++++++++- > 6 files changed, 88 insertions(+), 3 deletions(-) > create mode 100644 stacks/lamp_stack > create mode 100644 stacks/mesa3d-etnaviv_stack > create mode 100644 stacks/qt5-demos_stack > create mode 100644 stacks/qt5-fb_stack >
Dear Arnout Vandecappelle 2017-10-11 23:38 GMT+02:00 Arnout Vandecappelle <arnout@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? > 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! > 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! > 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. > > > Regards, > Arnout > > >> >> >> Angelo Compagnucci (3): >> support/kconfig/merge_config.sh: merge also buildroot config files >> Makefile: add handling of software stacks >> stacks: add a bunch of stacks >> >> Makefile | 40 ++++++++++++++++++++++++++++++++++++++-- >> stacks/lamp_stack | 10 ++++++++++ >> stacks/mesa3d-etnaviv_stack | 7 +++++++ >> stacks/qt5-demos_stack | 7 +++++++ >> stacks/qt5-fb_stack | 11 +++++++++++ >> support/kconfig/merge_config.sh | 16 +++++++++++++++- >> 6 files changed, 88 insertions(+), 3 deletions(-) >> create mode 100644 stacks/lamp_stack >> create mode 100644 stacks/mesa3d-etnaviv_stack >> create mode 100644 stacks/qt5-demos_stack >> create mode 100644 stacks/qt5-fb_stack >> > > -- > 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
On 12-10-17 08:13, Angelo Compagnucci wrote: > Dear Arnout Vandecappelle > > 2017-10-11 23:38 GMT+02:00 Arnout Vandecappelle <arnout@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 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. Also, I only give my own opinion. This may or may not represent the position of most of the community. >> 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? >> 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. >> 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. Regards, Arnout
Dear Arnout Vandecappelle, 2017-10-13 8:31 GMT+02:00 Arnout Vandecappelle <arnout@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@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