Re: [PATCH] docs: document python version used for compilation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu May 9, 2024 at 6:48 PM CEST, Jonathan Corbet wrote:
> Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx> writes:
>
> > The drm/msm driver had adopted using Python3 script to generate register
> > header files instead of shipping pre-generated header files. Document
> > the minimal Python version supported by the script.
> >
> > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx>
> > ---
> >  Documentation/process/changes.rst | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst
> > index 5685d7bfe4d0..8d225a9f65a2 100644
> > --- a/Documentation/process/changes.rst
> > +++ b/Documentation/process/changes.rst
> > @@ -63,6 +63,7 @@ cpio                   any              cpio --version
> >  GNU tar                1.28             tar --version
> >  gtags (optional)       6.6.5            gtags --version
> >  mkimage (optional)     2017.01          mkimage --version
> > +Python (optional)      3.5.x            python3 --version
> >  ====================== ===============  ========================================
>
> Is it really optional - can you build the driver without it?
>
> This document needs some help... I'm missing a number of things that are
> *not* marked as "optional" (jfsutils, reiserfsprogs, pcmciautils, ppp,
> ...) and somehow my system works fine :)  It would be nice to document
> *why* users might need a specific tool.
>
> But I guess we aren't going to do that now.  I can apply this, but I do
> wonder about the "optional" marking.

I guess it depends a bit on what exactly "optional" implies. It's
optional in the sense that you can easily disable the driver and then
build without Python.

So does "optional" mean that allmodconfig for all platforms builds
without the dependency? Or does it mean some definition of "core" kernel
builds for a set of defined platforms?

Maybe this really needs to be annotated with the exact Kconfig options
that need this. Although that could get out of hands rather quickly. At
some point we may have to list a *lot* of these options.

Alternatively, maybe Kconfig could be taught about build dependencies?

Thierry

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux