[PATCH 29] Re: Disabling Python Modules
Andrew Bartlett
abartlet at samba.org
Fri Jan 27 19:46:13 UTC 2017
On Fri, 2017-01-27 at 11:36 -0500, Ian Stakenvicius wrote:
> On 27/01/17 01:10 AM, Andrew Bartlett wrote:
> > On Wed, 2017-01-25 at 23:56 -0500, Ian Stakenvicius wrote:
> > > On 25/01/17 03:29 AM, Stefan Metzmacher wrote:
> > > > Hi Ian,
> > > >
> > > > > I can't be certain, but I think that may indeed be the last
> > > > > of
> > > > > them.
> > > > > All wscript_build files that contain modules with deps=
> > > > > including
> > > > > py*util, and LIBPYTHON, are now all covered.
> > > >
> > > > I know I'm late in the discussion, but is there a chance
> > > > that we could avoid all changes like this:
> > > >
> > > > -bld.SAMBA3_PYTHON('pys3param',
> > > > +if not bld.env.disable_python:
> > > > + bld.SAMBA3_PYTHON('pys3param',
> > > >
> > > > And just to that globally within SAMBA_PYTHON()
> > > > instead of changing each caller?
> > >
> > >
> > > I considered doing that, but decided against it due to the fact
> > > that
> > > this hides too much from the wscript_build of each module. When
> > > a
> > > bld.env.disable_python conditional exists it makes it clear that
> > > all
> > > components the conditional applies to (whether SAMBA_PYTHON() or
> > > not,
> > > and there's more than a few that aren't SAMBA_PYTHON()).
> > >
> > >
> > >
> > > > [...]
> > > >
> > > > For all others we should use something like
> > > > enabled=bld.PYTHON_BUILD_IS_ENABLED(),
> > > > see git grep 'enabled=' for examples.
> > >
> > >
> > > Is this just for style? or..
> >
> > No, it is more than style. It allows the build system to know that
> > the
> > name of the target subsystem exists, but it not in use. This
> > allows
> > dependencies to be resolved as nothing, rather than having 'if
> > python'
> > in dep strings. While this may just move the dep problem to the C
> > layer, it allow an #ifdef at that layer.
> >
> > It is also cleaner, in general, and while not totally consistent,
> > it is
> > how we have tried to handle other features.
> >
>
> Makes sense. Is there a particular use of this form already in the
> build system that you would recommend I mirror for the implementation
> of PYTHON_BUILD_IS_ENABLED()? Or does waf already provide that
> simply
> because the configure flag exists?
The normal way would be to check:
bld.CONFIG_SET('HAVE_PYTHON')
In your first patch the detection is a little odd. It seems we still
look for python even if disabled?
conf.SAMBA_CHECK_PYTHON(mandatory=True, version=(2, 6, 0))
- conf.SAMBA_CHECK_PYTHON_HEADERS(mandatory=True)
+ if conf.env.disable_python:
+ conf.SAMBA_CHECK_PYTHON_HEADERS(mandatory=False)
+ else:
+ conf.SAMBA_CHECK_PYTHON_HEADERS(mandatory=True)
Shouldn't it be:
if not conf.env.disable_python:
conf.SAMBA_CHECK_PYTHON(mandatory=True, version=(2, 6, 0))
conf.SAMBA_CHECK_PYTHON_HEADERS(mandatory=True)
or such?
> Also, does this mean that the various SAMBA_LIBRARY() modules I'm
> turning off due to their dependency on, say, LIBPYTHON, will now also
> need to be patched in C so that things won't fail? Or will the
> module
> still be skipped by the build system since 'enabled=' is false?
It may be cleaner to handle some of it there, rather than a cascade of
dependencies.
See what still needs to be disabled once you do this, and once you no
longer need to care about stuff already disabled by --without-samba-ad-
dc
BTW I'm quite suspicious of
Subject: [PATCH 11/28] waf: disable-python - don't build libcli echo
torture test
What does this have to do with python?
> > > > I think we should also have the --disable-python option
> > > > near to the --extra-python option within
> > > > buildtools/wafsamba/wscript, so that it is also available
> > > > for the standalone builds of talloc, tevent, tdb and ldb.
> > >
> > >
> > > --disable-python is already in the standalone builds, I don't
> > > recall
> > > patching that in except maybe for one of those; most if not all
> > > of
> > > the
> > > changes to those modules was to allow the pre-existing
> > > --disable-python functionality to apply when it's _not_ being
> > > built
> > > standalone.
> >
> > I think having this all in one place is still a good idea however.
> >
>
> I'll have to revisit the multi-python patchset to see where the
> --extra-python options are going. Aligning them should not be an
> issue at all.
Thanks.
> > > >
> > > > For the samba build I think --disable-python give an error
> > > > unless --without-ad-dc is also given as an ad-dc really
> > > > requires
> > > > python bindings.
> > >
> > >
> > > I believe I tested this one and it works out fine
> >
> > I'm sorry, the Samba AD DC strictly requires python. I don't know
> > what
> > you tested (presumably just that the binaries built), but building
> > with
> > the AD DC enabled needs to fail totally and early, to save
> > everybody
> > time and hair.
>
> I tested that if ADDC was set to be "enabled" at configure time, that
> the build process overall still successfully completed, yes. As I
> mentioned, likely ADDC was almost of not entirely skipped however and
> certainly it (as well as likely other features) would not be usable
> in
> any disable-python case.
>
> SO, to accomplish what's described here:
>
> (A) what other features are python-only or are otherwise useless to
> build when there isn't any python, so I can turn them all off at the
> same time?
So far just the AD DC.
> (B) the action taken: to me --disable-python without any addc options
> should just disable addc, while --disable-python and --with-addc
> should error. Does that make sense or should --disable-python always
> error unless all of the dependent features are disabled?
--disable-python should error unless all of the dependent features are
disabled. While it looks like this will become a supported feature,
the target is for folks already setting --without-ad-dc and I really
want folks to realise what they are missing out on.
If we don't, I'm quite confident we will get a user saying 'I built
with --disable-python because I don't like python, why can't I use the
AD DC!' ;-)
Thanks,
Andrew Bartlett
--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Catalyst IT http://catalyst.net.nz/services/samba
More information about the samba-technical
mailing list