This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: revamped gdb_mbuild.sh
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Andrew Cagney <ac131313 at redhat dot com>
- Cc: Richard Earnshaw <rearnsha at arm dot com>, gdb-patches at sources dot redhat dot com
- Date: Tue, 26 Nov 2002 17:30:16 +0000
- Subject: Re: revamped gdb_mbuild.sh
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot com
>
> > How about -c <x> -j <y>? Ie x configures in parallel & y make jobs in
> > parallel?
>
> In that script, a mindless implementation would result in:
>
> -c 2 -j 2
>
> creating two tasks (-c 2), each running 'make -j 2' (for jobs at the max).
>
> Is that your intent? Or, as I suspect, try to sustain two configures
> and a single 'make -j 2'.
>
> Andrew
>
>
Yep, it would mean that in my case you could effectively run -c 1 -j 10
and get fast builds with only the configures dropping down to single
threaded (which would get most of the parallelism with the least transient
disk space use) -- or have -c 2 -j 5 for a bit more configure parallelism
with less make parallelism. It would be a trade off that could be made by
each user, and the load would be the product of the two.
R.