[PATCH v5 02/29] kconfig: Add tools support to CONFIG_IS_ENABLED()

[Simon Glass]

Hi Tom,

On Wed, 6 Oct 2021 at 20:52, Tom Rini <trini at konsulko.com> wrote:
>
> On Wed, Oct 06, 2021 at 08:49:13PM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Wed, 6 Oct 2021 at 18:26, Tom Rini <trini at konsulko.com> wrote:
> > >
> > > On Sat, Sep 25, 2021 at 07:43:15PM -0600, Simon Glass wrote:
> > >
> > > > At present we must separately test for the host build for many options,
> > > > since we force them to be enabled. For example, CONFIG_FIT is always
> > > > enabled in the host tools, even if CONFIG_FIT is not enabled by the
> > > > board itself.
> > > >
> > > > It would be more convenient if we could use, for example,
> > > > CONFIG_IS_ENABLED(FIT) and get CONFIG_HOST_FIT, when building for the
> > > > host. Add support for this.
> > > >
> > > > With this and the tools_build() function, we should be able to remove all
> > > > the #ifdefs currently needed in code that is build by tools and targets.
> > > >
> > > > This will be even nicer when we move to using CONFIG(xxx) everywhere,
> > > > since all the #ifdef and IS_ENABLED/CONFIG_IS_ENABLED stuff will go away.
> > > >
> > > > Signed-off-by: Simon Glass <sjg at chromium.org>
> > > > Suggested-by: Rasmus Villemoes <rasmus.villemoes at prevas.dk> # b4f73886
> > > > Reviewed-by: Alexandru Gagniuc <mr.nuke.me at gmail.com>
> > >
> > > The problem here is we don't include <linux/kconfig.h> automatically
> > > when building host stuff, I believe.  This is why doing this breaks
> > > test_mkimage_hashes for me on am335x_evm with:
> > > /tmp/.bm-work/am335x_evm/tools/mkimage -D -I dts -O dtb -i /tmp/.bm-work/am335x_evm -f /home/trini/work/u-boot/u-boot/test/py/tests/vboot//hash-images.its /tmp/.bm-work/am335x_evm/test.fit
> > > *** stack smashing detected ***: <unknown> terminated
> >
> > Oh dear, and no CI coverage.
> >
> > I was reluctant to include kconfig.h everywhere but perhaps that is
> > the best approach. Will take a look ASAP.
>
> Maybe we need to think a bit harder too about how we structure
> intentionally shared code.
>
> Why not, for example, for these common algorithms, rely on typical
> system headers/libraries in the tooling, which means we validated U-Boot
> vs common reference, rather than just our implementations?

Do you mean we use openssl for sha1, for example?

Regards,
Simon