* Re: [kconfig-sat] [ANN] init-kconfig - easy way to embrace Linux's kconfig
2018-10-04 20:02 [ANN] init-kconfig - easy way to embrace Linux's kconfig Luis Chamberlain
@ 2018-10-04 20:09 ` Josh Triplett
2018-10-04 20:39 ` Luis Chamberlain
2018-10-05 0:18 ` Randy Dunlap
` (2 subsequent siblings)
3 siblings, 1 reply; 10+ messages in thread
From: Josh Triplett @ 2018-10-04 20:09 UTC (permalink / raw)
To: Luis Chamberlain
Cc: LKML, linux-kbuild, Masahiro Yamada, Randy Dunlap, Sam Ravnborg,
Petr Vorel, Steven Rostedt, Johannes Berg, Valentin Rothberg,
Vegard Nossum, Felix Fietkau, kconfig-sat
On Thu, Oct 04, 2018 at 01:02:49PM -0700, Luis Chamberlain wrote:
> Every now and then a project is born, and they decide to use Linux's
> kconfig to enable configuration of their project. As it stands we *know*
> kconfig is now used in at least over 12 different projects [0]. I myself
> added kconfig to one as well years ago. Even research reveals that
> kconfig has become one of the leading industrial variability modeling
> languages [1] [2].
>
> What is often difficult to do though is to start off using kconfig and
> integrating it into a project. Or updating / syncing to the latest
> kconfig from upstream Linux.
>
> I had yet another need to use kconfig for another small project so
> decided to make a clean template others can use and help keep it in sync.
> This is a passive fork which aims to keep in sync with the Linux
> kernel's latest kconfig to make it easier to keep up to date and to
> enable new projects to use and embrace kconfig on their own. The goal
> is *not* to fork kconfig and evolve it separately, but rather keep in
> sync with the evolution of kconfig on Linux to make it easier for
> projects to use kconfig and also update their own kconfig when needed.
Is there a *fundamental* reason that we couldn't have this *be* Linux
kconfig, whether pulled in by submodule or regular merges, and avoid
having any divergence at all?
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [kconfig-sat] [ANN] init-kconfig - easy way to embrace Linux's kconfig
2018-10-04 20:09 ` [kconfig-sat] " Josh Triplett
@ 2018-10-04 20:39 ` Luis Chamberlain
2018-10-04 20:41 ` Josh Triplett
0 siblings, 1 reply; 10+ messages in thread
From: Luis Chamberlain @ 2018-10-04 20:39 UTC (permalink / raw)
To: Josh Triplett
Cc: LKML, linux-kbuild, Masahiro Yamada, Randy Dunlap, Sam Ravnborg,
Petr Vorel, Steven Rostedt, Johannes Berg, Valentin Rothberg,
Vegard Nossum, Felix Fietkau, kconfig-sat
On Thu, Oct 04, 2018 at 01:09:00PM -0700, Josh Triplett wrote:
> On Thu, Oct 04, 2018 at 01:02:49PM -0700, Luis Chamberlain wrote:
> > Every now and then a project is born, and they decide to use Linux's
> > kconfig to enable configuration of their project. As it stands we *know*
> > kconfig is now used in at least over 12 different projects [0]. I myself
> > added kconfig to one as well years ago. Even research reveals that
> > kconfig has become one of the leading industrial variability modeling
> > languages [1] [2].
> >
> > What is often difficult to do though is to start off using kconfig and
> > integrating it into a project. Or updating / syncing to the latest
> > kconfig from upstream Linux.
> >
> > I had yet another need to use kconfig for another small project so
> > decided to make a clean template others can use and help keep it in sync.
> > This is a passive fork which aims to keep in sync with the Linux
> > kernel's latest kconfig to make it easier to keep up to date and to
> > enable new projects to use and embrace kconfig on their own. The goal
> > is *not* to fork kconfig and evolve it separately, but rather keep in
> > sync with the evolution of kconfig on Linux to make it easier for
> > projects to use kconfig and also update their own kconfig when needed.
>
> Is there a *fundamental* reason that we couldn't have this *be* Linux
> kconfig, whether pulled in by submodule or regular merges, and avoid
> having any divergence at all?
The structure of kconfig in Linux would have to be changed to make
adoption and sync easier. If that is a goal we wish to embrace, I'm
all for it.
Luis
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [kconfig-sat] [ANN] init-kconfig - easy way to embrace Linux's kconfig
2018-10-04 20:39 ` Luis Chamberlain
@ 2018-10-04 20:41 ` Josh Triplett
2018-10-04 20:53 ` Luis Chamberlain
0 siblings, 1 reply; 10+ messages in thread
From: Josh Triplett @ 2018-10-04 20:41 UTC (permalink / raw)
To: Luis Chamberlain
Cc: LKML, linux-kbuild, Masahiro Yamada, Randy Dunlap, Sam Ravnborg,
Petr Vorel, Steven Rostedt, Johannes Berg, Valentin Rothberg,
Vegard Nossum, Felix Fietkau, kconfig-sat
On Thu, Oct 04, 2018 at 01:39:50PM -0700, Luis Chamberlain wrote:
> On Thu, Oct 04, 2018 at 01:09:00PM -0700, Josh Triplett wrote:
> > On Thu, Oct 04, 2018 at 01:02:49PM -0700, Luis Chamberlain wrote:
> > > Every now and then a project is born, and they decide to use Linux's
> > > kconfig to enable configuration of their project. As it stands we *know*
> > > kconfig is now used in at least over 12 different projects [0]. I myself
> > > added kconfig to one as well years ago. Even research reveals that
> > > kconfig has become one of the leading industrial variability modeling
> > > languages [1] [2].
> > >
> > > What is often difficult to do though is to start off using kconfig and
> > > integrating it into a project. Or updating / syncing to the latest
> > > kconfig from upstream Linux.
> > >
> > > I had yet another need to use kconfig for another small project so
> > > decided to make a clean template others can use and help keep it in sync.
> > > This is a passive fork which aims to keep in sync with the Linux
> > > kernel's latest kconfig to make it easier to keep up to date and to
> > > enable new projects to use and embrace kconfig on their own. The goal
> > > is *not* to fork kconfig and evolve it separately, but rather keep in
> > > sync with the evolution of kconfig on Linux to make it easier for
> > > projects to use kconfig and also update their own kconfig when needed.
> >
> > Is there a *fundamental* reason that we couldn't have this *be* Linux
> > kconfig, whether pulled in by submodule or regular merges, and avoid
> > having any divergence at all?
>
> The structure of kconfig in Linux would have to be changed to make
> adoption and sync easier. If that is a goal we wish to embrace, I'm
> all for it.
I would *love* to see Kconfig in Linux evolved to be more easily reused.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [kconfig-sat] [ANN] init-kconfig - easy way to embrace Linux's kconfig
2018-10-04 20:41 ` Josh Triplett
@ 2018-10-04 20:53 ` Luis Chamberlain
2018-10-04 22:05 ` Steven Rostedt
0 siblings, 1 reply; 10+ messages in thread
From: Luis Chamberlain @ 2018-10-04 20:53 UTC (permalink / raw)
To: Josh Triplett
Cc: LKML, linux-kbuild, Masahiro Yamada, Randy Dunlap, Sam Ravnborg,
Petr Vorel, Steven Rostedt, Johannes Berg, Valentin Rothberg,
Vegard Nossum, Felix Fietkau, kconfig-sat
On Thu, Oct 04, 2018 at 01:41:18PM -0700, Josh Triplett wrote:
> I would *love* to see Kconfig in Linux evolved to be more easily reused.
This *can* happen. Let me itemize a few things off of my head I think
would need to be done as its at least fresh in my head now:
All we need from scripts/Kbuild.include is filechk and kecho (what I
have in my scripts/Kbuild.include). This could be moved to
scripts/Kbuild.basic, and so would make sync'ing easier.
The scripts/kconfig/Makefile would need a respective modifications to
make it work independently, see my scripts/kconfig/Makefile. Perhaps
the biggest pain was resolving the target for
scripts/kconfig/.mconf-cfg. If somehow we end up with a file which could
work for both environments we're set.
Other than this we'd need a simple script, say scripts/copy-kconfig.sh
which would copy over only those files I took from scripts/kconfig.
There's a few things to consider for a split copy / demo:
* versioning *is not* part of kconfig
* object building *is not* part of kconfig
But the problem I faced was that to demo kconfig I had to use *something*
for versioning and object building. The object building is simple, and
the versioning scheme was just copied from Linux.
What I ended up with the smallest demo I could come up with.
Luis
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [kconfig-sat] [ANN] init-kconfig - easy way to embrace Linux's kconfig
2018-10-04 20:53 ` Luis Chamberlain
@ 2018-10-04 22:05 ` Steven Rostedt
0 siblings, 0 replies; 10+ messages in thread
From: Steven Rostedt @ 2018-10-04 22:05 UTC (permalink / raw)
To: Luis Chamberlain
Cc: Josh Triplett, LKML, linux-kbuild, Masahiro Yamada, Randy Dunlap,
Sam Ravnborg, Petr Vorel, Johannes Berg, Valentin Rothberg,
Vegard Nossum, Felix Fietkau, kconfig-sat
On Thu, 4 Oct 2018 13:53:19 -0700
Luis Chamberlain <mcgrof@kernel.org> wrote:
> On Thu, Oct 04, 2018 at 01:41:18PM -0700, Josh Triplett wrote:
> > I would *love* to see Kconfig in Linux evolved to be more easily reused.
>
> This *can* happen. Let me itemize a few things off of my head I think
> would need to be done as its at least fresh in my head now:
>
> All we need from scripts/Kbuild.include is filechk and kecho (what I
> have in my scripts/Kbuild.include). This could be moved to
> scripts/Kbuild.basic, and so would make sync'ing easier.
>
> The scripts/kconfig/Makefile would need a respective modifications to
> make it work independently, see my scripts/kconfig/Makefile. Perhaps
> the biggest pain was resolving the target for
> scripts/kconfig/.mconf-cfg. If somehow we end up with a file which could
> work for both environments we're set.
>
> Other than this we'd need a simple script, say scripts/copy-kconfig.sh
> which would copy over only those files I took from scripts/kconfig.
>
> There's a few things to consider for a split copy / demo:
>
> * versioning *is not* part of kconfig
> * object building *is not* part of kconfig
>
> But the problem I faced was that to demo kconfig I had to use *something*
> for versioning and object building. The object building is simple, and
> the versioning scheme was just copied from Linux.
>
> What I ended up with the smallest demo I could come up with.
>
Are you attending Linux Plumbers in Vancouver? Because I think this
would be a very interesting BoF there.
-- Steve
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [ANN] init-kconfig - easy way to embrace Linux's kconfig
2018-10-04 20:02 [ANN] init-kconfig - easy way to embrace Linux's kconfig Luis Chamberlain
2018-10-04 20:09 ` [kconfig-sat] " Josh Triplett
@ 2018-10-05 0:18 ` Randy Dunlap
2018-10-05 10:48 ` Masahiro Yamada
2018-10-06 5:53 ` Ulf Magnusson
3 siblings, 0 replies; 10+ messages in thread
From: Randy Dunlap @ 2018-10-05 0:18 UTC (permalink / raw)
To: Luis Chamberlain, LKML, linux-kbuild, Masahiro Yamada
Cc: Sam Ravnborg, Petr Vorel, Steven Rostedt, Johannes Berg,
Valentin Rothberg, Vegard Nossum, Felix Fietkau, kconfig-sat,
Ulf Magnusson
On 10/4/18 1:02 PM, Luis Chamberlain wrote:
> Every now and then a project is born, and they decide to use Linux's
> kconfig to enable configuration of their project. As it stands we *know*
> kconfig is now used in at least over 12 different projects [0]. I myself
> added kconfig to one as well years ago. Even research reveals that
> kconfig has become one of the leading industrial variability modeling
> languages [1] [2].
>
> What is often difficult to do though is to start off using kconfig and
> integrating it into a project. Or updating / syncing to the latest
> kconfig from upstream Linux.
>
> I had yet another need to use kconfig for another small project so
> decided to make a clean template others can use and help keep it in sync.
> This is a passive fork which aims to keep in sync with the Linux
> kernel's latest kconfig to make it easier to keep up to date and to
> enable new projects to use and embrace kconfig on their own. The goal
> is *not* to fork kconfig and evolve it separately, but rather keep in
> sync with the evolution of kconfig on Linux to make it easier for
> projects to use kconfig and also update their own kconfig when needed.
>
> This may also be useful if folks want to test R&D code on a smaller
> compartamentalized codebase.
>
> If you find this useful and you'd like to help keep it in sync, send
> patches my way as the kernel's kconfig evolves. The code is up on
> gitlab [3].
>
> Do we want to document this option on Linux in case folks want to try
> and embrace kconfig on their own for other projects?
>
> [0] http://www.eng.uwaterloo.ca/~shshe/kconfig_semantics.pdf
> [1] http://gsd.uwaterloo.ca/sites/default/files/vm-2013-berger.pdf
> [2] http://gsd.uwaterloo.ca/sites/default/files/ase241-berger_0.pdf
> [3] https://gitlab.com/mcgrof/init-kconfig
>
> Luis
>
Hi Luis,
Any crossover with Ulf's recent announcement?
https://lore.kernel.org/lkml/CAFkk2KQ-sC=bAd9fCkOVPNmZn8m+EZfpZtirE+J5VpvW120sxQ@mail.gmail.com/
thanx,
--
~Randy
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [ANN] init-kconfig - easy way to embrace Linux's kconfig
2018-10-04 20:02 [ANN] init-kconfig - easy way to embrace Linux's kconfig Luis Chamberlain
2018-10-04 20:09 ` [kconfig-sat] " Josh Triplett
2018-10-05 0:18 ` Randy Dunlap
@ 2018-10-05 10:48 ` Masahiro Yamada
2018-11-21 22:58 ` [kconfig-sat] " Luis Chamberlain
2018-10-06 5:53 ` Ulf Magnusson
3 siblings, 1 reply; 10+ messages in thread
From: Masahiro Yamada @ 2018-10-05 10:48 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Linux Kernel Mailing List, Linux Kbuild mailing list,
Randy Dunlap, Sam Ravnborg, Petr Vorel, Steven Rostedt,
Johannes Berg, Valentin Rothberg, Vegard Nossum, nbd,
kconfig-sat
Hi,
On Fri, Oct 5, 2018 at 5:03 AM Luis Chamberlain <mcgrof@kernel.org> wrote:
>
> Every now and then a project is born, and they decide to use Linux's
> kconfig to enable configuration of their project. As it stands we *know*
> kconfig is now used in at least over 12 different projects [0]. I myself
> added kconfig to one as well years ago. Even research reveals that
> kconfig has become one of the leading industrial variability modeling
> languages [1] [2].
>
> What is often difficult to do though is to start off using kconfig and
> integrating it into a project. Or updating / syncing to the latest
> kconfig from upstream Linux.
>
> I had yet another need to use kconfig for another small project so
> decided to make a clean template others can use and help keep it in sync.
> This is a passive fork which aims to keep in sync with the Linux
> kernel's latest kconfig to make it easier to keep up to date and to
> enable new projects to use and embrace kconfig on their own. The goal
> is *not* to fork kconfig and evolve it separately, but rather keep in
> sync with the evolution of kconfig on Linux to make it easier for
> projects to use kconfig and also update their own kconfig when needed.
Syncing kconfig files is easy
since the files are collected in the single place, scripts/kconfig/.
It is true you need some efforts to introduce Kconfig in your project,
but once established, it is just a matter of copying files
under scripts/kconfig.
Copying stuff directly from Linux would be as easy as
doing so from your init-kconfig.
> This may also be useful if folks want to test R&D code on a smaller
> compartamentalized codebase.
>
> If you find this useful and you'd like to help keep it in sync, send
> patches my way as the kernel's kconfig evolves. The code is up on
> gitlab [3].
>
> Do we want to document this option on Linux in case folks want to try
> and embrace kconfig on their own for other projects?
>
> [0] http://www.eng.uwaterloo.ca/~shshe/kconfig_semantics.pdf
> [1] http://gsd.uwaterloo.ca/sites/default/files/vm-2013-berger.pdf
> [2] http://gsd.uwaterloo.ca/sites/default/files/ase241-berger_0.pdf
> [3] https://gitlab.com/mcgrof/init-kconfig
>
> Luis
Looks like init-kconfig is trying to build some objects as demo.
obj-y = main.o
obj-$(CONFIG_FOO) += foo.o
obj-$(CONFIG_BAR) += bar.o
obj-$(CONFIG_BAZ) += baz.o
obj-$(CONFIG_ALPHA) += alpha/
FWIW, this is something I played with some time ago.
Kbuild Skeleton
https://github.com/masahir0y/kbuild_skeleton
It consists of some core Makefiles and Kconfig.
From the time-stamp, it is already 6 years too old.
I am not sure if it is useful for people,
if so, it is pretty easy to sync up with the latest Linux.
--
Best Regards
Masahiro Yamada
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [kconfig-sat] Re: [ANN] init-kconfig - easy way to embrace Linux's kconfig
2018-10-05 10:48 ` Masahiro Yamada
@ 2018-11-21 22:58 ` Luis Chamberlain
0 siblings, 0 replies; 10+ messages in thread
From: Luis Chamberlain @ 2018-11-21 22:58 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Linux Kernel Mailing List, Linux Kbuild mailing list,
Randy Dunlap, Sam Ravnborg, Petr Vorel, Steven Rostedt,
Johannes Berg, Valentin Rothberg, Vegard Nossum, nbd,
kconfig-sat
On Fri, Oct 05, 2018 at 07:48:34PM +0900, Masahiro Yamada wrote:
> Hi,
>
>
>
> On Fri, Oct 5, 2018 at 5:03 AM Luis Chamberlain <mcgrof@kernel.org> wrote:
> >
> > Every now and then a project is born, and they decide to use Linux's
> > kconfig to enable configuration of their project. As it stands we *know*
> > kconfig is now used in at least over 12 different projects [0]. I myself
> > added kconfig to one as well years ago. Even research reveals that
> > kconfig has become one of the leading industrial variability modeling
> > languages [1] [2].
> >
> > What is often difficult to do though is to start off using kconfig and
> > integrating it into a project. Or updating / syncing to the latest
> > kconfig from upstream Linux.
> >
> > I had yet another need to use kconfig for another small project so
> > decided to make a clean template others can use and help keep it in sync.
> > This is a passive fork which aims to keep in sync with the Linux
> > kernel's latest kconfig to make it easier to keep up to date and to
> > enable new projects to use and embrace kconfig on their own. The goal
> > is *not* to fork kconfig and evolve it separately, but rather keep in
> > sync with the evolution of kconfig on Linux to make it easier for
> > projects to use kconfig and also update their own kconfig when needed.
>
>
> Syncing kconfig files is easy
I disagree. Even as someone who has done this in the past and is an
experience developer it hasn't been a swift process by any mean.
> since the files are collected in the single place, scripts/kconfig/.
That helps, but isn't enough.
> It is true you need some efforts to introduce Kconfig in your project,
> but once established, it is just a matter of copying files
> under scripts/kconfig.
Nope, there is other random subtle work needed, a few of things which
I noted earlier before I forgot what things I had to do / change manually
which we not obvious.
> Copying stuff directly from Linux would be as easy as
> doing so from your init-kconfig.
Clearly I disagree, the idea with init-kconfig is the process of
upkeeping is done centrally, and so users really do just take that
and go.
If we want to make the process smoother upstream, then great.
> > This may also be useful if folks want to test R&D code on a smaller
> > compartamentalized codebase.
> >
> > If you find this useful and you'd like to help keep it in sync, send
> > patches my way as the kernel's kconfig evolves. The code is up on
> > gitlab [3].
> >
> > Do we want to document this option on Linux in case folks want to try
> > and embrace kconfig on their own for other projects?
> >
> > [0] http://www.eng.uwaterloo.ca/~shshe/kconfig_semantics.pdf
> > [1] http://gsd.uwaterloo.ca/sites/default/files/vm-2013-berger.pdf
> > [2] http://gsd.uwaterloo.ca/sites/default/files/ase241-berger_0.pdf
> > [3] https://gitlab.com/mcgrof/init-kconfig
> >
> > Luis
>
>
> Looks like init-kconfig is trying to build some objects as demo.
>
> obj-y = main.o
> obj-$(CONFIG_FOO) += foo.o
> obj-$(CONFIG_BAR) += bar.o
> obj-$(CONFIG_BAZ) += baz.o
> obj-$(CONFIG_ALPHA) += alpha/
Indeed, we are spoiled with our build process. Mimicing this was
actually a separate effort, and so I didn't match on par, but just
enough to demo a basic use.
> FWIW, this is something I played with some time ago.
>
> Kbuild Skeleton
> https://github.com/masahir0y/kbuild_skeleton
>
> It consists of some core Makefiles and Kconfig.
>
>
> From the time-stamp, it is already 6 years too old.
>
> I am not sure if it is useful for people,
> if so, it is pretty easy to sync up with the latest Linux.
Groovy, indeed this is useful thanks. I still think this process can
be improved to allow perhaps both kconfig and its object makefiles magic
& dependency tracking thing be easily sharable. I however understand if
we don't want that to be a goal, there would have to be obvious gains
for it. I don't think we're there yet. Right now it would just make it
easier for enhancements to trickle out to the community and/or fixes to
bubble up, however I don't expect many people doing much kconfig hacking
outside of Linux. Perhaps the best advantage I can think for this as a
goal for us right now is to enable researchers with sandboxes, proof of
concepts, so that we can eventually get the fruits of such work.
Luis
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [ANN] init-kconfig - easy way to embrace Linux's kconfig
2018-10-04 20:02 [ANN] init-kconfig - easy way to embrace Linux's kconfig Luis Chamberlain
` (2 preceding siblings ...)
2018-10-05 10:48 ` Masahiro Yamada
@ 2018-10-06 5:53 ` Ulf Magnusson
3 siblings, 0 replies; 10+ messages in thread
From: Ulf Magnusson @ 2018-10-06 5:53 UTC (permalink / raw)
To: Luis R . Rodriguez
Cc: Linux Kernel Mailing List, Linux Kbuild mailing list,
Masahiro Yamada, Randy Dunlap, Sam Ravnborg, pvorel, rostedt,
johannes, valentinrothberg, vegard.nossum, nbd, kconfig-sat
On Thu, Oct 4, 2018 at 10:03 PM Luis Chamberlain <mcgrof@kernel.org> wrote:
>
> Every now and then a project is born, and they decide to use Linux's
> kconfig to enable configuration of their project. As it stands we *know*
> kconfig is now used in at least over 12 different projects [0]. I myself
> added kconfig to one as well years ago. Even research reveals that
> kconfig has become one of the leading industrial variability modeling
> languages [1] [2].
>
> What is often difficult to do though is to start off using kconfig and
> integrating it into a project. Or updating / syncing to the latest
> kconfig from upstream Linux.
>
> I had yet another need to use kconfig for another small project so
> decided to make a clean template others can use and help keep it in sync.
> This is a passive fork which aims to keep in sync with the Linux
> kernel's latest kconfig to make it easier to keep up to date and to
> enable new projects to use and embrace kconfig on their own. The goal
> is *not* to fork kconfig and evolve it separately, but rather keep in
> sync with the evolution of kconfig on Linux to make it easier for
> projects to use kconfig and also update their own kconfig when needed.
>
> This may also be useful if folks want to test R&D code on a smaller
> compartamentalized codebase.
>
> If you find this useful and you'd like to help keep it in sync, send
> patches my way as the kernel's kconfig evolves. The code is up on
> gitlab).) [3].
>
> Do we want to document this option on Linux in case folks want to try
> and embrace kconfig on their own for other projects?
>
> [0] http://www.eng.uwaterloo.ca/~shshe/kconfig_semantics.pdf
> [1] http://gsd.uwaterloo.ca/sites/default/files/vm-2013-berger.pdf
> [2] http://gsd.uwaterloo.ca/sites/default/files/ase241-berger_0.pdf
> [3] https://gitlab.com/mcgrof/init-kconfig
>
> Luis
Shameless self-plug:
There's also a Python Kconfig implementation that's starting to get
picked up by several projects: https://github.com/ulfalizer/kconfiglib
It has a terminal menuconfig interface with a lot more features than
mconf (a demonstration is available at
https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/menuconfig.gif),
and can also be used e.g. to generate cross-referenced Kconfig
documentation that includes propagated dependencies:
https://docs.zephyrproject.org/latest/reference/kconfig/index.html
(note: heavy page).
Kconfiglib is based around a library (an old version appears in e.g.
U-Boot and Yocto, and a newer version in e.g. Espressif). The
documentation generation is just a script
(https://github.com/zephyrproject-rtos/zephyr/blob/master/doc/scripts/genrest.py),
and the same goes for the menuconfig and the other tools. The core
library takes part of all the trickiness related to evaluating
symbols.
I realize there would probably be massive opposition to adding a
Python dependency to a core part of the kernel, so I'm not going for
that. For most other projects, I think it's a good fit though.
Cheers,
Ulf
^ permalink raw reply [flat|nested] 10+ messages in thread