Re: [patch/rfc] Build inf-ptrace.o when ptrace available

[Daniel Jacobowitz <drow@false.org>]

On Mon, Oct 11, 2004 at 01:23:56PM -0400, Andrew Cagney wrote:
> >I still do not believe that configure testing should be used for this
> >purpose.  If we end up moving the knowledge of natfiles into configure,
> >then we can set inf-ptrace to be included for all native GNU/Linux
> >targets easily enough.
> 
> So you're not objecting to changes making configure (actually 
> configure.host and configure.tgt) directly handle what was previously in 
> the .mh file ...

I thought I was being quite clear.  You've presented two suggestions:
  - use autoconf to build inf-ptrace
  - goal: move natfiles into lists in the configure scripts

I've said that I object to them both.  I object strongly to the first,
and stylisticly to the second.

> >Or there are other ways to do it, as below. 
> >
> >One of the reasons why I hold this position is that it lets us give a
> >more useful error message if someone's system is broken and can not
> >compile inf-ptrace.c for some reason that the configure script
> >detected.  They'll get either a link failure or a GDB which can't debug
> >anything, instead of an error related to the compile problem.  My
> >experience with automating distribution builds tells me that someone
> >will come up with a way to break their system in this fashion.
> 
> ..  but rather just objecting to having inf-ptrace selected dependant on 
> autoconf magic?  I could equally hardwire it vis:
> 
> case $host in
>   *-linux* | *-bsd* ) objs += inf-ptrace
> esac
> 
> Can you show us the money here - on what systems did you encounter 
> problems and what problems were they?
> 
> The most recent problem I can think of was with the TUI, and that was a 
> straight configure.in bug.

I wrote that my experience with automated builds suggested that a
problem _would_ occur.  I don't have an example of this problem
occuring, but I don't think we need one to understand why it is an
unsound design principle.  The change would cause inf-ptrace to be
built on more systems/configurations (where GDB wouldn't know how to
use it), and could potentially cause it to be built on fewer systems
(where GDB wouldn't work without it).  No win.

> >>>>>>>>>Why is it orthogonal?  If we assume that configure determines when 
> >>>>>>/proc >>>and ptrace() and provides both to the user it certainly 
> >>>>>>isn't.  Idea's >>>such as Mark's and mine would make it easier.
> >>>
> >>>>>
> >>>>>
> >>>>>Why is it related?  How would this make it easier?  It's not hard to
> >>>>>add a new backend file to all the Linux targets; it's really not much
> >>>>>different in a lot of little files than in one big one.  I've done this
> >>>>>plenty of times.
> >>
> >>>
> >>>If we used configure.tgt and:
> >>>	switch "$target"
> >>>	 *-*-linux* ) "objs=objs symfile-mem.c"
> >>>	esac
> >>>then all GNU/Linux systems will always and consistently include 
> >>>symtab-mem.c.  We don't, they don't ...
> >
> >
> >This is no harder than having a common linux.mh, as GCC has done for
> >years (gcc/config/t-linux).  It's not a technical differece between
> >configure-frobbing and makefile-fragmenting.
> 
> So initially we can migrate things to configure.host, and then, if 
> things prove to unwieldly, look at refactoring it.  But not before.

So move everything out of makefile fragments before considering
refactoring the makefile fragments?  That doesn't make any sense.

I will continue to object when you present this as a change with valid
technical/maintenance advantages.  If other maintainers agree that it
has better style, I won't object to making the change, I've already
said that.  But I don't want to make a gratuituous change in style for
bogus technical reasons.  Something which can obviously be done in the
current system is not a valid technical reason to discard the current
system.

-- 
Daniel Jacobowitz