[PATCHv2 1-14/14] Re: Disabling Python Modules

Ian Stakenvicius axs at gentoo.org
Mon Feb 13 16:28:38 UTC 2017


On 13/02/17 10:34 AM, Ian Stakenvicius wrote:
> On 13/02/17 09:51 AM, Ian Stakenvicius wrote:
>> On 09/02/17 02:26 PM, Ian Stakenvicius wrote:
>>>
>>>> On Feb 9, 2017, at 1:45 PM, Andrew Bartlett <abartlet at samba.org> wrote:
>>>>
>>>> Sadly this sill doesn't pass autobuild, this time on ctdb.   I'll add
>>>> it to my stack to look at today, but if I don't get back to you can you
>>>> please run:
>>>>
>>>> ./script/autobuild.py ctdb --testbase=/tmp
>>>>
>>>> locally.  Sadly ctdb is not set up on travis as it exceeded the
>>>> resource limits or was flapping (I can't remember which). 
>>>>
>>>
>>
>> OK, so the reason this fails is because right now, python is required
>> (by design) for a standalone CTDB build.  I would -expect- that this
>> is the true case, which means it's autobuild.py that needs adjusting
>> rather than ctdb, correct?
>>
>> Or should ctdb's wscript be patched to permit building it standalone
>> without python?
>>
> 
> Sorry, I was very wrong on my initial evaluation..  I'll report back
> after I've finished some additional investigations.


OK, what's really happening is this:

ctdb, when building standalone, forces Options.options.disable_python
= True in order to avoid its dependencies having to build python, as
apparently it doesn't need python from them.  Immediately afterwards
it checks mandatorily for python headers.  Since disable_python is now
global, python's header check fails because you can't force the python
headers check when you've requested python be disabled.

Forcing Options.options.disable_python = True in the current module in
order for submodules to "inherit" said configuration seems like a bit
of a hack to me, to be honest, and so I would like to focus on
changing that for the fix.  I've added a commit (see github PR#74)
that just moves that particular assignment down to just before the
conf.RECURSE calls, and autobuild on ctdb works just fine now, but i'm
not sure if overwriting settings to the current module's
Options.options object is really the right way to go to accomplish
what this is meant to do?



-------------- 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/20170213/83292e6c/signature.sig>


More information about the samba-technical mailing list