Dependence on config.status

Dependence on config.status

[Eli Zaretskii]

defs_h in gdb/Makefile includes config.status.  This makes all of the
GDB sources depend on it.  The result is that each time I reconfigure
the package, everything gets recompiled, which is quite annoying when
working on some minor configury buglets.

Why does GDB need to be dependent on config.status, in addition to
config.h? 

Re: Dependence on config.status

[Andrew Cagney]

Eli Zaretskii wrote:
> 
> defs_h in gdb/Makefile includes config.status.  This makes all of the
> GDB sources depend on it.  The result is that each time I reconfigure
> the package, everything gets recompiled, which is quite annoying when
> working on some minor configury buglets.

I guess you're refering to things like Makefile problems.

> Why does GDB need to be dependent on config.status, in addition to
> config.h?

I don't know and yes I agree with you.  I think it is just history.

Grubbing through really old versions of gdb I've found that defs_h was
added on:
	date: 1993/06/23 22:59:13;  author: rich
and it included config.status from day one.  The addition of config.h is
far more recent:
	date: 1996/03/17 00:35:57;  author: fnf

Assuming no one objects, I'll delete it in the morning.

	Andrew

Re: Dependence on config.status

[Eli Zaretskii]

> Eli Zaretskii wrote:
> > 
> > defs_h in gdb/Makefile includes config.status.  This makes all of the
> > GDB sources depend on it.  The result is that each time I reconfigure
> > the package, everything gets recompiled, which is quite annoying when
> > working on some minor configury buglets.
> 
> I guess you're refering to things like Makefile problems.

Yes.

> Assuming no one objects, I'll delete it in the morning.

Thanks.

Re: Dependence on config.status

[Jim Kingdon]

> > Why does GDB need to be dependent on config.status, in addition to
> > config.h?
> 
> I don't know and yes I agree with you.  I think it is just history.

Well, if memory serves, if you re-ran configure in such a way that
tm.h started linking to a different file, then the config.status
dependency was the only way to force a rebuild.  I think that is still
true (at least, I glanced through the Makefile.in and configure.in and
that's what it looked like).

Having said that, there is sometimes a tradeoff between having
dependencies correct and having them useful.  Making people type "make
clean" in certain obscure situations may not be all that bad (although
it tends to be pretty confusing as you usually don't realize what is
going on until GDB is acting in strange and inexplicable ways).

Re: Dependence on config.status

[Eli Zaretskii]

> Well, if memory serves, if you re-ran configure in such a way that
> tm.h started linking to a different file, then the config.status
> dependency was the only way to force a rebuild.

How about adding some #define to config.h that would also change when
this happens?

Re: Dependence on config.status

[Eli Zaretskii]

The following changes remove the dependency of GDB on config.status.

If people would still like to have automatic recompile when [ntx]m.h
are linked to different files, I think the correct way is to make
configure define [NTX]M_FILE symbols on config.h by using the values
of ${nativefile}, ${targetfile}, and ${hostfile}, which it already
computes.


2000-03-03  Eli Zaretskii  <eliz@is.elta.co.il>

	gdb/Makefile.in (defs_h): Don't depend on config.status.  (This
	is only needed when [ntx]m.h headers are linked to another set
	of files, in which case they should "make clean".)

--- gdb/Makefile.i~0	Tue Feb 22 10:52:06 2000
+++ gdb/Makefile.in	Fri Mar  3 13:52:30 2000
@@ -495,7 +496,7 @@
 gdbcmd_h =	gdbcmd.h $(command_h)
 
 call_cmds_h =	call-cmds.h
-defs_h =	defs.h xm.h tm.h nm.h config.status config.h gdbarch.h ui-file.h
+defs_h =	defs.h xm.h tm.h nm.h config.h gdbarch.h ui-file.h
 
 top_h =		top.h
 inferior_h =	inferior.h $(breakpoint_h)

Re: Dependence on config.status

[Andrew Cagney]

Eli Zaretskii wrote:
> 
> > Well, if memory serves, if you re-ran configure in such a way that
> > tm.h started linking to a different file, then the config.status
> > dependency was the only way to force a rebuild.
> 
> How about adding some #define to config.h that would also change when
> this happens?

Such as the names of the tm, xm and nm files?

	Andrew

Re: Dependence on config.status

[Eli Zaretskii]

> Eli Zaretskii wrote:
> > 
> > > Well, if memory serves, if you re-ran configure in such a way that
> > > tm.h started linking to a different file, then the config.status
> > > dependency was the only way to force a rebuild.
> > 
> > How about adding some #define to config.h that would also change when
> > this happens?
> 
> Such as the names of the tm, xm and nm files?

Yes, that's what I had in mind.  Since the configure scripts already
knows the names of those files, it could put them into config.h.

Re: Dependence on config.status

[Andrew Cagney]

Eli Zaretskii wrote:
> 
> > Eli Zaretskii wrote:
> > >
> > > > Well, if memory serves, if you re-ran configure in such a way that
> > > > tm.h started linking to a different file, then the config.status
> > > > dependency was the only way to force a rebuild.
> > >
> > > How about adding some #define to config.h that would also change when
> > > this happens?
> >
> > Such as the names of the tm, xm and nm files?
> 
> Yes, that's what I had in mind.  Since the configure scripts already
> knows the names of those files, it could put them into config.h.

Well I've long had in mind a ``maint build-info'' command that printed
out things like:

	tm/xm/hm.h
	the --host/target/build tupples
	the compiler
	the path to the source tree
	the build date
	the user/machine

Assuming your suggestion works (JimK doesn't find more technical flaws
(1) :-) A change putting tm/xm/hm into config.h is ok with me :-)

	Andrew

(1) I think changing tm/xm/nm happens sufficiently often for it to be
dangerous to not force a rebuild.

Re: Dependence on config.status

[Eli Zaretskii]

The following changes remove the dependency of GDB on config.status.

If people would still like to have automatic recompile when [ntx]m.h
are linked to different files, I think the correct way is to make
configure define [NTX]M_FILE symbols on config.h by using the values
of ${nativefile}, ${targetfile}, and ${hostfile}, which it already
computes.


2000-03-03  Eli Zaretskii  <eliz@is.elta.co.il>

	gdb/Makefile.in (defs_h): Don't depend on config.status.  (This
	is only needed when [ntx]m.h headers are linked to another set
	of files, in which case they should "make clean".)

--- gdb/Makefile.i~0	Tue Feb 22 10:52:06 2000
+++ gdb/Makefile.in	Fri Mar  3 13:52:30 2000
@@ -495,7 +496,7 @@
 gdbcmd_h =	gdbcmd.h $(command_h)
 
 call_cmds_h =	call-cmds.h
-defs_h =	defs.h xm.h tm.h nm.h config.status config.h gdbarch.h ui-file.h
+defs_h =	defs.h xm.h tm.h nm.h config.h gdbarch.h ui-file.h
 
 top_h =		top.h
 inferior_h =	inferior.h $(breakpoint_h)

Re: Dependence on config.status

[Andrew Cagney]

Eli Zaretskii wrote:
> 
> defs_h in gdb/Makefile includes config.status.  This makes all of the
> GDB sources depend on it.  The result is that each time I reconfigure
> the package, everything gets recompiled, which is quite annoying when
> working on some minor configury buglets.

I guess you're refering to things like Makefile problems.

> Why does GDB need to be dependent on config.status, in addition to
> config.h?

I don't know and yes I agree with you.  I think it is just history.

Grubbing through really old versions of gdb I've found that defs_h was
added on:
	date: 1993/06/23 22:59:13;  author: rich
and it included config.status from day one.  The addition of config.h is
far more recent:
	date: 1996/03/17 00:35:57;  author: fnf

Assuming no one objects, I'll delete it in the morning.

	Andrew

Re: Dependence on config.status

[Andrew Cagney]

Eli Zaretskii wrote:
> 
> > Well, if memory serves, if you re-ran configure in such a way that
> > tm.h started linking to a different file, then the config.status
> > dependency was the only way to force a rebuild.
> 
> How about adding some #define to config.h that would also change when
> this happens?

Such as the names of the tm, xm and nm files?

	Andrew

Re: Dependence on config.status

[Andrew Cagney]

Eli Zaretskii wrote:
> 
> > Eli Zaretskii wrote:
> > >
> > > > Well, if memory serves, if you re-ran configure in such a way that
> > > > tm.h started linking to a different file, then the config.status
> > > > dependency was the only way to force a rebuild.
> > >
> > > How about adding some #define to config.h that would also change when
> > > this happens?
> >
> > Such as the names of the tm, xm and nm files?
> 
> Yes, that's what I had in mind.  Since the configure scripts already
> knows the names of those files, it could put them into config.h.

Well I've long had in mind a ``maint build-info'' command that printed
out things like:

	tm/xm/hm.h
	the --host/target/build tupples
	the compiler
	the path to the source tree
	the build date
	the user/machine

Assuming your suggestion works (JimK doesn't find more technical flaws
(1) :-) A change putting tm/xm/hm into config.h is ok with me :-)

	Andrew

(1) I think changing tm/xm/nm happens sufficiently often for it to be
dangerous to not force a rebuild.

Re: Dependence on config.status

[Eli Zaretskii]

> Eli Zaretskii wrote:
> > 
> > > Well, if memory serves, if you re-ran configure in such a way that
> > > tm.h started linking to a different file, then the config.status
> > > dependency was the only way to force a rebuild.
> > 
> > How about adding some #define to config.h that would also change when
> > this happens?
> 
> Such as the names of the tm, xm and nm files?

Yes, that's what I had in mind.  Since the configure scripts already
knows the names of those files, it could put them into config.h.

Dependence on config.status

[Eli Zaretskii]

defs_h in gdb/Makefile includes config.status.  This makes all of the
GDB sources depend on it.  The result is that each time I reconfigure
the package, everything gets recompiled, which is quite annoying when
working on some minor configury buglets.

Why does GDB need to be dependent on config.status, in addition to
config.h? 

Re: Dependence on config.status

[Eli Zaretskii]

> Eli Zaretskii wrote:
> > 
> > defs_h in gdb/Makefile includes config.status.  This makes all of the
> > GDB sources depend on it.  The result is that each time I reconfigure
> > the package, everything gets recompiled, which is quite annoying when
> > working on some minor configury buglets.
> 
> I guess you're refering to things like Makefile problems.

Yes.

> Assuming no one objects, I'll delete it in the morning.

Thanks.

Re: Dependence on config.status

[Eli Zaretskii]

> Well, if memory serves, if you re-ran configure in such a way that
> tm.h started linking to a different file, then the config.status
> dependency was the only way to force a rebuild.

How about adding some #define to config.h that would also change when
this happens?

Re: Dependence on config.status

[Jim Kingdon]

> > Why does GDB need to be dependent on config.status, in addition to
> > config.h?
> 
> I don't know and yes I agree with you.  I think it is just history.

Well, if memory serves, if you re-ran configure in such a way that
tm.h started linking to a different file, then the config.status
dependency was the only way to force a rebuild.  I think that is still
true (at least, I glanced through the Makefile.in and configure.in and
that's what it looked like).

Having said that, there is sometimes a tradeoff between having
dependencies correct and having them useful.  Making people type "make
clean" in certain obscure situations may not be all that bad (although
it tends to be pretty confusing as you usually don't realize what is
going on until GDB is acting in strange and inexplicable ways).