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

[Andrew Cagney <cagney@gnu.org>]

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

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

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

Andrew