Re: problems with readline (compilation on mac fails)

[Ethan A M. <sf...@us...>]

On Wednesday, February 16, 2011 03:38:13 pm Hans-Bernhard Bröker wrote:
> On 16.02.2011 11:07, Mojca Miklavec wrote:
> 
> > It seems that ./configure script was old indeed
> 
> That's not really supposed to happen.  There's code in the Makefiles 
> that automatically builds everything, _including_ configure itself, 
> whenever any of the files it's made from change.  

Actually, I do not see any such depency or target in the Makefiles.
If I do "touch configure.in; make all", it does not re-run autotools.

But please, let's not blow this up into a big deal.
Yes, you should make sure that your configure script is current.
And yes, it is possible to forget this.  I've done so myself :-)

Mojca's case was rather extreme, a configure script left over somehow
from version 4.2 being mis-matched with current CVS version 4.5.
Perhaps we could at least have the script itself test for a match to
the current MAJOR.MINOR versioning?  So you'd see something like:

   ./configure
   Error:  Sorry, the version of this configure script (4.2) does not match 
              the version of the source code (4.5)

On the other hand, I have no strong objection to putting a copy of
the configure script into CVS.   Doing so would be no worse than
keeping a copy of gnuplot.texi in .../docs, which we already do. 
In truth it would be less trouble than gnuplot.texi because changes to
configure.in are less frequent than changes to gnuplot.doc, and any
developer making changes to configure.in must surely have autotools
available whereas at least some of us do not normally have a copy
of Emacs around to regenerate gnuplot.texi every time the doc file 
is changed.

	Ethan

> So unless you lack 
> auto tools, configure shouldn't acquire bit rot like that.
> 
> > Out of curiosity: is there any reason why "configure" script is not
> > included in CVS?
> 
> Because no generated files are supposed to be.  Source control is for 
> holding source files, not generates.
> 
> > but would be easier for the end users.)
> 
> End users are not supposed to be running off CVS directly in the first 
> place.  Those who decide they want to anyway pay a price: they will need 
> some extra tools, and the skills to use them.
> 
> > On the other hand, there are two files,
> >      config/djconfig.sh
> >      missing
> > which are constantly displayed as being present in repository, but
> > they keep changing when I run ./prepare (maybe also on other
> > occasions, for example when running configure or make, I'm not sure).
> >
> > However I checked again and it seems that only executable bit is changed.
> 
> And that's because CVS is lousy at managing the permission bits of 
> working files.  The chmod is the only way we know to make sure you get 
> exactly the permissions you need.
> 
> > In short: I would like to suggest to add "configure" script to
> > repository and/or at least add executable bit to the two files
> > mentioned above.
> 
> If only that were possible in a reliable fashion.
> 
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>