Re: problems with readline (compilation on mac fails)

[Mojca M. <moj...@gm...>]

2011/2/17 Hans-Bernhard Bröker <HBB...@t-...>:
> 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.  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; macports probably
does). I faintly remember that I had problem building from CVS (that
lacks configure scripts) when I tried to compile without MacPorts in
PATH, but I may be wrong.

I can try to reproduce the behaviour if needed, but I'm not sure if
I'm able to figure out what goes wrong. I know that I have generated
configure script a long time ago. I don't know if I ever called
./prepare again (there was no need to up to this moment).

>> 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.

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?

Many people expect ./configure script to be part of the source. (I
spent a great deal of time, if not months, before I figured out that I
had to run the ./prepare script.)

I understand that Makefiles have nothing to do in repository since
they highly depend on local configuration, but it seems that
./configure script is pretty much universal, rarely changes, it would
come in handy (I cannot build gnuplot on bare Mac OS X without
configure script), tracking changes doesn't cost much ...

In this particular case of configure script I consider advantages
would far outweight the drawbacks (like developer forgetting to run
./prepare when commiting some important changes, but that would be
soon discovered and easy to fix).

>> but would be easier for the end users.)
>
> End users are not supposed to be running off CVS directly in the first
> place.

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. (On mac, end users are often not
even supposed to use the Terminal, even when speaking about TeX
users.)

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

> Those who decide they want to anyway pay a price: they will need
> some extra tools, and the skills to use them.

Sure.

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?

>> 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.

CVS is lousy, but it is still capable of managing permission bit. (The
./prepare script consistently has that bit set, I see no reason why
the other two files couldn't have the executable bit set right.)

http://stackoverflow.com/questions/710592/how-do-i-add-execute-permission-to-a-file-in-cvs-after-its-already-been-checked

>> 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.

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

configure.in
configure.vms
depcomp
install-sh
mkinstalldirs
prepare

so I don't see why it would be such a problem to also set it on the
two other files.

prepare script says

exelist="configure configure.vms depcomp install-sh missing
mkinstalldirs config/djconfig.sh lisp/configure"
chmod 755 $exelist >/dev/null 2>&1

I'm not saying that those two lines should go away, only that it would
be nice to set the bit to the remaining two files.

Mojca