[GRASS5] Thought on my CVS problem

[Bernhard Reiter]

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 at 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 at 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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 236 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20000918/94dca048/attachment.bin