[Scons-users] Prioritization of builds

[Bill Deegan]

Brian,



On Fri, Jan 15, 2016 at 3:38 PM, Brian Cody <brian.j.cody at gmail.com> wrote:

> Bill,
>
> Isn't that just the same effect as adding some sort of fake dependency?
>
Yes. But it would work. and possibly if the run time issue is that the N
runs of slow license limited tool are serialized at the end, it might
improve run times.
Out of curiosity is the limitation on run per machine, or just one run at a
time?


> The goal is to minimize the wall clock time of the build. Would it be
> un-sconsy to allow the user to inject some sort of comparator that SCons
> could invoke to decide the order of ready-to-build targets?
>
What feels un-sconsy to me is the user telling SCons the order to execute
rather than laying out the dependencies.
Perhaps a better way to do this is to specify the relative speed of
builders and let that factor into scons' scheduling.

Either way it'd be a deep dive into the Taskmaster to do this. (core code).

=-Bill


> Thanks
> On Jan 15, 2016 1:09 PM, "Bill Deegan" <bill at baddogconsulting.com> wrote:
>
>> Brian,
>>
>> The short answer is not right now.
>> The long answer is.. to provide explicit "hinting" it would likely
>> require major changing of internals to add a build order priority, and
>> would be kind of "un-SConsy"
>>
>> That said.
>> scons -j 10 <my list of these targets or an alias which collects them all>
>> scons
>>
>> Might get you close to what you want with very little work..
>>
>> -Bill
>>
>> On Fri, Jan 15, 2016 at 10:02 AM, Brian Cody <brian.j.cody at gmail.com>
>> wrote:
>>
>>> Hello fellow sconsians,
>>>
>>> Let's say I have 1000 targets to build. There are some dependencies
>>> between them but over all there's a considerable amount of parallelism
>>> possible. Now let's say 10 of those targets require the use of a licensed
>>> tool which can only run one at a time. I use a side effect to enforce that
>>> with those 10 targets. I typically run with -j12 or so, one for each
>>> virtual core available. This works, and I'm happy.
>>>
>>> Except.. Those 10 builds I mentioned just happen to be very slow. The
>>> final target built will always be one of those ten. That's fine. However,
>>> the build will take much longer than necessary if it doesn't happen to
>>> start building those targets early. And doing that would require that their
>>> dependencies are also built early. However for some reason, these targets
>>> seem to always get started towards the end of the build.
>>>
>>> Today this is a minor annoyance. It may be adding 30 seconds to a 1
>>> minute 30 second build. Looking in my crystal ball this problem will be
>>> getting much much worse with some of the new targets that are coming.
>>>
>>> Is there a known way to influence the order at which targets are built
>>> without introducing phony dependencies or side effects? So if A and B are
>>> both ready to built right now, and one job-doer becomes available, is there
>>> any way I can cause SCons to pick them up in a particular order? Maybe by
>>> influencing a container holding onto targets?
>>>
>>> Thank you!
>>>
>>> _______________________________________________
>>> Scons-users mailing list
>>> Scons-users at scons.org
>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>
>>>
>>
>> _______________________________________________
>> Scons-users mailing list
>> Scons-users at scons.org
>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>
>>
> _______________________________________________
> Scons-users mailing list
> Scons-users at scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20160115/5e193a32/attachment-0001.html>