[PATCH 29] Re: Disabling Python Modules

[Ian Stakenvicius]

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?

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?


>>> 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.


>>>
>>> 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?

(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?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20170127/ea465b06/signature.sig>