This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: (toplevel) introduce host subdir configuration in Makefile
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Nathanael Nerode <neroden at twcny dot rr dot com>
- Cc: gcc-patches at gcc dot gnu dot org, gdb-patches at sources dot redhat dot com,binutils at sources dot redhat dot com, dj at redhat dot com
- Date: Mon, 2 Dec 2002 11:18:22 -0500
- Subject: Re: (toplevel) introduce host subdir configuration in Makefile
- References: <20021128221312.GA20889@doctormoo>
On Thu, Nov 28, 2002 at 05:13:12PM -0500, Nathanael Nerode wrote:
> This introduces configure targets for host modules, but doesn't use them
> by default. To use them right now, you need to configure --norecursion
> and then hit each one by hand. I'll make them used automatically once I
> fiddle around and get the dependencies right for sure.
>
> At the moment it appears that 'gcc','zlib','fastjar', and 'libiberty' can
> be configured in any order relative to each other (nice and straightforward).
> If anyone knows of specific configure order dependencies, they should tell
> me. I'll be spending a while fiddling with gcc and src trying to identify
> any other real configure order dependencies.
>
> The 'safe' way to do it is to have all-foo for *every* host module foo
> depend on configure-bar for *every* host module bar, and to have
> a huge list of configure-configure dependencies forcing a specific order.
> But that's stupid, and it looks to me like there are actually few if any
> of these dependences. (Apart from all-foo: configure-foo). I did include
> the one which was actually documented.
>
> Note that the configure target was written to replicate existing behavior
> as closely as possible, and is therefore a bit squirrely; I'll deal with
> that later, but at the moment I want to break as little as possible.
You may already know this, but just to be careful I'll mention it
anyway... it is not necessarily safe to configure more than one
subdirectory at a time. One possibly gotcha is the updating of
$cache_file. It isn't done atomically and so if you happen to have two
subdirectories with the same (essentially) configure.in, and they
happen to get started on an SMP system by make -j2 at (essentially) the
same time, you can blow out the cache file.
This isn't entirely hypothetical. A similar thing happened in
libiberty with two invocations of config.status.
Now, on the other hand, we could configure GCC while building
libiberty. It would be nice to have a way to throw each configure step
into its own log file so that they don't interleave on the screen,
someday.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer