Обсуждение: struct index
Is there a reason why anyone renamed struct index to struct RelationGetRelidindex in ecpg's type.h? I'm surprised it doesn't break the ecpg compilation procedure since the usage in preproc.y hasn't been changed at all. I just checked and found that is does indeed break ecpg compilation. I just didn't notice because ecpg isn't compiled per default. Any reason why it isn't? Michael -- Michael Meskes meskes@online-club.de, meskes@debian.org Go SF49ers! Go Rhein Fire! Use Debian GNU/Linux!
> Is there a reason why anyone renamed struct index to
> struct RelationGetRelidindex in ecpg's type.h? I'm surprised it doesn't
> break the ecpg compilation procedure since the usage in preproc.y hasn't
> been changed at all.
>
> I just checked and found that is does indeed break ecpg compilation. I just
> didn't notice because ecpg isn't compiled per default. Any reason why it
> isn't?
>
> Michael
Sorry. I am fixing it now. I am not sure how that got changed, but I
clearly did it:
---------------------------------------------------------------------------
*** type.h 1998/05/26 13:43:55 1.10
--- type.h 1998/08/19 01:33:47
***************
*** 75,81 ****
char *str;
};
! struct index
{
int index1;
int index2;
--- 75,81 ----
char *str;
};
! struct RelationGetRelidindex
{
int index1;
int index2;
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
> I just checked and found that is does indeed break ecpg compilation. I
> just didn't notice because ecpg isn't compiled per default. Any reason
> why it isn't?
I suspect it is for historical reasons: either ecpg had trouble
compiling at one time so someone disabled the default build, _or_ some
systems have trouble with your bison or flex input file. I'm vaguely
recalling the latter, and the fix will be for you to include the bison
and flex output in the distribution so it does not need to be rebuilt
unless someone changes the source.
If you do this, it is important to "touch" the output files _before_
committing to CVS, so that the outputs are definitely dated later than
the inputs, otherwise make will decide to rebuild them anyway. I made
this mistake yet again the last time I committed gram.c for the main
parser, and we'll need to fix this before v6.4 is released...
- Tom
On Wed, Aug 19, 1998 at 03:08:50PM +0000, Thomas G. Lockhart wrote: > I suspect it is for historical reasons: either ecpg had trouble > compiling at one time so someone disabled the default build, _or_ some > systems have trouble with your bison or flex input file. I'm vaguely > recalling the latter, and the fix will be for you to include the bison > and flex output in the distribution so it does not need to be rebuilt > unless someone changes the source. No problem with me. Shall I upload these files, or could anyone with direct cvs access put them in there? Michael -- Michael Meskes meskes@online-club.de, meskes@debian.org Go SF49ers! Go Rhein Fire! Use Debian GNU/Linux!
> On Wed, Aug 19, 1998 at 03:08:50PM +0000, Thomas G. Lockhart wrote: > > I suspect it is for historical reasons: either ecpg had trouble > > compiling at one time so someone disabled the default build, _or_ some > > systems have trouble with your bison or flex input file. I'm vaguely > > recalling the latter, and the fix will be for you to include the bison > > and flex output in the distribution so it does not need to be rebuilt > > unless someone changes the source. > > No problem with me. Shall I upload these files, or could anyone with direct > cvs access put them in there? OK. It will compile by default now. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)