Thread: pgsql-server/src backend/bootstrap/Tag: backen ...

pgsql-server/src backend/bootstrap/Tag: backen ...

From
momjian@svr1.postgresql.org (Bruce Momjian)
Date:
CVSROOT:    /cvsroot
Module name:    pgsql-server
Changes by:    momjian@svr1.postgresql.org    03/09/07 19:51:55

Added files:
    src/backend/bootstrap: Tag: WIN32_DEV bootparse.c bootscanner.c
                           bootstrap_tokens.h
    src/backend/parser: Tag: WIN32_DEV gram.c parse.h scan.c
    src/interfaces/ecpg/preproc: Tag: WIN32_DEV pgc.c preproc.c
                                 preproc.h
    src/pl/plpgsql/src: Tag: WIN32_DEV pl.tab.h pl_gram.c pl_scan.c

Log message:
    Add bison/lex created files.


Re: pgsql-server/src backend/bootstrap/Tag: backen ...

From
Tom Lane
Date:
momjian@svr1.postgresql.org (Bruce Momjian) writes:
> Added files:
>     src/backend/bootstrap: Tag: WIN32_DEV bootparse.c bootscanner.c
>                            bootstrap_tokens.h
>     src/backend/parser: Tag: WIN32_DEV gram.c parse.h scan.c
>     src/interfaces/ecpg/preproc: Tag: WIN32_DEV pgc.c preproc.c
>                                  preproc.h
>     src/pl/plpgsql/src: Tag: WIN32_DEV pl.tab.h pl_gram.c pl_scan.c

> Log message:
>     Add bison/lex created files.

I thought the consensus of the discussion was that this was not
necessary.  It sure doesn't strike me as a good idea.

            regards, tom lane

Re: pgsql-server/src backend/bootstrap/Tag: backen ...

From
Bruce Momjian
Date:
Tom Lane wrote:
> momjian@svr1.postgresql.org (Bruce Momjian) writes:
> > Added files:
> >     src/backend/bootstrap: Tag: WIN32_DEV bootparse.c bootscanner.c
> >                            bootstrap_tokens.h
> >     src/backend/parser: Tag: WIN32_DEV gram.c parse.h scan.c
> >     src/interfaces/ecpg/preproc: Tag: WIN32_DEV pgc.c preproc.c
> >                                  preproc.h
> >     src/pl/plpgsql/src: Tag: WIN32_DEV pl.tab.h pl_gram.c pl_scan.c
>
> > Log message:
> >     Add bison/lex created files.
>
> I thought the consensus of the discussion was that this was not
> necessary.  It sure doesn't strike me as a good idea.

This is only in the WIN32_DEV, where installing bison/flex is a pain.  I
copy the needed files over manually when I update that CVS from HEAD.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Re: pgsql-server/src backend/bootstrap/Tag: backen ...

From
Tom Lane
Date:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> I thought the consensus of the discussion was that this was not
>> necessary.  It sure doesn't strike me as a good idea.

> This is only in the WIN32_DEV, where installing bison/flex is a pain.  I
> copy the needed files over manually when I update that CVS from HEAD.

That's not a pain?  You don't expect that WIN32_DEV will be broken on a
regular basis because its derived files are out of date?

Mind you, I do not actually give a darn whether WIN32_DEV is broken.
What bothers me about this is that if it's considered a good idea for
WIN32_DEV (whose only users, presumably, are developers clueful enough
to obtain the needed tools for themselves) then whenever Windows support
gets merged back to HEAD, we will be feeling pressure to do the same in
the HEAD branch.  And that is something up with which I will not put.

            regards, tom lane

Re: pgsql-server/src backend/bootstrap/Tag: backen ...

From
Bruce Momjian
Date:
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Tom Lane wrote:
> >> I thought the consensus of the discussion was that this was not
> >> necessary.  It sure doesn't strike me as a good idea.
>
> > This is only in the WIN32_DEV, where installing bison/flex is a pain.  I
> > copy the needed files over manually when I update that CVS from HEAD.
>
> That's not a pain?  You don't expect that WIN32_DEV will be broken on a
> regular basis because its derived files are out of date?
>
> Mind you, I do not actually give a darn whether WIN32_DEV is broken.
> What bothers me about this is that if it's considered a good idea for
> WIN32_DEV (whose only users, presumably, are developers clueful enough
> to obtain the needed tools for themselves) then whenever Windows support
> gets merged back to HEAD, we will be feeling pressure to do the same in
> the HEAD branch.  And that is something up with which I will not put.

It is just easier for them to get start.  Yea, they will need it when it
is merged.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Re: pgsql-server/src backend/bootstrap/Tag: backen ...

From
Bruce Momjian
Date:
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > > Tom Lane wrote:
> > >> I thought the consensus of the discussion was that this was not
> > >> necessary.  It sure doesn't strike me as a good idea.
> >
> > > This is only in the WIN32_DEV, where installing bison/flex is a pain.  I
> > > copy the needed files over manually when I update that CVS from HEAD.
> >
> > That's not a pain?  You don't expect that WIN32_DEV will be broken on a
> > regular basis because its derived files are out of date?
> >
> > Mind you, I do not actually give a darn whether WIN32_DEV is broken.
> > What bothers me about this is that if it's considered a good idea for
> > WIN32_DEV (whose only users, presumably, are developers clueful enough
> > to obtain the needed tools for themselves) then whenever Windows support
> > gets merged back to HEAD, we will be feeling pressure to do the same in
> > the HEAD branch.  And that is something up with which I will not put.
>
> It is just easier for them to get start.  Yea, they will need it when it
> is merged.

Also, keep in mind that in the end most folks will be building under
MinGW using a release tarball, that has those output files.  We haven't
gotten a MinGW release yet, so they have to build all the stuff.

I use my unix bison/flex to build, but other's don't have that
capability.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Re: pgsql-server/src backend/bootstrap/Tag: backen ...

From
Tom Lane
Date:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> Tom Lane wrote:
>>> I thought the consensus of the discussion was that this was not
>>> necessary.  It sure doesn't strike me as a good idea.

> Also, keep in mind that in the end most folks will be building under
> MinGW using a release tarball, that has those output files.  We haven't
> gotten a MinGW release yet, so they have to build all the stuff.

Well, that's a fair argument, but why don't you get Marc to set up
nightly snapshots for the WIN32_DEV branch?  That only costs cycles
in the short term.  Polluting CVS with updates to derived files will
cost us CVS storage forever.

            regards, tom lane

Re: pgsql-server/src backend/bootstrap/Tag: backen ...

From
"Marc G. Fournier"
Date:

On Sun, 7 Sep 2003, Tom Lane wrote:

> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> >> Tom Lane wrote:
> >>> I thought the consensus of the discussion was that this was not
> >>> necessary.  It sure doesn't strike me as a good idea.
>
> > Also, keep in mind that in the end most folks will be building under
> > MinGW using a release tarball, that has those output files.  We haven't
> > gotten a MinGW release yet, so they have to build all the stuff.
>
> Well, that's a fair argument, but why don't you get Marc to set up
> nightly snapshots for the WIN32_DEV branch?  That only costs cycles
> in the short term.  Polluting CVS with updates to derived files will
> cost us CVS storage forever.

Easy enough, and done ...

ftp://ftp.postgresql.org/pub/win32_dev

will have it run nighty like the regular snapshot

Re: pgsql-server/src backend/bootstrap/Tag: backen ...

From
Bruce Momjian
Date:
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> >> Tom Lane wrote:
> >>> I thought the consensus of the discussion was that this was not
> >>> necessary.  It sure doesn't strike me as a good idea.
>
> > Also, keep in mind that in the end most folks will be building under
> > MinGW using a release tarball, that has those output files.  We haven't
> > gotten a MinGW release yet, so they have to build all the stuff.
>
> Well, that's a fair argument, but why don't you get Marc to set up
> nightly snapshots for the WIN32_DEV branch?  That only costs cycles
> in the short term.  Polluting CVS with updates to derived files will
> cost us CVS storage forever.

Hmm, another problem is that I don't think there is a flex port for
MinGW --- at least I remember someone saying they found bison, but not
flex, so if they grab the snapshot, they will not be able to use CVS to
do development and diffs.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Re: pgsql-server/src backend/bootstrap/Tag: backen ...

From
Bruce Momjian
Date:
Marc G. Fournier wrote:
>
>
> On Sun, 7 Sep 2003, Tom Lane wrote:
>
> > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > >> Tom Lane wrote:
> > >>> I thought the consensus of the discussion was that this was not
> > >>> necessary.  It sure doesn't strike me as a good idea.
> >
> > > Also, keep in mind that in the end most folks will be building under
> > > MinGW using a release tarball, that has those output files.  We haven't
> > > gotten a MinGW release yet, so they have to build all the stuff.
> >
> > Well, that's a fair argument, but why don't you get Marc to set up
> > nightly snapshots for the WIN32_DEV branch?  That only costs cycles
> > in the short term.  Polluting CVS with updates to derived files will
> > cost us CVS storage forever.
>
> Easy enough, and done ...
>
> ftp://ftp.postgresql.org/pub/win32_dev
>
> will have it run nighty like the regular snapshot

Oh, that's nice.  I put it on my web site so people don't need CVS
installed.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Re: pgsql-server/src backend/bootstrap/Tag: backen ...

From
Tom Lane
Date:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Hmm, another problem is that I don't think there is a flex port for
> MinGW --- at least I remember someone saying they found bison, but not
> flex, so if they grab the snapshot, they will not be able to use CVS to
> do development and diffs.

So?  Supplying the derived files via CVS rather than via snapshots
won't improve matters at all for people who haven't got the tools.

            regards, tom lane

Re: pgsql-server/src backend/bootstrap/Tag: backen ...

From
Bruce Momjian
Date:
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Hmm, another problem is that I don't think there is a flex port for
> > MinGW --- at least I remember someone saying they found bison, but not
> > flex, so if they grab the snapshot, they will not be able to use CVS to
> > do development and diffs.
>
> So?  Supplying the derived files via CVS rather than via snapshots
> won't improve matters at all for people who haven't got the tools.

Why do you need the tools if CVS has the files?  I added something to
configure so the derived files are newer than the others.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Re: pgsql-server/src backend/bootstrap/Tag: backen ...

From
"Marc G. Fournier"
Date:

On Sun, 7 Sep 2003, Bruce Momjian wrote:

> Tom Lane wrote:
> > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > >> Tom Lane wrote:
> > >>> I thought the consensus of the discussion was that this was not
> > >>> necessary.  It sure doesn't strike me as a good idea.
> >
> > > Also, keep in mind that in the end most folks will be building under
> > > MinGW using a release tarball, that has those output files.  We haven't
> > > gotten a MinGW release yet, so they have to build all the stuff.
> >
> > Well, that's a fair argument, but why don't you get Marc to set up
> > nightly snapshots for the WIN32_DEV branch?  That only costs cycles
> > in the short term.  Polluting CVS with updates to derived files will
> > cost us CVS storage forever.
>
> Hmm, another problem is that I don't think there is a flex port for
> MinGW --- at least I remember someone saying they found bison, but not
> flex, so if they grab the snapshot, they will not be able to use CVS to
> do development and diffs.

Actually, if I recall that same thread, one person mentioned downloading a
MinGW bison port, and then could build flex no problem using that ...

Basically, I agree with Tom ... if we are going to go the extra steps to
support Win32, at least the Win32 ppl can do is take the extra steps to
build using the same 'restrictions' as the Unix ppl go through ...



Re: pgsql-server/src backend/bootstrap/Tag: backen ...

From
Bruce Momjian
Date:
Marc G. Fournier wrote:
> > Hmm, another problem is that I don't think there is a flex port for
> > MinGW --- at least I remember someone saying they found bison, but not
> > flex, so if they grab the snapshot, they will not be able to use CVS to
> > do development and diffs.
>
> Actually, if I recall that same thread, one person mentioned downloading a
> MinGW bison port, and then could build flex no problem using that ...
>
> Basically, I agree with Tom ... if we are going to go the extra steps to
> support Win32, at least the Win32 ppl can do is take the extra steps to
> build using the same 'restrictions' as the Unix ppl go through ...

Well, the files are in there now --- I might as well just leave them so
they don't have to go through that.  This MinGW environment is much more
limited than a Unix environment --- no bison, flex, cvs, or perl.

Once people are invested in the port, I think they will install those
tools, but I like to make the getting-started easier.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Re: pgsql-server/src backend/bootstrap/Tag: backen ...

From
Bruce Momjian
Date:
Marc G. Fournier wrote:
> > Hmm, another problem is that I don't think there is a flex port for
> > MinGW --- at least I remember someone saying they found bison, but not
> > flex, so if they grab the snapshot, they will not be able to use CVS to
> > do development and diffs.
>
> Actually, if I recall that same thread, one person mentioned downloading a
> MinGW bison port, and then could build flex no problem using that ...
>
> Basically, I agree with Tom ... if we are going to go the extra steps to
> support Win32, at least the Win32 ppl can do is take the extra steps to
> build using the same 'restrictions' as the Unix ppl go through ...

Also, those files will not move into main CVS, and no one in Win32 is
going to be playing with changing any of the source files used by
bison/flex.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Re: pgsql-server/src backend/bootstrap/Tag: backen ...

From
Tom Lane
Date:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> So?  Supplying the derived files via CVS rather than via snapshots
>> won't improve matters at all for people who haven't got the tools.

> Why do you need the tools if CVS has the files?

Why do you need the tools if the nightly snapshots have the files?
Same either way AFAICS.

My objection is basically that CVS is a hugely inefficient mechanism
for delivering derived files.  The cost is about the same from a
downloader's point of view as snapshot tarballs --- but we pay for each
update *forever* in CVS storage.  I do not mind having CVS permanently
record every feature addition or bug fix; that's potentially-useful
history.  But there is zero historical content in derived files.

> I added something to configure so the derived files are newer than the
> others.

Doesn't that break the scenario you were just citing where a WIN32_DEV
user is trying to fix something in a .y or .l file?

            regards, tom lane

Re: pgsql-server/src backend/bootstrap/Tag: backen ...

From
Bruce Momjian
Date:
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Tom Lane wrote:
> >> So?  Supplying the derived files via CVS rather than via snapshots
> >> won't improve matters at all for people who haven't got the tools.
>
> > Why do you need the tools if CVS has the files?
>
> Why do you need the tools if the nightly snapshots have the files?
> Same either way AFAICS.
>
> My objection is basically that CVS is a hugely inefficient mechanism
> for delivering derived files.  The cost is about the same from a
> downloader's point of view as snapshot tarballs --- but we pay for each
> update *forever* in CVS storage.  I do not mind having CVS permanently
> record every feature addition or bug fix; that's potentially-useful
> history.  But there is zero historical content in derived files.

Oh, that's true.  Maybe I should just push the snapshots because those
are easier, and cvs isn't even in MinGW.  I mount a Unix directory for
builds, so I have CVS and all the other tools.

Once nice thing about CVS is that you don't have to download the whole
tarball each time --- good for code in development like MinGW.

Also, one thing I am doing is pushing HEAD changes down in to the branch
so I get the HEAD Win32 fixes that go in, and merging will be easier.
Isn't that going to make overhead too?

> > I added something to configure so the derived files are newer than the
> > others.
>
> Doesn't that break the scenario you were just citing where a WIN32_DEV
> user is trying to fix something in a .y or .l file?

Sure.  I don't anticipate any changes made there.  All the stuff left is
backend startup stuff.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Re: pgsql-server/src backend/bootstrap/Tag: backen ...

From
Sean Chittenden
Date:
> >>> I thought the consensus of the discussion was that this was not
> >>> necessary.  It sure doesn't strike me as a good idea.
>
> > Also, keep in mind that in the end most folks will be building
> > under MinGW using a release tarball, that has those output files.
> > We haven't gotten a MinGW release yet, so they have to build all
> > the stuff.
>
> Well, that's a fair argument, but why don't you get Marc to set up
> nightly snapshots for the WIN32_DEV branch?  That only costs cycles
> in the short term.  Polluting CVS with updates to derived files will
> cost us CVS storage forever.

Um, why not just have someone with local CVSROOT access just rm -f the
,v file when the WIN32_DEV branch ceases to be useful?  In the
meantime, have the flex/bison files in CVS.  Few will notice or care
in the meantime other than possibly CVSup administrators.  Just a
thought.

-sc

--
Sean Chittenden

Re: pgsql-server/src backend/bootstrap/Tag: backen ...

From
Tom Lane
Date:
Sean Chittenden <sean@chittenden.org> writes:
>> Well, that's a fair argument, but why don't you get Marc to set up
>> nightly snapshots for the WIN32_DEV branch?  That only costs cycles
>> in the short term.  Polluting CVS with updates to derived files will
>> cost us CVS storage forever.

> Um, why not just have someone with local CVSROOT access just rm -f the
> ,v file when the WIN32_DEV branch ceases to be useful?

If we do that, we will lose the change histories from back when those
files were kept in CVS (five or more years ago).  Perhaps this is not
important, but I'm hesitant to do it.

            regards, tom lane

Re: pgsql-server/src backend/bootstrap/Tag: backen ...

From
Bruce Momjian
Date:
Tom Lane wrote:
> Sean Chittenden <sean@chittenden.org> writes:
> >> Well, that's a fair argument, but why don't you get Marc to set up
> >> nightly snapshots for the WIN32_DEV branch?  That only costs cycles
> >> in the short term.  Polluting CVS with updates to derived files will
> >> cost us CVS storage forever.
>
> > Um, why not just have someone with local CVSROOT access just rm -f the
> > ,v file when the WIN32_DEV branch ceases to be useful?
>
> If we do that, we will lose the change histories from back when those
> files were kept in CVS (five or more years ago).  Perhaps this is not
> important, but I'm hesitant to do it.

Right.  I assume branches are kept in the same file as HEAD.

I have decided not to regularly update the derived files in WIN32_DEV
--- I will just keep the files in their place, and have configure
'touch' them to make them more recent when configure is run ---  we are
just trying to get the backend to start at this point.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Re: pgsql-server/src backend/bootstrap/Tag: backen ...

From
Sean Chittenden
Date:
> > >> Well, that's a fair argument, but why don't you get Marc to set
> > >> up nightly snapshots for the WIN32_DEV branch?  That only costs
> > >> cycles in the short term.  Polluting CVS with updates to
> > >> derived files will cost us CVS storage forever.
> >
> > > Um, why not just have someone with local CVSROOT access just rm
> > > -f the ,v file when the WIN32_DEV branch ceases to be useful?
> >
> > If we do that, we will lose the change histories from back when
> > those files were kept in CVS (five or more years ago).  Perhaps
> > this is not important, but I'm hesitant to do it.

That's right... those files used to be in CVS...

> Right.  I assume branches are kept in the same file as HEAD.

Correct, CVS abuses the RCS format.

> I have decided not to regularly update the derived files in
> WIN32_DEV --- I will just keep the files in their place, and have
> configure 'touch' them to make them more recent when configure is
> run --- we are just trying to get the backend to start at this
> point.

*shrug* It's just an RCS file and easily editable by those who have
write access.  As I said, just a thought and is something that's
pretty common for FreeBSD's CVS meisters to do and shouldn't be an
option that this project rules out.

--
Sean Chittenden

Re: pgsql-server/src backend/bootstrap/Tag: backen ...

From
Peter Eisentraut
Date:
Bruce Momjian writes:

> Also, those files will not move into main CVS, and no one in Win32 is
> going to be playing with changing any of the source files used by
> bison/flex.

That is just false.  Look at the CVS history of these files.

--
Peter Eisentraut   peter_e@gmx.net


Re: pgsql-server/src backend/bootstrap/Tag: backen ...

From
Peter Eisentraut
Date:
Bruce Momjian writes:

> Well, the files are in there now --- I might as well just leave them so
> they don't have to go through that.  This MinGW environment is much more
> limited than a Unix environment --- no bison, flex, cvs, or perl.

The whole MinGW thing is overhyped.  Install Cygwin and specify gcc
-mno-cygwin when you compile.  That gets you the same compilation
environment that MinGW provides, but you can use all the Unix tools.

> Once people are invested in the port, I think they will install those
> tools, but I like to make the getting-started easier.

Yeah, but if there is supposedly no cvs available in that environment,
what is the point of this exercise?  They're going to have to download a
pre-cooked tarball anyway.

--
Peter Eisentraut   peter_e@gmx.net


Re: pgsql-server/src backend/bootstrap/Tag: backen ...

From
Bruce Momjian
Date:
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > Also, those files will not move into main CVS, and no one in Win32 is
> > going to be playing with changing any of the source files used by
> > bison/flex.
>
> That is just false.  Look at the CVS history of these files.

I meant I wasn't going to _resurect_ those files in CVS HEAD, only in
WIN32_DEV.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Re: pgsql-server/src backend/bootstrap/Tag: backen ...

From
Bruce Momjian
Date:
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > Well, the files are in there now --- I might as well just leave them so
> > they don't have to go through that.  This MinGW environment is much more
> > limited than a Unix environment --- no bison, flex, cvs, or perl.
>
> The whole MinGW thing is overhyped.  Install Cygwin and specify gcc
> -mno-cygwin when you compile.  That gets you the same compilation
> environment that MinGW provides, but you can use all the Unix tools.

But we still need to do the work of getting this to work without
compatiblity libraries.  It is try Cygwin has a nice development
environment too.

> > Once people are invested in the port, I think they will install those
> > tools, but I like to make the getting-started easier.
>
> Yeah, but if there is supposedly no cvs available in that environment,
> what is the point of this exercise?  They're going to have to download a
> pre-cooked tarball anyway.

True.  They could CVS from somewhere else and copy it to Win32, but they
would need flex/bison on Win32 for the compile.  It just seemed two less
things for people to do.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Re: pgsql-server/src backend/bootstrap/Tag: backen ...

From
Rod Taylor
Date:
> > Yeah, but if there is supposedly no cvs available in that environment,
> > what is the point of this exercise?  They're going to have to download a
> > pre-cooked tarball anyway.
>
> True.  They could CVS from somewhere else and copy it to Win32, but they
> would need flex/bison on Win32 for the compile.  It just seemed two less
> things for people to do.

Windows has some of the best CVS clients out of all operating systems
I've tried. Tortoise CVS is consistently one of the simplest and most
useful.

Attachment

Re: pgsql-server/src backend/bootstrap/Tag: backen ...

From
Peter Eisentraut
Date:
Bruce Momjian writes:

> Peter Eisentraut wrote:
> > Bruce Momjian writes:
> >
> > > Also, those files will not move into main CVS, and no one in Win32 is
> > > going to be playing with changing any of the source files used by
> > > bison/flex.
> >
> > That is just false.  Look at the CVS history of these files.
>
> I meant I wasn't going to _resurect_ those files in CVS HEAD, only in
> WIN32_DEV.

That is not the point.  The point is: you claim that no Windows developers
are going to want to change those files.  The fact is: A glance at the CVS
history shows that these files have already been changed several times
because of Windows-related work.

--
Peter Eisentraut   peter_e@gmx.net


Re: pgsql-server/src backend/bootstrap/Tag: backen ...

From
Peter Eisentraut
Date:
Bruce Momjian writes:

> > The whole MinGW thing is overhyped.  Install Cygwin and specify gcc
> > -mno-cygwin when you compile.  That gets you the same compilation
> > environment that MinGW provides, but you can use all the Unix tools.
>
> But we still need to do the work of getting this to work without
> compatiblity libraries.

That's what I'm saying: -mno-cygwin turns off all the Cygwin compatiblity
libraries and compiles it just like MinGW.  It's the same code.

> > Yeah, but if there is supposedly no cvs available in that environment,
> > what is the point of this exercise?  They're going to have to download a
> > pre-cooked tarball anyway.
>
> True.  They could CVS from somewhere else and copy it to Win32, but they
> would need flex/bison on Win32 for the compile.  It just seemed two less
> things for people to do.

If they get cvs from "somewhere", why can't they get flex and bison from
the same place?

--
Peter Eisentraut   peter_e@gmx.net


Re: pgsql-server/src backend/bootstrap/Tag: backen ...

From
Bruce Momjian
Date:
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > > The whole MinGW thing is overhyped.  Install Cygwin and specify gcc
> > > -mno-cygwin when you compile.  That gets you the same compilation
> > > environment that MinGW provides, but you can use all the Unix tools.
> >
> > But we still need to do the work of getting this to work without
> > compatiblity libraries.
>
> That's what I'm saying: -mno-cygwin turns off all the Cygwin compatiblity
> libraries and compiles it just like MinGW.  It's the same code.

I am not using any MinGW features.  The changes I am making are needed
for a Visual C port or any native port.

I am using MinGW because there is no confusion over libraries I _don't_
want to use, and over possible license issues.  We can switch to Cygwin
if we wish --- the Win32 code will be the same.  I don't even have a
compile test for MinGW being present or anything.

> > > Yeah, but if there is supposedly no cvs available in that environment,
> > > what is the point of this exercise?  They're going to have to download a
> > > pre-cooked tarball anyway.
> >
> > True.  They could CVS from somewhere else and copy it to Win32, but they
> > would need flex/bison on Win32 for the compile.  It just seemed two less
> > things for people to do.
>
> If they get cvs from "somewhere", why can't they get flex and bison from
> the same place?

I am not sure.

I don't understand why people are wasting time worrying about a few
files resurected in CVS to assist Win32.  If you want me to set up my
own CVS so people aren't bothered, maybe I should do that.  It is a pain
to be having to answer so many questions about something that is
micro-managing a project like this.

If you want a vote on whether those files should be added, fine, if not,
I would rather not hear complaints.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Re: pgsql-server/src backend/bootstrap/Tag: backen ...

From
Bruce Momjian
Date:
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > Peter Eisentraut wrote:
> > > Bruce Momjian writes:
> > >
> > > > Also, those files will not move into main CVS, and no one in Win32 is
> > > > going to be playing with changing any of the source files used by
> > > > bison/flex.
> > >
> > > That is just false.  Look at the CVS history of these files.
> >
> > I meant I wasn't going to _resurect_ those files in CVS HEAD, only in
> > WIN32_DEV.
>
> That is not the point.  The point is: you claim that no Windows developers
> are going to want to change those files.  The fact is: A glance at the CVS
> history shows that these files have already been changed several times
> because of Windows-related work.

Uh, I am lost now.  The derived files have changes for Windows?  Oh, I
do remember changes for WIN32 reserved words that are used in our
grammar, but those are all done now.  Right now, we have a TODO list,
and are focusing on that.  If someone changes it for Win32, I will
update the file.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Re: pgsql-server/src backend/bootstrap/Tag: backen ...

From
Tom Lane
Date:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I don't understand why people are wasting time worrying about a few
> files resurected in CVS to assist Win32.

Because this approach incurs a long-term cost (CVS storage) to buy a
short-term benefit (Windows developers might not need flex&bison).
The long-term cost is not trivial --- if you look at the CVS history
for the short interval that we kept these files in CVS, you will see
lots of five-thousand-line diffs corresponding to trivial changes in
the gram.y source.  We abandoned that approach for very good reasons.

It was already pointed out that Windows users wouldn't get any benefit
at all unless they installed a CVS client.  Surely if they can do that,
they can install flex&bison too.

We decided years ago that the minimum requirement to use our CVS sources
on Unix systems was the ability to run flex and bison locally (and we've
not had much patience with people running old versions of same, either).
I don't see the argument why people helping to develop a cutting-edge
Windows port should be expected to be less competent than every single
Unix CVS user.  (Other than the fact that they're using Windows in the
first place of course ;-)))

            regards, tom lane

Re: pgsql-server/src backend/bootstrap/Tag: backen ...

From
Christof Petig
Date:
Bruce Momjian schrieb:
> Marc G. Fournier wrote:
>
>>>Hmm, another problem is that I don't think there is a flex port for
>>>MinGW --- at least I remember someone saying they found bison, but not
>>>flex, so if they grab the snapshot, they will not be able to use CVS to
>>>do development and diffs.
>>
>>Actually, if I recall that same thread, one person mentioned downloading a
>>MinGW bison port, and then could build flex no problem using that ...
>>
>>Basically, I agree with Tom ... if we are going to go the extra steps to
>>support Win32, at least the Win32 ppl can do is take the extra steps to
>>build using the same 'restrictions' as the Unix ppl go through ...
>
>
> Well, the files are in there now --- I might as well just leave them so
> they don't have to go through that.  This MinGW environment is much more
> limited than a Unix environment --- no bison, flex, cvs, or perl.

You should really consider using MSys (the development environment by
one of the MinGW developers). It offers bash,perl,cvs,ssh,libtool,auto*
and more in 3+9MB. I can't imagine porting anything from unix to Windows
without that environment. It should even offer bison+flex.

    Christof



Re: pgsql-server/src backend/bootstrap/Tag: backen ...

From
Bruce Momjian
Date:
Christof Petig wrote:
> >>Basically, I agree with Tom ... if we are going to go the extra steps to
> >>support Win32, at least the Win32 ppl can do is take the extra steps to
> >>build using the same 'restrictions' as the Unix ppl go through ...
> >
> >
> > Well, the files are in there now --- I might as well just leave them so
> > they don't have to go through that.  This MinGW environment is much more
> > limited than a Unix environment --- no bison, flex, cvs, or perl.
>
> You should really consider using MSys (the development environment by
> one of the MinGW developers). It offers bash,perl,cvs,ssh,libtool,auto*
> and more in 3+9MB. I can't imagine porting anything from unix to Windows
> without that environment. It should even offer bison+flex.

I have Msys installed, but I don't see perl or cvs.  Here is my /bin:

    awk*           egrep*      infokey.exe*       od.exe*     start*
    basename.exe*  env.exe*    install-info.exe*  patch.exe*  tail.exe*
    bunzip2*       ex*         install.exe*       printf*     tar.exe*
    bzip2.exe*     expr.exe*   less.exe*          ps.exe*     tee.exe*
    cat.exe*       false.exe*  libW11.dll*        pwd*        texindex.exe*
    chmod.exe*     fgrep*      ln.exe*            rm.exe*     touch.exe*
    cmd*           find.exe*   lnkcnv*            rmdir.exe*  tr.exe*
    cmp.exe*       fold.exe*   ls.exe*            rvi*        true.exe*
    comm.exe*      ftp*        m4.exe*            rview*      uname.exe*
    cp.exe*        gawk.exe*   make.exe*          rvim*       uniq.exe*
    cut.exe*       grep.exe*   makeinfo.exe*      rxvt.exe*   vi*
    date.exe*      gunzip*     md5sum.exe*        sed.exe*    view*
    diff.exe*      gzip.exe*   mkdir.exe*         sh.exe*     vim.exe*
    diff3.exe*     head.exe*   mount.exe*         sleep.exe*  wc.exe*
    dirname.exe*   id.exe*     msys-1.0.dll*      sort.exe*
    echo*          info.exe*   mv.exe*            split.exe*

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Re: pgsql-server/src backend/bootstrap/Tag: backen ...

From
Bruce Momjian
Date:
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > I don't understand why people are wasting time worrying about a few
> > files resurected in CVS to assist Win32.
>
> Because this approach incurs a long-term cost (CVS storage) to buy a
> short-term benefit (Windows developers might not need flex&bison).
> The long-term cost is not trivial --- if you look at the CVS history
> for the short interval that we kept these files in CVS, you will see
> lots of five-thousand-line diffs corresponding to trivial changes in
> the gram.y source.  We abandoned that approach for very good reasons.
>
> It was already pointed out that Windows users wouldn't get any benefit
> at all unless they installed a CVS client.  Surely if they can do that,
> they can install flex&bison too.
>
> We decided years ago that the minimum requirement to use our CVS sources
> on Unix systems was the ability to run flex and bison locally (and we've
> not had much patience with people running old versions of same, either).
> I don't see the argument why people helping to develop a cutting-edge
> Windows port should be expected to be less competent than every single
> Unix CVS user.  (Other than the fact that they're using Windows in the
> first place of course ;-)))

I already said I am not updating the derived files unless we have to
make a Win32 fix for it.  The CVS branch is only going to be active
until we start 7.5 development.

Marc, maybe you better make me a separate CVS tree for Win32, rather
than branch.  There are too many people who's desire for perfect extends
even to the CVS branches.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Re: pgsql-server/src backend/bootstrap/Tag: backen ...

From
Bruce Momjian
Date:
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > I don't understand why people are wasting time worrying about a few
> > files resurected in CVS to assist Win32.
>
> Because this approach incurs a long-term cost (CVS storage) to buy a
> short-term benefit (Windows developers might not need flex&bison).
> The long-term cost is not trivial --- if you look at the CVS history
> for the short interval that we kept these files in CVS, you will see
> lots of five-thousand-line diffs corresponding to trivial changes in
> the gram.y source.  We abandoned that approach for very good reasons.
>
> It was already pointed out that Windows users wouldn't get any benefit
> at all unless they installed a CVS client.  Surely if they can do that,
> they can install flex&bison too.
>
> We decided years ago that the minimum requirement to use our CVS sources
> on Unix systems was the ability to run flex and bison locally (and we've
> not had much patience with people running old versions of same, either).
> I don't see the argument why people helping to develop a cutting-edge
> Windows port should be expected to be less competent than every single
> Unix CVS user.  (Other than the fact that they're using Windows in the
> first place of course ;-)))

Also, I am told flex doesn't run on MinGW properly --- not sure why.

Anyway, buy continuing complaints, you are asking for a vote, so I will
start one now.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Re: pgsql-server/src backend/bootstrap/Tag: backen ...

From
Christof Petig
Date:
[trimmed CC a bit, though committer is OT, it clearly is the only
mailing list involved. Time for a pgsql-win32?]

Bruce Momjian schrieb:
> Christof Petig wrote:
>>>Well, the files are in there now --- I might as well just leave them so
>>>they don't have to go through that.  This MinGW environment is much more
>>>limited than a Unix environment --- no bison, flex, cvs, or perl.
>>
>>You should really consider using MSys (the development environment by
>>one of the MinGW developers). It offers bash,perl,cvs,ssh,libtool,auto*
>>and more in 3+9MB. I can't imagine porting anything from unix to Windows
>>without that environment. It should even offer bison+flex.

there is an extra package called msysDTK (developer toolkit)
http://sourceforge.net/project/shownotes.php?release_id=158856

and msysDTK-1.0.0-alpha-1.tar.gz includes perl (since actual msysDTK is
an opaque .exe it's difficult for me to tell whether perl is in it, I
clearly have perl.exe in my msys/bin).

bison and flex are available from the gnuwin32 effort:
http://gnuwin32.sourceforge.net/packages.html

    Christof

PS: Never install normal windows binaries in msys/bin. There are special
command line properties (directory structure compatibility) associated
with msys/bin.


Re: pgsql-server/src backend/bootstrap/Tag: backen ...

From
Christof Petig
Date:
Christof Petig schrieb:
> bison and flex are available from the gnuwin32 effort:
> http://gnuwin32.sourceforge.net/packages.html

additional comments from an mingw developer:

Earnie Boyd schrieb:
 > Darko Prenosil wrote:
 >> Bison binary downloaded from MinGW site was not working - and that one
 >> was not compiled by me.
 >
 > I've marked it on my round tuit list to look at.  Configuring with
 > --prefix=/mingw and doing a make && make install will correct your
problem.