Would it be okay if I add some .cvsignore files to cvs?

So we don't need to get rows like

? po/tr.mo
? po/zh_CN.mo
? po/zh_TW.mo
? utils/mb/conversion_procs/euc_jp_and_sjis/libeuc_jp_and_sjis.so.0.0
? utils/mb/conversion_procs/euc_kr_and_mic/libeuc_kr_and_mic.so.0.0
? utils/mb/conversion_procs/euc_tw_and_big5/libeuc_tw_and_big5.so.0.0

when we do "cvs diff".

-- 
/Dennis Bjï¿½rklund


Sat, 24 Jan 2004 08:42:35 +0100 (CET)
Dennis Bjorklund <db@zigo.dhs.org>
cvsignore
Dennis Bjorklund wrote:
> Would it be okay if I add some .cvsignore files to cvs?
>
> So we don't need to get rows like
>
> ? po/tr.mo
> ? po/zh_CN.mo
> ? po/zh_TW.mo
> ? utils/mb/conversion_procs/euc_jp_and_sjis/libeuc_jp_and_sjis.so.0.0
> ? utils/mb/conversion_procs/euc_kr_and_mic/libeuc_kr_and_mic.so.0.0
> ? utils/mb/conversion_procs/euc_tw_and_big5/libeuc_tw_and_big5.so.0.0
>
> when we do "cvs diff".

I order to achieve that you would have to add *all* built files to 
cvsignore.  Surely you don't plan that?


Sat, 24 Jan 2004 11:06:09 +0100
Peter Eisentraut <peter_e@gmx.net>
Re: cvsignore
On Sat, 24 Jan 2004, Peter Eisentraut wrote:

> I order to achieve that you would have to add *all* built files to 
> cvsignore.  Surely you don't plan that?

Yes, I did plan that.

For my builds that is. If some other build environment creates other files
then here, then I can not add these to the ignore list (since I don't know
which files it is). People that use these build env. can add these files
if they want.

It's not like it's a big job. You just run cvs diff and it will say what 
files it is, and all you have to do is to make sure it's a built file and 
add it. One can also add globs in the ignore file so for the po directory 
one adds *.mo and all the build .mo files are ignored. Same thing for the 
lib*.so* files.

I have cvsignore files in all projects I handle myself.

One advantage of this is that you can do "cvs diff > foo.patch" and get a 
patch file without a lot of garbage.

-- 
/Dennis Bjï¿½rklund


Sat, 24 Jan 2004 11:27:25 +0100 (CET)
Dennis Bjorklund <db@zigo.dhs.org>
Re: cvsignore
Dennis Bjorklund wrote:
> One advantage of this is that you can do "cvs diff > foo.patch" and
> get a patch file without a lot of garbage.

Maybe you would be happier if you build outside the source tree.  Do

cd ..
mkdir pgbuild
cd pgbuild
../pgsql/configure --prefix.......
make
make install

Then to make a diff, go back

cd ../pgsql
cvs diff

and you won't have any built files in your way.


Sat, 24 Jan 2004 11:43:47 +0100
Peter Eisentraut <peter_e@gmx.net>
Re: cvsignore
On Sat, 24 Jan 2004, Peter Eisentraut wrote:

> Dennis Bjorklund wrote:
> > One advantage of this is that you can do "cvs diff > foo.patch" and
> > get a patch file without a lot of garbage.
> 
> Maybe you would be happier if you build outside the source tree.  Do

Sure, one can do that.

Still, if it doesn't bother anyone and it does help me, then I don't see 
why not.

I just noticed that there already are some .cvsignore files in the cvs
tree.

-- 
/Dennis Bjï¿½rklund


Sat, 24 Jan 2004 11:50:42 +0100 (CET)
Dennis Bjorklund <db@zigo.dhs.org>
Re: cvsignore
On Sat, Jan 24, 2004 at 11:43:47AM +0100, Peter Eisentraut wrote:

> Maybe you would be happier if you build outside the source tree.  Do
> [...]

I am currently building outside the source tree so that I don't have
these problems.  It works fine, except that some files are created in
the source tree anyway.  I think it's mostly output from bison and flex:

src/backend/parser/gram.c
src/backend/parser/scan.c
src/backend/bootstrap/bootparse.c
src/backend/bootstrap/bootscanner.c
src/interfaces/ecpg/preproc/pgc.c
src/interfaces/ecpg/preproc/preproc.c

(maybe I'm missing some files)

Maybe they are there because they are part of the source tarball?  It
annoys me a little because I do "diff -cr" between different source
directories and those files have lots of differences.


Also, the regression tests can be run fine with "make installcheck", but
if I want to run the parallel schedule, I have to point pg_regress to
the source dir.  Maybe the file could be copied to the build dir ...

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"La libertad es como el dinero; el que no la sabe emplear la pierde" (Alvarez)

Sat, 24 Jan 2004 12:09:58 -0300
Alvaro Herrera <alvherre@dcc.uchile.cl>
vpath build (was Re: cvsignore)
Dennis Bjorklund wrote:
> Still, if it doesn't bother anyone and it does help me, then I don't
> see why not.

Well, I think a lot of people would be bothered by the idea of you 
maintaining a copy of what will amount to a list of all files.  Even 
more people will be bothered by the idea that they would have to help 
maintaining it if they add or remove files.

> I just noticed that there already are some .cvsignore files in the
> cvs tree.

The files listed in those files have to be built in the source tree for 
various reasons even if you configure a separate build directory.  So 
the .cvsignore files serve to get clean cvs diffs if you use a separate 
build directory.


Sat, 24 Jan 2004 20:09:07 +0100
Peter Eisentraut <peter_e@gmx.net>
Re: cvsignore
Dennis Bjorklund <db@zigo.dhs.org> writes:
> On Sat, 24 Jan 2004, Peter Eisentraut wrote:
>> I order to achieve that you would have to add *all* built files to 
>> cvsignore.  Surely you don't plan that?

> Yes, I did plan that.

This would be quite unacceptable IMHO.  A cvs run *ought* to complain
if there is any cruft in the tree.  The .cvsignore files that exist
are there to prevent complaints about files that are built but are
included in distribution tarballs (and so are not removed by make
distclean).  If we did what you suggest, we'd miss bugs in "make clean"
rules that left cruft in the distribution.

FWIW, I find that by far the safest procedure for working with CVS tip
is to do a make distclean before any cvs update, so I'm not convinced
that what you want is worth expending effort towards anyway.  Rebuilding
after every update costs machine time, but seldom any of my time (I can
generally overlap it with other useful activities, eg reading mail).
Not rebuilding from scratch works most of the time, but when it doesn't
work you will waste large amounts of your own time trying to figure out
mysterious bugs that aren't really bugs but just build inconsistencies.
I've been there and done that enough times that I don't plan to do it
anymore.

			regards, tom lane

Sat, 24 Jan 2004 14:21:38 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: cvsignore 
Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
> I am currently building outside the source tree so that I don't have
> these problems.  It works fine, except that some files are created in
> the source tree anyway.  I think it's mostly output from bison and flex:

That's intentional, although it might not be necessary to do it that way
(when building a distribution tarball, we do or can build within the
source tree).  One advantage of doing it like this in a vpath build is
that those files are the same across all architectures and so you don't
need to build them again for each one ... but of course, if you're not
using vpath to handle multiple architecture builds then you don't care.
Personally I don't use vpath much and don't really care if we change
that behavior --- any other opinions out there?

> Also, the regression tests can be run fine with "make installcheck", but
> if I want to run the parallel schedule, I have to point pg_regress to
> the source dir.  Maybe the file could be copied to the build dir ...

That's an oversight, surely; but ISTM it worked last time I tried it.

			regards, tom lane

Sat, 24 Jan 2004 14:46:06 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: vpath build (was Re: cvsignore) 
On Sat, Jan 24, 2004 at 02:46:06PM -0500, Tom Lane wrote:
> Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
> > I am currently building outside the source tree so that I don't have
> > these problems.  It works fine, except that some files are created in
> > the source tree anyway.  I think it's mostly output from bison and flex:

[...]

> Personally I don't use vpath much and don't really care if we change
> that behavior --- any other opinions out there?

Maybe I just need to teach diff how to use the .cvsignore files.

> > Also, the regression tests can be run fine with "make installcheck", but
> > if I want to run the parallel schedule, I have to point pg_regress to
> > the source dir.  Maybe the file could be copied to the build dir ...
> 
> That's an oversight, surely; but ISTM it worked last time I tried it.

Checking the makefile, I see that "make installcheck" uses the serial
schedule, while "make check" uses the parallel one.  Is this
intentional?  I see this dates to the time those rules were invented,
GNUmakefile 1.24 ...

Maybe there should be rules to do a install-parallel and install-serial,
and others to do temp-install-parallel and temp-install-serial ... or
maybe just use some envvar to select the schedule to use.

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"I personally became interested in Linux while I was dating an English major
who wouldn't know an operating system if it walked up and bit him."
(Val Henson)

Sat, 24 Jan 2004 17:13:06 -0300
Alvaro Herrera <alvherre@dcc.uchile.cl>
Re: vpath build (was Re: cvsignore)