[GRASS5] Thought on my CVS problem

GRASS GRASS developer
1

Hello all

Yesterday, when I found that some files in the CVS tree that I had not
modified were changed when I did a cvs commit from the top directory, I
thought that such commits were not a good idea. After thinking about
this though, I feel that there should be no reason for not performing a
commit from the top of the CVS tree. After all, the cvs commit command
is recursive by default for a reason - to allow multiple files in
several directories to be committed at the same time.

At the time, I was more concerned with getting the tree back to normal
than with what was actually happening, especially since the first few
files I checked had been wiped out (see this old version
http://freegis.org/cgi-bin/viewcvs.cgi/~checkout~/grass/man/cat1/r.mapcalc?rev=1.5&content-type=text/plain
for an example). But today, I have looked into the files that caused the
problem and the following files can be explained.

src/include/config.h
src/raster/r.binfer/gram.c
src/raster/r.binfer/lex.c
src/raster/r.combine/cmd/gis_lxcl.c
src/raster/r.combine/cmd/gis_pars.c
src/raster/r.combine/cmd/gis_pars.h
src/raster/r.combine/cmd/gis_pars.out
src/raster/r.mapcalc/polish/lex.yy.c
src/raster/r.mapcalc/polish/y.tab.c
src/raster/r.weight/inter/gis_lxcl.c
src/raster/r.weight/inter/gis_pars.c
src/raster/r.weight/inter/gis_pars.h
src/raster/r.weight/inter/gis_pars.out
src/scripts/shells/create_fifos.sh

Correct me if I'm wrong, but all of these files are created at compile
time. As such, I would like to propose that these files be removed from
the CVS source tree. The only ones I hesitate to remove are config.h,
and create_fifos.sh. I think config.h can be removed since it is created
by the configure script, but I'm not sure about create_fifos.sh.

Most of the other files are man pages

man/cat1/r.mapcalc
man/cat1/r.patch
man/cat3/v.in.dxf3d.sh
man/cat4/m.ipf
man/cat4/m.sdts.read
man/cat4/m.svfit
man/cat4/v.out.sdts
man/cat4/v.sdts.dq.cp
man/cat4/v.sdts.meta
man/cat4/v.sdts.meta.cp
man/cat4/v.what
man/utilities/man.version

I don't know why these files were changed. But upon investigation,
perhaps all the files in the cat directories should be removed from the
CVS source tree since the man/utilities/Nroff script supposedly creates
them at compile time (from the Nroff script: "Script to produce cat*
entries from GRASS man* man page source.") as well as the man.version
file. Maybe even the cat directories thenmselves should be deleted and
their creation added to the src/CMD/generic/GISGEN.sh script similar to
the man/1, man/2 etc. directories.

Since it appears that these files are all created during compilation,
then performing a cvs commit at the top of the CVS source tree should
not be a problem.

Anyway, does anyone know of any reason why these files should not be
removed from the CVS source tree? Since Markus is away this week, I will
wait to hear from him before I do anything. But, at this time I see no
reason to keep files that are generated at compile time in the CVS
source tree.

By the way, if these files are removed from the source tree, I will add
them to the "make distclean" target in the Makefile.in file as well.

Thank you for your time and any comments would be greatly appreciated.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

2

Yes, I agree that the compilation or configure output files should be
removed from the CVS tree. This is normal practice in other projects.
Further, the files named should be included in a .cvsignore file in
the directory that they will reside, and the .cvsignore files should be
in CVS.

--
James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

3

On Wed, Sep 13, 2000 at 08:26:02AM +1100, James Cameron wrote:

Yes, I agree that the compilation or configure output files should be
removed from the CVS tree.

I also agree,
but we must have them in the tarball,
so there should be a target to just build them if we remove them from
the CVS version.

Not everybody has a recent autoconf or flex/bison installed and properly
configured. Which means we are excluding some people from using the
CVS directly. (I do not think it is a problem, but it should be noted.)

  Bernhard

This is normal practice in other projects.
Further, the files named should be included in a .cvsignore file in
the directory that they will reside, and the .cvsignore files should be
in CVS.

This only helps with imports, right?
  
--
Professional Service around Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)

4

Hello Bernhard

Bernhard Reiter wrote:

On Wed, Sep 13, 2000 at 08:26:02AM +1100, James Cameron wrote:
> Yes, I agree that the compilation or configure output files should
> be removed from the CVS tree.

I also agree,
but we must have them in the tarball,
so there should be a target to just build them if we remove them from
the CVS version.

Not everybody has a recent autoconf or flex/bison installed and
properly configured. Which means we are excluding some people from
using the
CVS directly. (I do not think it is a problem, but it should be
noted.)

But these files are platform dependent (especially the autoconf files).
If we were to keep them for those who can't generate them, then we would
need to keep a copy for each platform. This seems to be a lot of trouble
to me. I really don't think we are being thoughtless by asking people to
have proper versions of software that is required to compile grass.
After all, we do that for tcltkgrass.

Just a thought.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

5

On Wed, Sep 13, 2000 at 08:58:39AM +0200, Bernhard Reiter wrote:

> This is normal practice in other projects.
> Further, the files named should be included in a .cvsignore file in
> the directory that they will reside, and the .cvsignore files should be
> in CVS.

This only helps with imports, right?

It'll keep all "ignored" file from being added to repository. Makefiles,
object files, etc. are all good candidates. You can use wildcards in the
file *.o, OBJ_*, etc...

--
/bin/sh ~/.signature:
Command not found

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

6

On Wed, Sep 13, 2000 at 02:50:28PM +0700, Justin Hickey wrote:

Bernhard Reiter wrote:
> On Wed, Sep 13, 2000 at 08:26:02AM +1100, James Cameron wrote:
> > Yes, I agree that the compilation or configure output files should
> > be removed from the CVS tree.
>
> I also agree,
> but we must have them in the tarball,
> so there should be a target to just build them if we remove them from
> the CVS version.
>
> Not everybody has a recent autoconf or flex/bison installed and
> properly configured. Which means we are excluding some people from
> using the
> CVS directly. (I do not think it is a problem, but it should be
> noted.)

But these files are platform dependent (especially the autoconf files).

configure should not be platform dependent.
Most free software packages coming with a ready to run configure
and lex and yacc output files.

So you can compile without proper automake/autoconf installed.
But you need this as a developer if you want to create configure.
  Bernhard

--
Professional Service around Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)

7

On Wed, Sep 13, 2000 at 08:58:39AM +0200, Bernhard Reiter wrote:

On Wed, Sep 13, 2000 at 08:26:02AM +1100, James Cameron wrote:
> Yes, I agree that the compilation or configure output files should be
> removed from the CVS tree.
I also agree, but we must have them in the tarball,
so there should be a target to just build them if we remove them from
the CVS version.
Not everybody has a recent autoconf or flex/bison installed and properly
configured. Which means we are excluding some people from using the
CVS directly. (I do not think it is a problem, but it should be noted.)

I will politely continue to disagree.

Those people can go get a recent autoconf or flex/bison installed, if
they are wanting to compile the sources. Some of the build utilities
may have architecture dependencies that render their output wrong for
the platform the end user of a tarball tries to compile on.

Example: assume you use a Linux Intel machine to build the flex/bison
output, and further assume that flex/bison generates 32-bit specific
code on your machine. It gets committed to CVS or saved in the tarball,
and then I install it on my Linux Alpha machine. I blindly try to
build and the 32-bit code is used on my 64-bit machine, causing
problems. I end up writing lots of mail, and eventually someone says
"oh, try deleting the source files generates by flex or bison".

Doesn't seem right, somehow.

Most other open source packages require that I have the tools to build
them.

> Further, the files named should be included in a .cvsignore file in
> the directory that they will reside, and the .cvsignore files should be
> in CVS.
This only helps with imports, right?

No, it also helps with commit and diff, the files listed in .cvsignore
don't get listed with a question mark beside them. You should be able
to do a "make distclean" before a "cvs diff" and see no extra files
mentioned. Good test of the coverage of .cvsignore. It also helps to
make sure that you have all the source files properly added to CVS.

--
James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

8

On Wed, Sep 13, 2000 at 12:55:49AM -0700, Eric G . Miller wrote:

On Wed, Sep 13, 2000 at 08:58:39AM +0200, Bernhard Reiter wrote:
> > This is normal practice in other projects.
> > Further, the files named should be included in a .cvsignore file in
> > the directory that they will reside, and the .cvsignore files should be
> > in CVS.
>
> This only helps with imports, right?

It'll keep all "ignored" file from being added to repository. Makefiles,
object files, etc. are all good candidates. You can use wildcards in the
file *.o, OBJ_*, etc...

Yes.
But this only matters when doing a recursive cvs import.
  Bernhard
--
Professional Service around Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)

9

Hello Bernhard

Bernhard Reiter wrote:

On Wed, Sep 13, 2000 at 02:50:28PM +0700, Justin Hickey wrote:
> But these files are platform dependent (especially the autoconf files).

configure should not be platform dependent.
Most free software packages coming with a ready to run configure
and lex and yacc output files.

So you can compile without proper automake/autoconf installed.
But you need this as a developer if you want to create configure.

OK, but the main reason I said they were platform dependent was due to
the amount of differences between the CVS files and those generated on
my machine. See for example, the src/raster/r.weight/inter/gis_pars.c
file. Click the following link and choose Diff to previous 1.2 from
version 1.3

http://freegis.org/cgi-bin/viewcvs.cgi/grass/src/raster/r.weight/inter/gis_pars.c

As you can see, the files are completely different and I don't know if
the compiling one on a different platform will cause problems or not.
What do you think?

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

10

On Wed, Sep 13, 2000 at 03:25:09PM +0700, Justin Hickey wrote:

Bernhard Reiter wrote:
>
> On Wed, Sep 13, 2000 at 02:50:28PM +0700, Justin Hickey wrote:
> > But these files are platform dependent (especially the autoconf files).
>
> configure should not be platform dependent.
> Most free software packages coming with a ready to run configure
> and lex and yacc output files.
>
> So you can compile without proper automake/autoconf installed.
> But you need this as a developer if you want to create configure.

OK, but the main reason I said they were platform dependent was due to
the amount of differences between the CVS files and those generated on
my machine. See for example, the src/raster/r.weight/inter/gis_pars.c
file. Click the following link and choose Diff to previous 1.2 from
version 1.3

http://freegis.org/cgi-bin/viewcvs.cgi/grass/src/raster/r.weight/inter/gis_pars.c

As you can see, the files are completely different and I don't know if
the compiling one on a different platform will cause problems or not.
What do you think?

You were probably using completly different versions of yacc oder bison.

I see no reason why a good bison output should not be platform
dependent. If it is, then we cannot bring the preconstructed files
with the standard tarball.
  Bernhard

--
Professional Service around Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)

11

On Wed, Sep 13, 2000 at 07:06:05PM +1100, James Cameron wrote:

On Wed, Sep 13, 2000 at 08:58:39AM +0200, Bernhard Reiter wrote:
> On Wed, Sep 13, 2000 at 08:26:02AM +1100, James Cameron wrote:

> Not everybody has a recent autoconf or flex/bison installed and properly
> configured. Which means we are excluding some people from using the
> CVS directly. (I do not think it is a problem, but it should be noted.)

I will politely continue to disagree.

Those people can go get a recent autoconf or flex/bison installed, if
they are wanting to compile the sources.

They could, but if it is unnecessary it is an unnecessary hassle.
(And it can be quite a pain getting autoconf flex and bison installed.)

Some of the build utilities
may have architecture dependencies that render their output wrong for
the platform the end user of a tarball tries to compile on.

But not configure, flex and bison.

Example: assume you use a Linux Intel machine to build the flex/bison
output, and further assume that flex/bison generates 32-bit specific
code on your machine. It gets committed to CVS or saved in the tarball,
and then I install it on my Linux Alpha machine. I blindly try to
build and the 32-bit code is used on my 64-bit machine, causing
problems. I end up writing lots of mail, and eventually someone says
"oh, try deleting the source files generates by flex or bison".

Doesn't seem right, somehow.

True, bugt AFAIK the assumption is wrong.
The generated configure script and flex and bison code _should_
be platform independant. If it is not, the right way would be to fix
them.

Most other open source packages require that I have the tools to build
them.

> > Further, the files named should be included in a .cvsignore file in
> > the directory that they will reside, and the .cvsignore files should be
> > in CVS.
> This only helps with imports, right?

No, it also helps with commit and diff, the files listed in .cvsignore
don't get listed with a question mark beside them.

Actually I think that this question mark helps clarify the situation
of the files. The actual behaviour of CVS is the same in this case.

You should be able
to do a "make distclean" before a "cvs diff" and see no extra files
mentioned.

True, because they are not there, if they do not belong in CVS: :slight_smile:

Good test of the coverage of .cvsignore. It also helps to make sure
that you have all the source files properly added to CVS.

  Bernhard
--
Professional Service around Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)

12

Hello Bernhard

Bernhard Reiter wrote:

I see no reason why a good bison output should not be platform
dependent. If it is, then we cannot bring the preconstructed files
with the standard tarball.

OK, but how do we determine if it actually is platform independant? Do
we need to brute force test it on every platform? And then once we do
determine this, how do we manage these files so that what happened to me
(local machine generating a very different version) doesn't happen in
the future? Also, if a user compiles GRASS and a new different version
is generated, can we assume the new version produced a file that
contains all the features it is supposed to? Is there a way to prevent
local machines (that have bison and yacc installed) from generating
their own version? Is the .cvsignore file that was mentioned earlier the
answer?

The reason I'm asking all these questions is that I never worked with
lex or yacc except for simple assignments at university. So I don't know
the differences between the different versions and the implications of
using the locally generated files with regard to them reliably
performing the same functionality as the CVS version.

This is important to me since I will be changing a large number of files
when I upgrade GRASS to use the new environment system, and I would
really prefer to do a commit from the root of the CVS tree.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

13

Justin,

we just have to know which files are platform independant.
If they are not, we have to fix it.

I would suggest that someone bundling the source up,
has to create this files. We might want another makefile target
or script for this: Creating platform independant files for
configure, flex and bison results and cleaning up again.

We might fix a little tarballs with just these files generated
for developers to test from time to time on their installations.

Someone who is a developer using the CVS
does not necessarily need the files as I think that we can demand
from a developer that he/she gets the tools first.
So we can remove them from the CVS.

Originally I just wanted to point out that we need this files in
a tarball source distribution.

Addressing your other question:
Only if the source file changes (e.g. configure.in) a remake of
configure is needed. So if you have a tarball with the current configure
there is no need to regenerate it and make won't do it.

.cvsignore is a convinience list, it makes CVS completly ignore some
files or directories. It helps not to clutter up the display when doing
updates and releases. For imports where it is useful
you can also specify it as a parameter to CVS.
So as long as we have not removed the files as mentioned above
you can use .cvsignore or the -I option to not commit yours with CVS.

Regards,
  Bernhard

On Mon, Sep 18, 2000 at 02:25:12PM +0700, Justin Hickey wrote:

Bernhard Reiter wrote:
> I see no reason why a good bison output should not be platform
> dependent. If it is, then we cannot bring the preconstructed files
> with the standard tarball.

OK, but how do we determine if it actually is platform independant? Do
we need to brute force test it on every platform? And then once we do
determine this, how do we manage these files so that what happened to me
(local machine generating a very different version) doesn't happen in
the future? Also, if a user compiles GRASS and a new different version
is generated, can we assume the new version produced a file that
contains all the features it is supposed to? Is there a way to prevent
local machines (that have bison and yacc installed) from generating
their own version? Is the .cvsignore file that was mentioned earlier the
answer?

The reason I'm asking all these questions is that I never worked with
lex or yacc except for simple assignments at university. So I don't know
the differences between the different versions and the implications of
using the locally generated files with regard to them reliably
performing the same functionality as the CVS version.

This is important to me since I will be changing a large number of files
when I upgrade GRASS to use the new environment system, and I would
really prefer to do a commit from the root of the CVS tree.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

--
Professional Service around Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)

14

Hi Bernhard

Bernhard Reiter wrote:

I would suggest that someone bundling the source up,
has to create this files. We might want another makefile target
or script for this: Creating platform independant files for
configure, flex and bison results and cleaning up again.

We might fix a little tarballs with just these files generated
for developers to test from time to time on their installations.

Someone who is a developer using the CVS
does not necessarily need the files as I think that we can demand
from a developer that he/she gets the tools first.
So we can remove them from the CVS.

Originally I just wanted to point out that we need this files in
a tarball source distribution.

Addressing your other question:
Only if the source file changes (e.g. configure.in) a remake of
configure is needed. So if you have a tarball with the current
configure there is no need to regenerate it and make won't do it.

First of all, I think there is a misunderstanding about the configure
script. I agree with you that the configure script should stay in the
CVS tree. Perhaps the misunderstanding came from my original post that
suggested that src/include/config.h be removed from the tree. I thought
that config.h was platform dependent since it is generated by configure.
Am I wrong with this?

Anyway, my contention is more for the lex and yacc generated files. I
think I am starting to understand the situation more. Let me see if I've
got this straight.

You propose that we remove these files from the CVS tree but bundle them
with our source code releases. This sounds reasonable, except I still
don't understand what will happen, for example, with my machine. Let's
assume I download a source tarball that has the generated lex and yacc
files. When I compile this on my machine, I have lex and yacc installed
and they get called by Make. Thus, the pre-generated files are now
replaced by ones generated by my version of lex and yacc. As I have
shown, these files can be drastically different from the pre-generated
files. My main concern now would be, do the new files have the same
functionality as the ones that they overwrote? I don't know due to my
lack of knowledge of lex and yacc.

If we can't answer this question reasonably, then should we guarantee
somehow that the generated files in the tarball never get replaced by
the local machine? Or is it safe to assume an appropriate file, although
different, will be equal in functionality, and perhaps even more
efficient since it may have been generated with vendor specific
programs?

Thank you for your patience with this. I sometimes feel like an idiot
when I need to discuss things I don't understand :slight_smile:

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

15

On Tue, Sep 19, 2000 at 11:27:57AM +0700, Justin Hickey wrote:

Bernhard Reiter wrote:

First of all, I think there is a misunderstanding about the configure
script. I agree with you that the configure script should stay in the
CVS tree.

Why? It can be generated by autoconf. :slight_smile:
But we might leave it in.

Perhaps the misunderstanding came from my original post that
suggested that src/include/config.h be removed from the tree. I thought
that config.h was platform dependent since it is generated by configure.
Am I wrong with this?

No. You are correct. Config.h ist platform dependent.

Anyway, my contention is more for the lex and yacc generated files. I
think I am starting to understand the situation more. Let me see if I've
got this straight.

You propose that we remove these files from the CVS tree but bundle them
with our source code releases.

Yes. We could do this. We can also do it with configure.

This sounds reasonable, except I still
don't understand what will happen, for example, with my machine. Let's
assume I download a source tarball that has the generated lex and yacc
files. When I compile this on my machine, I have lex and yacc installed
and they get called by Make. Thus, the pre-generated files are now
replaced by ones generated by my version of lex and yacc. As I have
shown, these files can be drastically different from the pre-generated
files. My main concern now would be, do the new files have the same
functionality as the ones that they overwrote? I don't know due to my
lack of knowledge of lex and yacc.

The results of lex and yacc _should_ be platform independent.
(Though you might need a library for flex, IIRC.).
So if the make sees that there are files present it will not
start flex or bison to create them and use the one already there.

If we can't answer this question reasonably, then should we guarantee
somehow that the generated files in the tarball never get replaced by
the local machine?

A proper Makefile should take care of this.

Or is it safe to assume an appropriate file, although
different, will be equal in functionality, and perhaps even more
efficient since it may have been generated with vendor specific
programs?

No, it might be that you need to start your version of flex or lex
if you are missing the library. The configure script could check for
this.

Thank you for your patience with this.

No Problem.
  Bernhard
--
Professional Service around Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)

16

First of all, Frank

Thanks for your comments. It makes things clearer now, and I agree that
the files in the tarball should be created with "clean" versions of lex
and yacc.

Bernhard

Bernhard Reiter wrote:

On Tue, Sep 19, 2000 at 11:27:57AM +0700, Justin Hickey wrote:
> Bernhard Reiter wrote:

> First of all, I think there is a misunderstanding about the
> configure script. I agree with you that the configure script should
> stay in the CVS tree.

Why? It can be generated by autoconf. :slight_smile:
But we might leave it in.

Ooops, for some reason I thought you had said to keep it. If we do get
rid of it, who should I talk to that can help me make the appropriate
change to effect the hardcoded changes I made to configure to get GRASS
to compile on an SGI? I couldn't find an appropriate section in
configure.in.

The results of lex and yacc _should_ be platform independent.
(Though you might need a library for flex, IIRC.).
So if the make sees that there are files present it will not
start flex or bison to create them and use the one already there.

I agree, but that did not happen on my machine. Perhaps the Gmakefiles
need to be tweaked, or maybe the time stamp of the generated C files
need to be ensured to be later than the lex or yacc source files. Maybe
once we remove these files from CVS, this will occur naturally when the
tarball is made.

So now, to summarize this discussion, it seems we agree to remove the
generated files from the CVS tree, which include the following

src/include/config.h
src/raster/r.binfer/gram.c
src/raster/r.binfer/lex.c
src/raster/r.combine/cmd/gis_lxcl.c
src/raster/r.combine/cmd/gis_pars.c
src/raster/r.combine/cmd/gis_pars.h
src/raster/r.combine/cmd/gis_pars.out
src/raster/r.mapcalc/polish/lex.yy.c
src/raster/r.mapcalc/polish/y.tab.c
src/raster/r.weight/inter/gis_lxcl.c
src/raster/r.weight/inter/gis_pars.c
src/raster/r.weight/inter/gis_pars.h
src/raster/r.weight/inter/gis_pars.out
src/scripts/shells/create_fifos.sh

As well as the man/cat*/ directories (adding their creation to
src/CMD/generic/GISGEN.sh) and man/utilities/man.version since they are
populated by the man/utilities/Nroff script.

What hasn't been finalized is whether the configure script should be
removed as well. Thus developers would need to have autoconf, flex, and
bison installed to compile GRASS.

Personally, it doesn't matter to me if we remove the configure script.
It at least would be consistant with removing all generated files, and
it would probably be good for me since I would need to learn autoconf
:).

So, unless somebody has objections to removing these files (including
configure) I will remove them next week (that should be enough time for
a response).

By the way, I know I need to install autoconf and m4, but do I also need
automake? Also, is there a quick and dirty way to get autoconf to
generate configure, or is it better to plug away at the documentation?

Thanks to everyone for their comments and clarifications. It really
helped me to understand these concepts.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

17

On Wed, Sep 20, 2000 at 03:34:09PM +0700, Justin Hickey wrote:
[...]

So now, to summarize this discussion, it seems we agree to remove the
generated files from the CVS tree, which include the following

src/include/config.h
src/raster/r.binfer/gram.c
src/raster/r.binfer/lex.c
src/raster/r.combine/cmd/gis_lxcl.c
src/raster/r.combine/cmd/gis_pars.c
src/raster/r.combine/cmd/gis_pars.h
src/raster/r.combine/cmd/gis_pars.out
src/raster/r.mapcalc/polish/lex.yy.c
src/raster/r.mapcalc/polish/y.tab.c
src/raster/r.weight/inter/gis_lxcl.c
src/raster/r.weight/inter/gis_pars.c
src/raster/r.weight/inter/gis_pars.h
src/raster/r.weight/inter/gis_pars.out
src/scripts/shells/create_fifos.sh

As well as the man/cat*/ directories (adding their creation to
src/CMD/generic/GISGEN.sh) and man/utilities/man.version since they are
populated by the man/utilities/Nroff script.

I agree with Justin (and probably others) to remove these files.
And I suggest to remove the entire man/ section and to create
them on the fly from HTML pages using g.html2man script. For me
it is much extra work to keep the MAN and HTML in sync. Why not
using the computer to to this work?
The g.html2man might need some few updates to support all important
HTML tags, but it is rather good. The last 30 man pages I generated
by this script from HTML.

What do you think?

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

18

Hi Markus

Markus Neteler wrote:

I agree with Justin (and probably others) to remove these files.
And I suggest to remove the entire man/ section and to create
them on the fly from HTML pages using g.html2man script. For me
it is much extra work to keep the MAN and HTML in sync. Why not
using the computer to to this work?
The g.html2man might need some few updates to support all important
HTML tags, but it is rather good. The last 30 man pages I generated
by this script from HTML.

What do you think?

I agree. I see no reason to keep multiple source files around when we
can generate all the help files we need from a single source.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

19

On Fri, Sep 15, 2000 at 10:07:54AM +0200, Bernhard Reiter wrote:

On Wed, Sep 13, 2000 at 07:06:05PM +1100, James Cameron wrote:
> Those people can go get a recent autoconf or flex/bison installed, if
> they are wanting to compile the sources.
They could, but if it is unnecessary it is an unnecessary hassle.
(And it can be quite a pain getting autoconf flex and bison installed.)

If there are problems installing autoconf, flex or bison, these should
be fixed. I've never had problems. Dodging the problems by shipping
GRASS source in a partially built form may hide them, stopping them
from being fixed.

The generated configure script should stay. It should also be
expanded to check for flex and bison. configure.in currently makes no
mention of bison/yacc, though it does mention AC_PROG_LEX. If you
intend to include flex output, it should be removed from configure.in.

My main reason for suggesting that lex and yacc output not be present
is that they are not source files. Portability is a side issue. Open
Source generally accepted practice is to only include source files and
the output of autoconf.

> Some of the build utilities
> may have architecture dependencies that render their output wrong for
> the platform the end user of a tarball tries to compile on.
But not configure, flex and bison.

I checked the output of the same version of bison on Compaq Tru64
UNIX, on Debian GNU/Linux on Alpha, and on Intel, and there are no
significant differences. However I can't be sure there are no
differences on other platforms. The checks made by the configure
script of bison 1.28 are quite extensive, covering many areas of
difference between platforms. This includes operating system
interfaces, not just processor architecture differences. I do not
think it is safe to assume there will be no future portability issues,
unless you were to include flex and bison sources within the GRASS
source tarball.

--
James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'