python waf bypasses _MAKE_JOBS number

Marcus von Appen mva at freebsd.org
Fri Jan 9 23:29:18 UTC 2015


Sean Bruno <sbruno at ignoranthack.me>:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 01/09/15 11:10, Antoine Brodin wrote:
>> On Fri, Jan 9, 2015 at 5:52 PM, Sean Bruno <sbruno at ignoranthack.me>
>> wrote:
>>> Marcus:
>>>
>>> The thing that I would like "fixed" is python waf ignoring the
>>> fact that it should not try and detect the number of CPUs on the
>>> system.
>>>
>>
>> Let me rephrase the problem,  there are some problems in some
>> individual ports using waf. Those ports do not respect
>> ${MAKE_JOBS_NUMBER},  especially when MAKE_JOBS_NUMBER=1. This
>> breaks qemu which is not multi job friendly  (people using qemu
>> have DISABLE_MAKE_JOBS=yes which sets MAKE_JOBS_NUMBER to 1).
>>
>> Cheers,
>>
>> Antoine
>>
>
> YES.  :-)  Sorry for the confusion.

Just to be a bit more specific: we are not talking about a waf port,
but about some (still unknown) waf scripts in the upstream package,
correct? Since this is the usual way, waf is used.
Please point us to the correct scripts/call hierarchy/whatever that
allows us to investigate, what the port actually does at the build phase.

waf issues usually need to be fixed (since it's somewhat similar to
a cmake, scons or autotools configuration/build file) on the problematic
port or via injection, hence we need the information about how the build
is done or at least a pointer, where to look at.

I'm leaving the threading issue aside here, since (for now) there is not
enough information (for me) to address this. Let's get the build issue
sorted out first, then take a look at Python's threading support for
non-amd64 and non-i386 platforms on FreeBSD.

Cheers
Marcus




More information about the freebsd-python mailing list