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

Andrew Bartlett abartlet at samba.org
Sun Feb 19 10:03:03 UTC 2017


On Mon, 2017-02-13 at 11:28 -0500, Ian Stakenvicius wrote:
> 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.o
> > > > > rg> 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?

I'll look at this tomorrow.  I agree it sounds like a bit of a hack.

Amitay,

Do you have any thoughts on this?

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