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 15:40:09 +0000
- Subject: Re: revamped gdb_mbuild.sh
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot com
> > Richard,
> >>
> >> Finally got to trying the gdb_mbuild.sh script and, in the process,
> >> integrated some, er, `new features' from my old local script:
> >>
> >
> >
> > Looks pretty good to me. My only comment is that we loose the ability to
> > run gnumake with -j <n> replacing it with simultaneous configures/builds
> > of different targets. That means a higher transient disk usage (storage)
> > which would be a marginal problem for me due to lack of disk quota on the
> > multi-way machines... ;-( But that's me thinking about my environment, so
> > it isn't a major objection
>
> I was wondering about a schema where one resource was allocated to
> configure while the remaining N-1 were allocated to a single build.
> That would mean an even faster turnaround on the first build (which I've
> found is what I'm after :-).
>
> I guess we just wonder ...
>
> Andrew
>
>
How about -c <x> -j <y>? Ie x configures in parallel & y make jobs in
parallel?
R.