sim: using automake

sim: using automake

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 744 bytes --]

On Thursday, July 07, 2011 23:44:27 Hans-Peter Nilsson wrote:
> Obviously and see the context where non-multi-objs depend on it.
> Found the usual hard way: do a necessary edit in sim-main.h and
> observe fallout when the igen-generated semantics files aren't
> recompiled.  I know there probably *should* also be an explicit
> dependency from the .o to the .c too as in the non-multi-objs
> but at least this is an improvement.

ive been bit by this multiple times, and it always seemed crazy to me that we 
still do manual dependency management.  many of the other sourceware projects 
have converted to automake and dropped the hardcoded lists, so is there 
anything holding back the sim dir other than someone doing it ?
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: sim: using automake

[Tom Tromey]

>>>>> "Mike" == Mike Frysinger <vapier@gentoo.org> writes:

Mike> ive been bit by this multiple times, and it always seemed crazy to
Mike> me that we still do manual dependency management.  many of the
Mike> other sourceware projects have converted to automake and dropped
Mike> the hardcoded lists, so is there anything holding back the sim dir
Mike> other than someone doing it ?

It seems like an improvement to me.

Tom

Re: sim: using automake

[Doug Evans]

On Mon, Jul 11, 2011 at 7:57 AM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Mike" == Mike Frysinger <vapier@gentoo.org> writes:
>
> Mike> ive been bit by this multiple times, and it always seemed crazy to
> Mike> me that we still do manual dependency management.  many of the
> Mike> other sourceware projects have converted to automake and dropped
> Mike> the hardcoded lists, so is there anything holding back the sim dir
> Mike> other than someone doing it ?
>
> It seems like an improvement to me.

"Well ..."
I'd rather not make this transition without a bit more discussion.
[I would prefer to avoid automake.]

One question and one observation:

Question: can automake handle dependencies on machine generated files?
I think(!) the answer is "no", so automake doesn't solve all problems.

Observation: gdb no longer manually describes dependencies (*1) yet it
doesn't use automake.

---
(*1): I realize it's more complicated than that, e.g. source files from subdirs.

Re: sim: using automake

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1623 bytes --]

On Monday, July 11, 2011 12:38:13 Doug Evans wrote:
> On Mon, Jul 11, 2011 at 7:57 AM, Tom Tromey <tromey@redhat.com> wrote:
> >>>>>> "Mike" == Mike Frysinger <vapier@gentoo.org> writes:
> > Mike> ive been bit by this multiple times, and it always seemed crazy to
> > Mike> me that we still do manual dependency management.  many of the
> > Mike> other sourceware projects have converted to automake and dropped
> > Mike> the hardcoded lists, so is there anything holding back the sim dir
> > Mike> other than someone doing it ?
> > 
> > It seems like an improvement to me.
> 
> "Well ..."
> I'd rather not make this transition without a bit more discussion.
> [I would prefer to avoid automake.]

much of the sourceware tree has converted.  seems the only major dirs not 
using it are newlib/libgloss/gdb/sim.
$ ls `find -name Makefile.in | sed 's:[.]in:.am:g'`

not saying this means "gdb/sim must convert", just providing more context to 
show that it's inevitable ! :)

> One question and one observation:
> 
> Question: can automake handle dependencies on machine generated files?
> I think(!) the answer is "no", so automake doesn't solve all problems.

i'm not sure what you mean by machine generated files.  could you provide 
specific examples ?

> Observation: gdb no longer manually describes dependencies (*1) yet it
> doesn't use automake.
> 
> ---
> (*1): I realize it's more complicated than that, e.g. source files from
> subdirs.

just having dependency info in the current dir would be a vast improvement.  
i'll poke the gdb system to see how it's doing it.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: sim: using automake

[Tom Tromey]

>>>>> "Doug" == Doug Evans <dje@google.com> writes:

Doug> [I would prefer to avoid automake.]

Can you say why?

Doug> Question: can automake handle dependencies on machine generated files?
Doug> I think(!) the answer is "no", so automake doesn't solve all problems.

Yes.

Doug> Observation: gdb no longer manually describes dependencies (*1) yet it
Doug> doesn't use automake.

Yes, I did this by porting the code from automake, since that seemed
simpler than moving gdb to use automake.  Using automake would actually
offer other benefits, I just didn't want do deal with the details of the
transition.

Tom

Re: sim: using automake

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 602 bytes --]

On Monday, July 11, 2011 13:24:40 Tom Tromey wrote:
> >>>>> "Doug" == Doug Evans <dje@google.com> writes:
> Doug> Observation: gdb no longer manually describes dependencies (*1) yet
> Doug> it doesn't use automake.
> 
> Yes, I did this by porting the code from automake, since that seemed
> simpler than moving gdb to use automake.  Using automake would actually
> offer other benefits, I just didn't want do deal with the details of the
> transition.

to be clear, i dont want to handle gdb either.  just the sim dir because 
that's a lot simpler and ive been poking it already :).
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: sim: using automake

[Doug Evans]

On Mon, Jul 11, 2011 at 10:24 AM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Doug" == Doug Evans <dje@google.com> writes:
>
> Doug> [I would prefer to avoid automake.]
>
> Can you say why?

It's an extra layer of complication that I've always had to fight with
(as opposed to working with).

There are lots of problems that can be solved by an extra layer of
abstraction (heck, Transmeta lived (and died, heh) by that).
But I haven't been convinced that this is one of them.