Re: problems with readline (compilation on mac fails)

[Hans-Bernhard B. <HBB...@t-...>]

On 17.02.2011 12:18, Mojca Miklavec wrote:
> 2011/2/17 Hans-Bernhard Bröker<HBB...@t-...>:

>> So unless you lack auto tools, configure shouldn't acquire bit rot
>> like that.

> I don't know what exactly was wrong. But the fact that I excluded
> MacPorts from PATH might explain the situation (I don't know if bare
> Mac OS X comes with the right version of autotools;

It almost certainly doesn't come with any autotools at all.

> macports probably does).


> I understand that it makes little sense to save a new version of
> gnuplot binary, several MB, each time when a single line changes. But
> ... isn't "configure" something that resembles source much better than
> it resembles binary?

It's not an issue of binary vs. source.  It's a question of a file that 
is made from some source code, as opposed to a file that's source code 
itself.

> Many people expect ./configure script to be part of the source.

People have all kinds of strange expectations.  That doesn't make them 
correct.

> (I spent a great deal of time, if not months, before I figured out
> that I had to run the ./prepare script.)

Impressive.  That information is right there in line 9 of README.1ST. :-O

> But who is supposed to be end user on Mac OS X? End users are not
> supposed to compile source in the first place, however gnuplot doesn't
> even ship binaries for mac. Ever.

You're wrong about that.  We did ship binaries of quite a few versions. 
  But without anyone on the team equipped with the tools and skills to 
build gnuplot binaries, we can't generate, much less ship any.

> And you probably do want some beta testers (even if they are not
> experts in autotools)?

You're jumping to conclusions.  You don't need to be an expert in 
autotools just to run them.

> But just as example: what am I supposed to do if my system comes with
> all the tools I need to build gnuplot, except for the tools to create
> a configure file. Am I disqualified for beta testing just because of
> that?

Only if you disqualify yourself by refusing to install those tools.

> CVS is lousy, but it is still capable of managing permission bit.

Not really.  Not with developers using CVS clients of wildly different 
version, on wildly different platforms, without direct shell access to 
files on the CVS server.  Trust me, we've been there.  In the long run 
it just doesn't work.

The problem is CVS doesn't actually _manage_ the permissions at all: the 
state of those bits is not part of the state recorded per revision. 
What you get is some of the permission bits of the archive duplicated 
into those of the working file.  Setting aside the obvious problems with 
having to flag archive files executable even though they aren't, that's 
not managing --- that's a stopgap at best.


> But all the following files (in root tree) do have the executable bit set:

... by luck, as of today.  That can change any time, without anybody 
quite knowing why.

> configure.in

And guess what: that's wrong.  configure.in is not supposed to be 
executable.