From: Alan W. I. <ir...@be...> - 2001-12-24 23:22:26
|
The files in the commit message below depend on pltclgen, plapi.tpl, and tclcmd.tpl and are easily generated by perl pltclgen In the interest of keeping our cvs free of files which are generated from other files I would like to remove these from cvs. Please let me know if there are any good reasons to keep these files under cvs control. Alan email: ir...@be... phone: 250-727-2902 FAX: 250-721-7715 snail-mail: Dr. Alan W. Irwin Department of Physics and Astronomy, University of Victoria, P.O. Box 3055, Victoria, British Columbia, Canada, V8W 3P6 __________________________ Linux-powered astrophysics __________________________ On Mon, 24 Dec 2001, Alan W. Irwin wrote: > Update of /cvsroot/plplot/plplot/bindings/tcl > In directory usw-pr-cvs1:/tmp/cvs-serv31978 > > Modified Files: > tclgen.c tclgen.h tclgen_s.h > Log Message: > Regenerate > > > _______________________________________________ > Plplot-cvs mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-cvs > |
From: Geoffrey F. <fu...@ga...> - 2001-12-26 16:38:06
|
Alan W. Irwin writes: > The files in the commit message below depend on pltclgen, plapi.tpl, and > tclcmd.tpl and are easily generated by > > perl pltclgen > > In the interest of keeping our cvs free of files which are generated from > other files I would like to remove these from cvs. > > Please let me know if there are any good reasons to keep these files under > cvs control. Maurice will probably be the only one besides me who will remember that the use of a perl-based pltclgen was the source of the overwhelming majority of plplot build problems trouble reports, for a number of years. People would fetch the snapshots, try to build, wouldn'thave perl on their system, configure would work but the build would fail, and they'd send trouble reports in like the Great Flood. When I got so tired I could stand it no longer, I just added the files to the repo so that would-be users wouldn't be triped up over such a small thing. That was before we had binary releases. I dunno, maybe it would be okay to go back to the "no generated files in the repo" posture now, figuring that anyone skipping the .rpms and just checking out the source directly, can handle a build. But note that some users took particular exception to the fact that they had to have perl installed in order to build the Tcl binding :-). Checking the files in was the act that stemmed the tide. If you want to unplug the dike, its on you. :-). -- Geoffrey Furnish fu...@ga... |
From: Alan W. I. <ir...@be...> - 2001-12-26 22:23:19
|
On Wed, 26 Dec 2001, Geoffrey Furnish wrote: > Alan W. Irwin writes: > > Please let me know if there are any good reasons to keep these files under > > cvs control. > > [...] configure would work but the build > would fail, and they'd send trouble reports in like the Great Flood. > > When I got so tired I could stand it no longer, I just added the files > to the repo so that would-be users wouldn't be triped up over such a > small thing. > > That was before we had binary releases. I dunno, maybe it would be > okay to go back to the "no generated files in the repo" posture now, > figuring that anyone skipping the .rpms and just checking out the > source directly, can handle a build. But note that some users took > particular exception to the fact that they had to have perl installed > in order to build the Tcl binding :-). > > Checking the files in was the act that stemmed the tide. If you want > to unplug the dike, its on you. :-). I have a feeling that our users are a different bunch now. For one thing most of them probably use Linux which will have perl almost automatically. Also, one hopes that the perl/tcl/python scripting language flamefests have cooled down a bit. I prefer python for myself, but I don't give a damn if perl and tcl are on my machine and are actively used in a number of ways to make my life easier. Will it confuse cvs if I remove the 3 generated files from cvs control, but then change my mind later and want to put them under cvs control again? If changing my mind is no problem to cvs (meaning I can always go back if there is a storm of protest), then I think the right thing to do is to treat these generated files the same way we do the configure script; exclude them from cvs control but generate them for the tarball release. This only puts the onus on those of us here on the developer's list (and perhaps a few more) that are building from CVS to be sure that they have perl. Any objections to having perl on your machine from the developers here? Alan |
From: Maurice L. <mj...@ga...> - 2001-12-26 23:34:02
|
Alan W. Irwin writes: > Will it confuse cvs if I remove the 3 generated files from cvs control, but > then change my mind later and want to put them under cvs control again? Sadly, yes. I've never been able to resurrect dead files without directly modifying the repository. I just tried now on a test file / test repository and still it doesn't work through the API. > If changing my mind is no problem to cvs (meaning I can always go back if > there is a storm of protest), then I think the right thing to do is to treat > these generated files the same way we do the configure script; exclude them > from cvs control but generate them for the tarball release. This only puts > the onus on those of us here on the developer's list (and perhaps a few > more) that are building from CVS to be sure that they have perl. I don't see any problem with this. Previously, it was leaving the generated files out of the public distribution that caused all the trouble. > Any objections to having perl on your machine from the developers here? I doubt there'll be any objections. And as far as availability goes, IIRC perl's even available under Windows. -- Maurice LeBrun mj...@ga... |
From: Alan W. I. <ir...@be...> - 2002-01-04 18:44:50
|
On Wed, 26 Dec 2001, Maurice LeBrun wrote: > Alan W. Irwin writes: > > Will it confuse cvs if I remove the 3 generated files from cvs control, but > > then change my mind later and want to put them under cvs control again? > > Sadly, yes. I've never been able to resurrect dead files without directly > modifying the repository. I just tried now on a test file / test repository > and still it doesn't work through the API. Thanks for this information. I am going to take my chances that I will never have to modify the repository (which would require SF's help or other extraordinary measures) to get these generated files back into cvs. > > > ....I think the right thing to do is to treat > > these generated files the same way we do the configure script; exclude them > > from cvs control but generate them for the tarball release. This only puts > > the onus on those of us here on the developer's list (and perhaps a few > > more) that are building from CVS to be sure that they have perl. > > I don't see any problem with this. Previously, it was leaving the generated > files out of the public distribution that caused all the trouble. > > > Any objections to having perl on your machine from the developers here? > > I doubt there'll be any objections. And as far as availability goes, IIRC > perl's even available under Windows. Thanks for your thoughts on this change. Also, I have specifically contacted Olof (our windows porter) on this question, and apparently it will not be a problem for him. Therefore, I have just made this change to CVS (and have already put a reminder in my release self-instructions to generate these files for the tarball release.) Alan |
From: Maurice L. <mj...@ga...> - 2002-01-15 05:53:34
|
Maurice LeBrun writes: > Alan W. Irwin writes: > > If changing my mind is no problem to cvs (meaning I can always go back if > > there is a storm of protest), then I think the right thing to do is to treat > > these generated files the same way we do the configure script; exclude them > > from cvs control but generate them for the tarball release. This only puts > > the onus on those of us here on the developer's list (and perhaps a few > > more) that are building from CVS to be sure that they have perl. > > I don't see any problem with this. Previously, it was leaving the generated > files out of the public distribution that caused all the trouble. Well right off I hit a problem (first plplot build I've tried in a while). There is a catch-22 with the build process: the necessary header files get built *after* the symlinks into tmp/plplot are created, so they are not found. E.g. on a fresh build: ... gcc -c -g -O -I. -I/home/mjl/gts/include plimage.c cd /home/mjl/dev/plplot/latest/bindings/tcl; \ perl pltclgen cd /home/mjl/dev/plplot/latest/bindings/tcl; \ perl pltclgen cd /home/mjl/dev/plplot/latest/bindings/tcl; \ perl pltclgen gcc -c -g -O -I. -I/home/mjl/gts/include tclAPI.c tclAPI.c:35:27: plplot/tclgen.h: No such file or directory tclAPI.c:70:29: plplot/tclgen_s.h: No such file or directory tclAPI.c:478:20: tclgen.c: No such file or directory make: *** [tclAPI.o] Error 1 Running configure again "solves" this problem, but a nicer solution should be found. -- Maurice LeBrun mj...@ga... |
From: Alan W. I. <ir...@be...> - 2002-01-15 17:57:44
|
On Mon, 14 Jan 2002, Maurice LeBrun wrote: > E.g. on a fresh build: > > ... > gcc -c -g -O -I. -I/home/mjl/gts/include plimage.c > cd /home/mjl/dev/plplot/latest/bindings/tcl; \ > perl pltclgen > cd /home/mjl/dev/plplot/latest/bindings/tcl; \ > perl pltclgen > cd /home/mjl/dev/plplot/latest/bindings/tcl; \ > perl pltclgen > gcc -c -g -O -I. -I/home/mjl/gts/include tclAPI.c > tclAPI.c:35:27: plplot/tclgen.h: No such file or directory > tclAPI.c:70:29: plplot/tclgen_s.h: No such file or directory > tclAPI.c:478:20: tclgen.c: No such file or directory > make: *** [tclAPI.o] Error 1 > > Running configure again "solves" this problem, but a nicer solution should be > found. I put in some specific symlinks into configure.in, and that seems to solve the problem according to my one superficial test. Please test it for yourself, and let me know what you think. Alan |