why cgen/cpu and not cgen in gdb_5_2_1-2002-07-23-release

why cgen/cpu and not cgen in gdb_5_2_1-2002-07-23-release

[Doug Evans]

I just checked out gdb_5_2_1-2002-07-23-release from the cvs tree.

Question: Why are the cgen cpu files there but not cgen?

This is just idle curiosity.

Re: why cgen/cpu and not cgen in gdb_5_2_1-2002-07-23-release

[Andrew Cagney]

> I just checked out gdb_5_2_1-2002-07-23-release from the cvs tree.
> 
> Question: Why are the cgen cpu files there but not cgen?

Same reason GDB doesn't include autoconf, automake, gettext, bison, and 
many other tools used to create generated files.  Not needed.

Andrew

Re: why cgen/cpu and not cgen in gdb_5_2_1-2002-07-23-release

[Doug Evans]

Andrew Cagney writes:
 > > I just checked out gdb_5_2_1-2002-07-23-release from the cvs tree.
 > > 
 > > Question: Why are the cgen cpu files there but not cgen?
 > 
 > Same reason GDB doesn't include autoconf, automake, gettext, bison, and 
 > many other tools used to create generated files.  Not needed.

I recognize this.
But cgen isn't autoconf.  gdb/configure.in isn't shipped with autoconf.

I'm wondering if more changes are required or different rules are at play.
That's all.

Methinks apps shipping the .cpu files in src/cgen/cpu without cgen is fragile.
How fragile I dunno, but it is suspect.  Ergo my question.
[N.B. I'm not suggesting not shipping .cpu files.
Nor am I suggesting shipping the cgen *.scm files.
I'm just questioning the current situation.
As an example, one could move the .cpu files to a different dir.]

If I upgrade to autoconf 2.15, or some such, I don't expect any fundamental
change to gdb.  If I grab a copy of cgen off the net, it'll come with
the .cpu files.  All of a sudden my gdb 5.2 is now supporting the
foo and bar insns of the baz cpu (assuming one configures the tree with
--enable-cgen-maint or some such).
I suppose we could have two different cgen releases,
one with .cpu files (*1), one without.  [Or, for completeness' sake, cgen
could be instructed to use the .cpu files that came with the app, rather
than the ones that came with it, but that's clearly rather fragile.]

(*1): There's also .opc files.  I'm using ".cpu files" as a catch-all.
[One can certainly argue .opc files should live in opcodes, but that's
another discussion.]

Also, maybe now's the time to add version numbers to .cpu files.
That is also another discussion.

Re: why cgen/cpu and not cgen in gdb_5_2_1-2002-07-23-release

[Andrew Cagney]

> Andrew Cagney writes:
>  > > I just checked out gdb_5_2_1-2002-07-23-release from the cvs tree.
>  > > 
>  > > Question: Why are the cgen cpu files there but not cgen?
>  > 
>  > Same reason GDB doesn't include autoconf, automake, gettext, bison, and 
>  > many other tools used to create generated files.  Not needed.
> 
> I recognize this.
> But cgen isn't autoconf.  gdb/configure.in isn't shipped with autoconf.

True, gdb/configure is shipped with gdb/configure.in.  If you want to 
generate a new gdb/configure then just the correct autoconf is needed.

> I'm wondering if more changes are required or different rules are at play.
> That's all.
> 
> Methinks apps shipping the .cpu files in src/cgen/cpu without cgen is fragile.
> How fragile I dunno, but it is suspect.  Ergo my question.
> [N.B. I'm not suggesting not shipping .cpu files.
> Nor am I suggesting shipping the cgen *.scm files.
> I'm just questioning the current situation.
> As an example, one could move the .cpu files to a different dir.]

Moving the files to a different directory seems to make sense.

> If I upgrade to autoconf 2.15, or some such, I don't expect any fundamental
> change to gdb.  If I grab a copy of cgen off the net, it'll come with
> the .cpu files.  All of a sudden my gdb 5.2 is now supporting the
> foo and bar insns of the baz cpu (assuming one configures the tree with
> --enable-cgen-maint or some such).
> I suppose we could have two different cgen releases,
> one with .cpu files (*1), one without.  [Or, for completeness' sake, cgen
> could be instructed to use the .cpu files that came with the app, rather
> than the ones that came with it, but that's clearly rather fragile.]
> 
> (*1): There's also .opc files.  I'm using ".cpu files" as a catch-all.
> [One can certainly argue .opc files should live in opcodes, but that's
> another discussion.]
> 
> Also, maybe now's the time to add version numbers to .cpu files.
> That is also another discussion.

Yes.

Andrew