(toplevel) introduce host subdir configuration in Makefile

(toplevel) introduce host subdir configuration in Makefile

[Nathanael Nerode]

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.

This is made to apply after my outstanding patches.  I hear that there's 
some support for dropping my patches into src now, letting it diverge from 
gcc mainline.  That would be fine with me. :-)  Either way,
the sooner I can get my outstanding patches in the happier I am.

Tested on i686-pc-linux-gnu.  Without --norecursion, behaves as before.
With --norecursion, seems to work as expected, but I'm working on checking
dependencies.  (Although if this goes in, others can help me.)

	* Makefile.tpl: Introduce host module configuration targets.
	* configure.in: Introduce support for them.

--- configure.in.current	2002-11-28 15:08:58.000000000 -0500
+++ configure.in	2002-11-28 16:50:51.000000000 -0500
@@ -1446,6 +1446,18 @@
 # desired.
 buildargs="--cache-file=../config.cache --build=${build_alias} --host=${build_alias} ${baseargs}"
 
+# For host modules, accept cache file option, or specification as blank.
+case "${cache_file}" in
+"") # empty
+  cache_file_option="" ;;
+/* | [A-Za-z]:[\\/]* ) # absolute path
+  cache_file_option="--cache-file=${cache_file}" ;;
+*) # relative path
+  cache_file_option="--cache-file=../${cache_file}" ;;
+esac
+
+hostargs="${cache_file_option} ${buildopt} --host=${host_alias} --target=${target_alias} ${extra_host_args} ${baseargs}"
+
 targargs=${baseargs}
 
 # Passing a --with-cross-host argument lets the target libraries know
@@ -1670,6 +1682,7 @@
 s%@build_subdir@%${build_subdir}%
 s%@build_configargs@%${buildargs}%
 s%@gxx_include_dir@%${gxx_include_dir}%
+s%@host_configargs@%${hostargs}%
 EOF
 sed -f $sedtemp Makefile > Makefile.tem
 rm -f Makefile $sedtemp
--- Makefile.tpl.current	2002-11-28 16:42:32.000000000 -0500
+++ Makefile.tpl	2002-11-28 17:02:07.000000000 -0500
@@ -223,13 +223,17 @@
 BUILD_SUBDIR = @build_subdir@
 
 # This is set by the configure script to the arguments to use when configuring
-# directories built for the target.
-TARGET_CONFIGARGS = @target_configargs@
-
-# This is set by the configure script to the arguments to use when configuring
 # directories built for the build system.
 BUILD_CONFIGARGS = @build_configargs@
 
+# This is set by the configure script to the arguments to use when configuring
+# directories built for the host system.
+HOST_CONFIGARGS = @host_configargs@
+
+# This is set by the configure script to the arguments to use when configuring
+# directories built for the target.
+TARGET_CONFIGARGS = @target_configargs@
+
 # This is set by configure to REALLY_SET_LIB_PATH if --enable-shared
 # was used.
 SET_LIB_PATH = @SET_LIB_PATH@
@@ -862,6 +866,46 @@
 	      +] $(X11_FLAGS_TO_PASS)[+ 
 	    ENDIF with_x +] all)
 
+.PHONY: configure-[+module+] maybe-configure-[+module+]
+maybe-configure-[+module+]:
+configure-[+module+]: [+module+]/Makefile
+[+module+]/Makefile: config.status
+	@[ -d [+module+] ] || mkdir [+module+]; \
+	r=`${PWD}`; export r; \
+	s=`cd $(srcdir); ${PWD}`; export s; \
+	CC="$(CC)"; export CC; \
+	CFLAGS="$(CFLAGS)"; export CFLAGS; \
+	CXX="$(CXX)"; export CXX; \
+	CXXFLAGS="$(CXXFLAGS)"; export CXXFLAGS; \
+	if [ z$(build_canonical) !=  z$(host_canoncial) ] ; then \
+	  AR="$(AR)"; export AR; \
+	  AS="$(AS)"; export AS; \
+	  CC_FOR_BUILD="$(CC_FOR_BUILD)"; export CC_FOR_BUILD; \
+	  DLLTOOL="$(DLLTOOL)"; export DLLTOOL; \
+	  LD="$(LD)"; export LD; \
+	  NM="$(NM)"; export NM; \
+	  RANLIB="$(RANLIB)"; export RANLIB; \
+	  WINDRES="$(WINDRES)"; export WINDRES; \
+	  OBJCOPY="$(OBJCOPY)"; export OBJCOPY; \
+	  OBJDUMP="$(OBJDUMP)"; export OBJDUMP; \
+	fi; \
+	echo Configuring in [+module+]; \
+	cd [+module+] || exit 1; \
+	case $(srcdir) in \
+	\.) \
+	  srcdiroption="--srcdir=."; \
+	  libsrcdir=".";; \
+	/* | [A-Za-z]:[\\/]*) \
+	  srcdiroption="--srcdir=$(srcdir)/[+module+]"; \
+	  libsrcdir="$$s/[+module+]";; \
+	*) \
+	  srcdiroption="--srcdir=../$(srcdir)/[+module+]"; \
+	  libsrcdir="$$s/[+module+]";; \
+	esac; \
+	$(SHELL) $${libsrcdir}/configure \
+	  $(HOST_CONFIGARGS) $${srcdiroption} \
+	  || exit 1
+
 [+ IF no_check +]
 .PHONY: check-[+module+]
 check-[+module+]:
@@ -1042,6 +1086,46 @@
 	  true; \
 	fi
 
+.PHONY: configure-gcc maybe-configure-gcc
+maybe-configure-gcc:
+configure-gcc: gcc/Makefile
+gcc/Makefile: config.status
+	@[ -d gcc ] || mkdir gcc;\
+	r=`${PWD}`; export r; \
+	s=`cd $(srcdir); ${PWD}`; export s; \
+	CC="$(CC)"; export CC; \
+	CFLAGS="$(CFLAGS)"; export CFLAGS; \
+	CXX="$(CXX)"; export CXX; \
+	CXXFLAGS="$(CXXFLAGS)"; export CXXFLAGS; \
+	if [ z$(build_canonical) != z$(host_canoncial) ] ; then \
+	  AR="$(AR)"; export AR; \
+	  AS="$(AS)"; export AS; \
+	  CC_FOR_BUILD="$(CC_FOR_BUILD)"; export CC_FOR_BUILD; \
+	  DLLTOOL="$(DLLTOOL)"; export DLLTOOL; \
+	  LD="$(LD)"; export LD; \
+	  NM="$(NM)"; export NM; \
+	  RANLIB="$(RANLIB)"; export RANLIB; \
+	  WINDRES="$(WINDRES)"; export WINDRES; \
+	  OBJCOPY="$(OBJCOPY)"; export OBJCOPY; \
+	  OBJDUMP="$(OBJDUMP)"; export OBJDUMP; \
+	fi; \
+	echo Configuring in gcc; \
+	cd gcc || exit 1; \
+	case $(srcdir) in \
+	\.) \
+	  srcdiroption="--srcdir=."; \
+	  libsrcdir=".";; \
+	/* | [A-Za-z]:[\\/]*) \
+	  srcdiroption="--srcdir=$(srcdir)/gcc"; \
+	  libsrcdir="$$s/gcc";; \
+	*) \
+	  srcdiroption="--srcdir=../$(srcdir)/gcc"; \
+	  libsrcdir="$$s/gcc";; \
+	esac; \
+	$(SHELL) $${libsrcdir}/configure \
+	  $(HOST_CONFIGARGS) $${srcdiroption} \
+	  || exit 1
+
 # Building GCC uses some tools for rebuilding "source" files
 # like texinfo, bison/byacc, etc.  So we must depend on those.
 #

Re: (toplevel) introduce host subdir configuration in Makefile

[Andrew Cagney]

> 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.

Nathanael,

Some heads up.

GDB requires an ISO C compiler and on some systems that involves running 
the compiler with specific flags (-Ae, I think, on HP/UX?).  The problem 
is that GDB can't test/configure this directly.  By time time it has a 
say in the matter, it is too late.  The top level will need to do this 
very early on.

While GDB has a depencency on the SIM directory, it resolves it by 
testing for ${srcdir)/../sim so that should be ok.

While INSIGHT has a dependency on tcl/tk, it appears to resolve it doing 
some pretty agressive hunting.  It looks in both ${srcdir} and `pwd`.

Andrew

Re: (toplevel) introduce host subdir configuration in Makefile

[Daniel Jacobowitz]

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

Re: (toplevel) introduce host subdir configuration in Makefile

[Alexandre Oliva]

On Dec  2, 2002, Daniel Jacobowitz <drow@mvista.com> wrote:

> 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.

This was a bug in autoconf 2.13, that's fixed in autoconf 2.5x.

As for config.cache, the update isn't atomic but, in general, you'll
probably just lose part of the cache.  Unfortunately, this is not
guaranteed by the latest version of autoconf, but it shouldn't be too
hard to fix in the common case by replacing `cat confcache
>$cache_file´ with say `cat confcache >$cache_file.$$ && mv
$cache_file.$$ $cache_file || cat confcache >$cache_file´ in
_AC_CACHE_DUMP.  Unless we want to preserve the semantics that
$cache_file retains the same inode, so that, if there are hard-links
to it, they're also updated, which might be a reasonable thing to do
in case a global cache-file is maintained.

Without atomic updates, it's not safe to run multiple configures in
parallel, indeed.  But I believe you'll most often just lose some
updates to the cache.  You can't really help that, anyway, unless you
serialized configure runs or acquire a lock on it and read it back in
just in case it was updated before writing it out and releasing the
lock; I don't think we want to do that.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: (toplevel) introduce host subdir configuration in Makefile

[Daniel Jacobowitz]

On Mon, Dec 02, 2002 at 02:39:49PM -0200, Alexandre Oliva wrote:
> On Dec  2, 2002, Daniel Jacobowitz <drow@mvista.com> wrote:
> 
> > 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.
> 
> This was a bug in autoconf 2.13, that's fixed in autoconf 2.5x.

What was?  The way files are generated from config.status?

> As for config.cache, the update isn't atomic but, in general, you'll
> probably just lose part of the cache.  Unfortunately, this is not
> guaranteed by the latest version of autoconf, but it shouldn't be too
> hard to fix in the common case by replacing `cat confcache
> >$cache_file´ with say `cat confcache >$cache_file.$$ && mv
> $cache_file.$$ $cache_file || cat confcache >$cache_file´ in
> _AC_CACHE_DUMP.  Unless we want to preserve the semantics that
> $cache_file retains the same inode, so that, if there are hard-links
> to it, they're also updated, which might be a reasonable thing to do
> in case a global cache-file is maintained.
> 
> Without atomic updates, it's not safe to run multiple configures in
> parallel, indeed.  But I believe you'll most often just lose some
> updates to the cache.  You can't really help that, anyway, unless you
> serialized configure runs or acquire a lock on it and read it back in
> just in case it was updated before writing it out and releasing the
> lock; I don't think we want to do that.

Without atomic updates you will definitely lose some updates to the
cache; since the cache is read once and written once.

I'm more worried about two configures writing to the cache at the same
time.  Start both cat processes and you could end up with the two cache
files interleaved at 1K blocks (or so, depending on FS/OS).  That makes
me really uncomfortable...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: (toplevel) introduce host subdir configuration in Makefile

[Alexandre Oliva]

On Dec  2, 2002, Daniel Jacobowitz <drow@mvista.com> wrote:

>> This was a bug in autoconf 2.13, that's fixed in autoconf 2.5x.

> What was?  The way files are generated from config.status?

Yup.  Each run of config.status uses a different temporary file name.

> Without atomic updates you will definitely lose some updates to the
> cache; since the cache is read once and written once.

Even with atomic updates, you lose some of them, unless the cache is
reread just before it's written back.  Currently, configure reads it
when it starts, and rewrites it when it finishes.  If you start
multiple configures using the same cache in parallel, the last one to
write its cache out wins, as long as you're not sufficiently unlucky
to have both of them doing it at the same time, in which case you may
end up with a corrupted cache file.

> I'm more worried about two configures writing to the cache at the same
> time.  Start both cat processes and you could end up with the two cache
> files interleaved at 1K blocks (or so, depending on FS/OS).  That makes
> me really uncomfortable...

Yup, this can be a problem.

The only safe solutions for this at the moment are to use separate
cache files per subdirectory (which defeats most of the purpose of the
cache) or prevent concurrent configure runs (which defeats the point
of making configure parallelizable)

FWIW, we've had target configures running in parallel for a long time,
and I don't know of any corruption caused by this.  Granted, there
aren't as many target libraries to be configured as there are host
packages, but still...

One way to try to overcome this limitation in autoconf that has just
occurred to me is to offload the updating of a shared config.cache to
the top-level Makefile.  E.g., the Makefile safely copies the
top-level config.cache to a subdirectory before it configures it, and
safely copies it back (or merges it) with the top-level config.cache
when configure finishes.  Safety can be accomplished with

cp ${cache_file} subdir/config.cache
run configure in subdir, with --config-cache=./config.cache
mv subdir/config.cache ${cache_file}

trying to merge the contents can get trickier, but I believe it can be
done too.

The one thing we'd have to be careful about is in case the user
specified a config.cache to the top-level, especially /dev/null.  We
may have to handle that especially, like autoconf does.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: (toplevel) introduce host subdir configuration in Makefile

[Daniel Jacobowitz]

On Mon, Dec 02, 2002 at 03:44:21PM -0200, Alexandre Oliva wrote:
> One way to try to overcome this limitation in autoconf that has just
> occurred to me is to offload the updating of a shared config.cache to
> the top-level Makefile.  E.g., the Makefile safely copies the
> top-level config.cache to a subdirectory before it configures it, and
> safely copies it back (or merges it) with the top-level config.cache
> when configure finishes.  Safety can be accomplished with
> 
> cp ${cache_file} subdir/config.cache
> run configure in subdir, with --config-cache=./config.cache
> mv subdir/config.cache ${cache_file}
> 
> trying to merge the contents can get trickier, but I believe it can be
> done too.
> 
> The one thing we'd have to be careful about is in case the user
> specified a config.cache to the top-level, especially /dev/null.  We
> may have to handle that especially, like autoconf does.

Yeah, I think this would be the way to go; but in any case, I suggest
that we serialize configure targets if it's practical to do so.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: (toplevel) introduce host subdir configuration in Makefile

[Alexandre Oliva]

On Dec  2, 2002, Daniel Jacobowitz <drow@mvista.com> wrote:

> Yeah, I think this would be the way to go; but in any case, I suggest
> that we serialize configure targets if it's practical to do so.

Hmm...  I thought the whole point of having explicit configure targets
was to be able to run them in parallel.  Of course we'll still be able
to configure a sub-package while another builds, but that's not quite
as good.

We should definitely have a configure (or host-configure) target that
gets all packages to configure sequentially, such that those who want
to do parallel builds can still do them without having to do parallel
configures (i.e., run `make host-configure && make -j4 all/bootstrap´)

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: (toplevel) introduce host subdir configuration in Makefile

[DJ Delorie]

> Hmm...  I thought the whole point of having explicit configure
> targets was to be able to run them in parallel.

If we can arrange that, that would be better.  For now I think just
serializing the configures (allowing builds in parallel) will be a
sufficient gain.

> Of course we'll still be able to configure a sub-package while
> another builds, but that's not quite as good.

It will also allow re-configuring to pick up one or two new
subdirectories (or manually de-configured) without reconfiguring
everything.

Re: (toplevel) introduce host subdir configuration in Makefile

[Thomas Dickey]

On Mon, Dec 02, 2002 at 02:39:49PM -0200, Alexandre Oliva wrote:
> On Dec  2, 2002, Daniel Jacobowitz <drow@mvista.com> wrote:
> 
> > 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.
> 
> This was a bug in autoconf 2.13, that's fixed in autoconf 2.5x.

arguable (as usual).  2.13 didn't pretend to support parallel make.
2.5x pretends to, but (as you note) config.cache isn't handled.
So it appears more as a bug in 2.5x

-- 
Thomas E. Dickey <dickey@invisible-island.net>
http://invisible-island.net
ftp://invisible-island.net

Re: (toplevel) introduce host subdir configuration in Makefile

[Samuel Tardieu]

>>>>> "Thomas" == Thomas Dickey <dickey@herndon4.his.com> writes:

Thomas> arguable (as usual).  2.13 didn't pretend to support parallel
Thomas> make.  2.5x pretends to, but (as you note) config.cache isn't
Thomas> handled.  So it appears more as a bug in 2.5x

It looks like you have misunderstood what parallel configuration
process meant: only config.status is supposed to be run in parallel in
the same directory, and config.status has never ever used
config.cache.

  Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam

Re: (toplevel) introduce host subdir configuration in Makefile

[Thomas E. Dickey]

On Wed, 4 Dec 2002, Samuel Tardieu wrote:

> >>>>> "Thomas" == Thomas Dickey <dickey@herndon4.his.com> writes:
>
> Thomas> arguable (as usual).  2.13 didn't pretend to support parallel
> Thomas> make.  2.5x pretends to, but (as you note) config.cache isn't
> Thomas> handled.  So it appears more as a bug in 2.5x
>
> It looks like you have misunderstood what parallel configuration
> process meant: only config.status is supposed to be run in parallel in
> the same directory, and config.status has never ever used
> config.cache.

no - I understood the problem.
you're free to make up definitions for your words, and I'm free to ignore
you.

-- 
T.E.Dickey <dickey@herndon4.his.com>
http://invisible-island.net
ftp://invisible-island.net

Re: (toplevel) introduce host subdir configuration in Makefile

[DJ Delorie]

> 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.

We could have each configured configure target depend on the previous
one in the list.  That should serialize them.  We can do this now
because configure has a specific list of which subdirs *will* be
configured, rather than the list of *potential* ones we used to have.

Assuming autogen can do that, of course ;-)

Re: (toplevel) introduce host subdir configuration in Makefile

[Nathanael Nerode]

>>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.
> Nathanael,
>
> Some heads up.
>
> GDB requires an ISO C compiler and on some systems that involves 
>running the compiler with specific flags (-Ae, I think, on HP/UX?). The 
>problem is that GDB can't test/configure this directly. By time time it 
>has a say in the matter, it is too late. The top level will need to do 
>this very early on.
This *shouldn't*, hopefully, be affected, because this doesn't require
that any other *subdirectories* be built.  The top level still 
determines the value of CC, CFLAGS, and so on and so forth, and passes 
them down to subconfigures and submakes.

> While GDB has a depencency on the SIM directory, it resolves it by 
>testing for ${srcdir)/../sim so that should be ok.
Whee.  I put a dependency in for that anyway because of the comment (in
my follow-up patch).

> While INSIGHT has a dependency on tcl/tk, it appears to resolve it 
>doing some pretty agressive hunting. It looks in both ${srcdir} and 
>`pwd`.
Extensive testing indicated that several subdirs with tcl/tk 
dependencies *did* require that in-source tcl/tk be configured; 
otherwise they used installed tcl/tk (or just failed). I dealt with this
in a subsequent patch (but I'm going to commit these patches as a whole,
probably, once I eventually get to them, since the follow-ups are 
effectively tweaks to the original).

> Andrew
Thanks for all the help.  This particular bit is likely to be the most 
destabilizing of my changes; most of the stuff prior to it was carefully
designed to be "behavior-change-free".

--Nathanael

Re: (toplevel) introduce host subdir configuration in Makefile

[Andrew Cagney]

> [...] This particular bit is likely to be the most 
> destabilizing of my changes; most of the stuff prior to it was carefully
> designed to be "behavior-change-free".

Yes, that's why I'd like to see it sooner rather than later.  Plenty of 
time before 5.4/6.0 branches to fix problems.

Andrew

Re: (toplevel) introduce host subdir configuration in Makefile

[Nathanael Nerode]

>>[...] This particular bit is likely to be the most destabilizing of my 
>>changes; most of the stuff prior to it was carefully
>> designed to be "behavior-change-free".
> Yes, that's why I'd like to see it sooner rather than later. Plenty of 
>time before 5.4/6.0 branches to fix problems.
>
> Andrew
And when is that branch anticipated to happen?  (So I can plan...)

--Nathanael

Re: (toplevel) introduce host subdir configuration in Makefile

[Andrew Cagney]

>>>[...] This particular bit is likely to be the most destabilizing of my 
>>>changes; most of the stuff prior to it was carefully
>>> designed to be "behavior-change-free".
> 
>> Yes, that's why I'd like to see it sooner rather than later. Plenty of 
>>time before 5.4/6.0 branches to fix problems.
>>
>> Andrew
> 
> And when is that branch anticipated to happen?  (So I can plan...)

Honestly, who knows.  Febuary, march, april?

A GDB branch isn't that much of a deal.

Andrew