Menu
▾
▴
gnuplot-beta
|
From: Mojca M. <moj...@gm...> - 2011-02-14 09:31:45
|
Dear list,
if I remove MacPorts from PATH (I had to do it since I have serious
problems with AquaTerm), building fails with:
plot.c:110:30: error: readline/tilde.h: No such file or directory
make[3]: *** [plot.o] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
I indeed have no tilde.h except in /opt/local/include/readline/tilde.h
(and in some TeX-related sources). I configured gnuplot with
./configure --disable-wxwidgets --without-latex --without-tutorial
Adding --with-readline=bsd solved compilation, but this should somehow
be solved automatically ...
(I'm testing with version 2011-01-10. If something has changed with
respect to readline after that date, I do apologise. I'll try to test
with the latest version again.)
Mojca
(I will try to solve the problem with AquaTerm with Per Persson.
Something is broken both with in AquaTerm and in gnuplot, but I need
to figure out what can be done on the AquaTerm-side first.)
|
|
From: Ethan M. <merritt@u.washington.edu> - 2011-02-14 16:15:27
|
On Monday, February 14, 2011, Mojca Miklavec wrote: > Dear list, > > if I remove MacPorts from PATH (I had to do it since I have serious > problems with AquaTerm), building fails with: > > plot.c:110:30: error: readline/tilde.h: No such file or directory > make[3]: *** [plot.o] Error 1 > make[2]: *** [all-recursive] Error 1 > make[1]: *** [all-recursive] Error 1 > make: *** [all] Error 2 > > I indeed have no tilde.h except in /opt/local/include/readline/tilde.h > (and in some TeX-related sources). The configure script explicitly tests for the presence of support for tilde expansion in the local readline. Did you re-run ./configure after changing your PATH? |
|
From: Mojca M. <moj...@gm...> - 2011-02-14 16:23:30
|
On Mon, Feb 14, 2011 at 17:15, Ethan Merritt <merritt@u.washington.edu> wrote: > On Monday, February 14, 2011, Mojca Miklavec wrote: >> Dear list, >> >> if I remove MacPorts from PATH (I had to do it since I have serious >> problems with AquaTerm), building fails with: >> >> plot.c:110:30: error: readline/tilde.h: No such file or directory >> make[3]: *** [plot.o] Error 1 >> make[2]: *** [all-recursive] Error 1 >> make[1]: *** [all-recursive] Error 1 >> make: *** [all] Error 2 >> >> I indeed have no tilde.h except in /opt/local/include/readline/tilde.h >> (and in some TeX-related sources). > > The configure script explicitly tests for the presence of support for > tilde expansion in the local readline. Did you re-run ./configure > after changing your PATH? Yes, I did. I tried that again. I did "make clean; ./configure --disable-wxwidgets; make". >From config.log: configure:8168: checking readline/tilde.h usability configure:8168: gcc -c -g -O2 -ObjC conftest.c >&5 conftest.c:133:28: error: readline/tilde.h: No such file or directory configure:8168: $? = 1 Mojca |
|
From: Ethan A M. <sf...@us...> - 2011-02-14 17:14:24
|
On Monday, February 14, 2011 08:23:21 am Mojca Miklavec wrote: > On Mon, Feb 14, 2011 at 17:15, Ethan Merritt <merritt@u.washington.edu> wrote: > > On Monday, February 14, 2011, Mojca Miklavec wrote: > >> Dear list, > >> > >> if I remove MacPorts from PATH (I had to do it since I have serious > >> problems with AquaTerm), building fails with: > >> > >> plot.c:110:30: error: readline/tilde.h: No such file or directory > >> make[3]: *** [plot.o] Error 1 > >> make[2]: *** [all-recursive] Error 1 > >> make[1]: *** [all-recursive] Error 1 > >> make: *** [all] Error 2 > >> > >> I indeed have no tilde.h except in /opt/local/include/readline/tilde.h > >> (and in some TeX-related sources). > > > > The configure script explicitly tests for the presence of support for > > tilde expansion in the local readline. Did you re-run ./configure > > after changing your PATH? > > Yes, I did. I tried that again. I did "make clean; ./configure > --disable-wxwidgets; make". > > From config.log: > > configure:8168: checking readline/tilde.h usability > configure:8168: gcc -c -g -O2 -ObjC conftest.c >&5 > conftest.c:133:28: error: readline/tilde.h: No such file or directory > configure:8168: $? = 1 OK, so then config.h should contain a line #define MISSING_RL_TILDE_EXPANSION 1 If it does not, then I conclude that your system is missing the equivalent of the -*devel*- package for readline. I.e., you still have the library in your path but you do not have the matching header files in your path. On the other hand, I am puzzled by the specific line you show from config.log, because I don't see any check for "readline/tilde.h usability" in the configure script generated from current CVS source for either 4.4 or 4.5. Where did your configure script come from? Ethan |
|
From: Ethan A M. <sf...@us...> - 2011-02-14 18:03:43
|
On Monday, February 14, 2011 09:13:31 am Ethan A Merritt wrote: > On Monday, February 14, 2011 08:23:21 am Mojca Miklavec wrote: > > On Mon, Feb 14, 2011 at 17:15, Ethan Merritt <merritt@u.washington.edu> wrote: > > > On Monday, February 14, 2011, Mojca Miklavec wrote: > > >> Dear list, > > >> > > >> if I remove MacPorts from PATH (I had to do it since I have serious > > >> problems with AquaTerm), building fails with: > > >> > > >> plot.c:110:30: error: readline/tilde.h: No such file or directory > > >> make[3]: *** [plot.o] Error 1 > > >> make[2]: *** [all-recursive] Error 1 > > >> make[1]: *** [all-recursive] Error 1 > > >> make: *** [all] Error 2 > > >> > > >> I indeed have no tilde.h except in /opt/local/include/readline/tilde.h > > >> (and in some TeX-related sources). > > > > > > The configure script explicitly tests for the presence of support for > > > tilde expansion in the local readline. Did you re-run ./configure > > > after changing your PATH? > > > > Yes, I did. I tried that again. I did "make clean; ./configure > > --disable-wxwidgets; make". > > > > From config.log: > > > > configure:8168: checking readline/tilde.h usability > > configure:8168: gcc -c -g -O2 -ObjC conftest.c >&5 > > conftest.c:133:28: error: readline/tilde.h: No such file or directory > > configure:8168: $? = 1 > > OK, so then config.h should contain a line > #define MISSING_RL_TILDE_EXPANSION 1 > > If it does not, then I conclude that your system is missing the > equivalent of the -*devel*- package for readline. I.e., you still have > the library in your path but you do not have the matching header files > in your path. > > On the other hand, I am puzzled by the specific line you show from > config.log, because I don't see any check for "readline/tilde.h usability" > in the configure script generated from current CVS source for either > 4.4 or 4.5. Where did your configure script come from? And indeed, I now see that the test you quote was present in version 4.2 but was replaced by different, more extensive configuration tests in later versions. So I suspect that your configure script is out of date and needs to be regenerated from current source. Ethan |
|
From: Mojca M. <moj...@gm...> - 2011-02-16 10:07:25
|
On Mon, Feb 14, 2011 at 19:01, Ethan A Merritt wrote:
>
>> On the other hand, I am puzzled by the specific line you show from
>> config.log, because I don't see any check for "readline/tilde.h usability"
>> in the configure script generated from current CVS source for either
>> 4.4 or 4.5. Where did your configure script come from?
>
> And indeed, I now see that the test you quote was present in version 4.2
> but was replaced by different, more extensive configuration tests in later
> versions. So I suspect that your configure script is out of date and needs
> to be regenerated from current source.
I'm sorry for the noise. I tried with the latest version (running
./prepare again) and it works fine. It seems that ./configure script
was old indeed (I don't remember any problems recently, but it is true
that I usually compile with macports in PATH where the file is
present).
Out of curiosity: is there any reason why "configure" script is not
included in CVS? (That might mean running "prepare" on regular
basis/when things change of course, but would be easier for the end
users.)
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.
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.
Thank you very much,
Mojca
|
|
From: Hans-Bernhard B. <HBB...@t-...> - 2011-02-16 23:38:22
|
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. > 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. |
|
From: Mojca M. <moj...@gm...> - 2011-02-17 11:19:00
|
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 |
|
From: Andrea D'A. <and...@ma...> - 2011-02-17 12:26:27
|
2011/2/17 Mojca Miklavec <moj...@gm...>: > 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? You would then install the missing tool. -- Andrea |
|
From: Hans-Bernhard B. <HBB...@t-...> - 2011-02-17 21:19:45
|
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. |
|
From: Mojca M. <moj...@gm...> - 2011-02-18 09:13:27
|
2011/2/17 Hans-Bernhard Bröker wrote:
> On 17.02.2011 12:18, Mojca Miklavec wrote:
>
>> 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.
My guess is that when a file becomes executable somebody must have
changed the executable bit on the server (executable bits of new files
that are added to repository match the executable bit of original
file, but if it is changed later on the client side, that change won't
proliferate to server).
I'm not talking about whether it works or not in any given client on
any given OS, but what I observe when I check out CVS is 100%
consistent with what's in original CVS repository (the following files
are from January, not the latest ones, but there is not much
difference):
-rw-rw-r-- 1 user group 23K 11 sep 23:35 README,v
-rw-rw-r-- 1 user group 15K 11 sep 23:35 README.1ST,v
-rw-rw-r-- 1 user group 34K 6 okt 02:52 TODO,v
-rw-rw-r-- 1 user group 5,5K 11 sep 23:35 VERSION,v
drwxrwsr-x 3 user group 102B 17 jan 03:31 beos
drwxrwsr-x 37 user group 1,2K 17 jan 04:55 config
-rwxrwxr-x 1 user group 332K 14 nov 01:06 configure.in,v
-r-xrwxr-x 1 user group 26K 11 sep 23:35 configure.vms,v
drwxrwsr-x 171 user group 5,7K 17 jan 04:55 demo
-r-xrwxr-x 1 user group 19K 11 sep 23:35 depcomp,v
drwxrwsr-x 38 user group 1,3K 17 jan 04:55 docs
-rwxrwxr-x 1 user group 33K 11 sep 23:35 install-sh,v
drwxrwsr-x 20 user group 680B 17 jan 04:54 lisp
drwxrwsr-x 12 user group 408B 17 jan 04:21 m4
drwxrwsr-x 8 user group 272B 17 jan 04:38 man
-rw-rw-r-- 1 user group 35K 11 sep 23:35 missing,v
-rwxrwxr-x 1 user group 16K 11 sep 23:35 mkinstalldirs,v
drwxrwsr-x 3 user group 102B 17 jan 03:22 os2
drwxrwsr-x 7 user group 238B 17 jan 03:57 pm3d
-r-xrwxr-x 1 user group 5,4K 11 sep 23:35 prepare,v
drwxrwsr-x 6 user group 204B 17 jan 04:49 share
drwxrwsr-x 139 user group 4,6K 17 jan 04:56 src
-rw-rw-r-- 1 user group 5,5K 11 sep 23:35 stamp-h.in,v
drwxrwsr-x 86 user group 2,9K 17 jan 04:55 term
drwxrwsr-x 19 user group 646B 17 jan 04:53 tutorial
drwxrwsr-x 3 user group 102B 17 jan 03:51 win
>> configure.in
>
> And guess what: that's wrong. configure.in is not supposed to be
> executable.
But than you need to tell that the server, not the client:
-rwxrwxr-x 1 user group 332K 14 nov 01:06 configure.in,v
The executable bit is present in original repository as well. I guess
that if one changes it on the server, it will also ceise to be
executable on clients. (At least on fresh checkouts ...)
Maybe CVS is not capable of tracking when the executable bit has
changed, but in this particual case I don't think that it really
matters.
Mojca
|
|
From: Hans-Bernhard B. <HBB...@t-...> - 2011-02-18 18:18:58
|
On 18.02.2011 10:13, Mojca Miklavec wrote: > 2011/2/17 Hans-Bernhard Bröker wrote: >> On 17.02.2011 12:18, Mojca Miklavec wrote: >>> 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. > My guess is that when a file becomes executable somebody must have > changed the executable bit on the server (executable bits of new files > that are added to repository match the executable bit of original > file, but if it is changed later on the client side, that change won't > proliferate to server). Well, yes, that's what it's supposed to be like. But unfortunately the story doesn't end there. Files in our CVS have magically changed their 'x' bits several times in the past. And without shell access to the CVS servers, like it used to be on SF.net for most of the past 10 years, that means somebody has to file a support ticket, and somebody from SF.net staff has to do it for us. And we can't even promise them we won't file the same ticket again a week later. > I'm not talking about whether it works or not in any given client on > any given OS, You're missing the point. The problem is that some clients apparently have the capability of breaking this _on the server_, for no particular reason anybody is aware of. |
|
From: Mojca M. <moj...@gm...> - 2011-02-18 09:42:31
|
2011/2/17 Hans-Bernhard Bröker wrote: > On 17.02.2011 12:18, Mojca Miklavec wrote: > >> (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 Since Fri Jul 9 23:27:49 2010 if I see correctly. (I was fighting with compilation back in 2005 or 2006, most of the time on a windows machine and only occasionally using linux.) Mojca PS: I would like suggest to put the same information to INSTALL. |
|
From: Andrea D'A. <and...@ma...> - 2011-02-17 09:02:14
|
On Mon, Feb 14, 2011 at 10:31 AM, Mojca Miklavec <moj...@gm...> wrote: > Dear list, > if I remove MacPorts from PATH (I had to do it since I have serious > problems with AquaTerm), building fails with: Out of curiosity why did you remove mp from PATH? You can still use x11 terminal even with MacPorts' build of gnuplot. Btw I've tried to use macports to build gnuplot with a default x11 terminal and I wasn't able to do that, no matter what the env is, configure manage to set aqua as default terminal. I ended using "set terminal x11" into ~/.gnuplot . -- Andrea |
|
From: Andrea D'A. <and...@ma...> - 2011-02-17 20:57:52
|
2011/2/17 Hans-Bernhard Bröker <HBB...@t-...>: > I rather much doubt that. Setting the variable GNUTERM in the environment > should always work to override the default terminal. See "help > environment". Are you talking about run-time? I'm talking about build time and consequent default value for terminal. -- Andrea |
|
From: Ethan A M. <sf...@us...> - 2011-02-17 21:49:35
|
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
>
|
|
From: Hans-Bernhard B. <HBB...@t-...> - 2011-02-17 23:05:35
|
On 17.02.2011 22:48, Ethan A Merritt wrote: > On Wednesday, February 16, 2011 03:38:13 pm Hans-Bernhard Bröker wrote: >> 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. They're there (see the top-level Makefile, look for am__configure_deps and its uses), but they're disabled. You actually disabled those yourself, Ethan, when you put the AM_MAINTAINER_MODE macro into configure.in. Now people need to run configure with --enable-maintainer-mode to get back those rules, but since neither ./prepare nor any of the README files mentions this fact, just about everybody, including yourself, missed that. IMHO that rather convincingly proves that AM_MAINTAINER_MODE is a bad idea, and I suggest we take back that change. > 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. ... and which routinely gets way out of synch, because 'make' doesn't even build it, so people don't even know they forgot to update it. Which brings us to the key reason why generated files really should never be in CVS: their timestamps get jumbled at checkout/update time, and thus they will get out of synch without the Makefiles getting a chance to notice. As-is, the gnuplot.texi in CVS is basically useless --- it's out of synch most of the time (by 8 revisions, or two months, right now), and even if you decide you want to build it explicitly by cd docs ; make gnuplot.texi there are significant odds that 'make' will claim there's nothing to do even though the file is actually out of date. |
|
From: Ethan A M. <sf...@us...> - 2011-02-17 23:47:43
|
> Hans-Bernhard Br�ker wrote: > On 17.02.2011 22:48, Ethan A Merritt wrote: > > On Wednesday, February 16, 2011 03:38:13 pm Hans-Bernhard Br�ker wrote: > > >> 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. > > They're there (see the top-level Makefile, look for am__configure_deps > and its uses), but they're disabled. You actually disabled those > yourself, Ethan, when you put the AM_MAINTAINER_MODE macro into > configure.in. > > Now people need to run configure with --enable-maintainer-mode to get > back those rules, but since neither ./prepare nor any of the README > files mentions this fact, just about everybody, including yourself, > missed that. IMHO that rather convincingly proves that > AM_MAINTAINER_MODE is a bad idea, and I suggest we take back that change. I myself do not care much one way or the other, but if we remove AM_MAINTAINER_MODE then I predict we will get complaints in the other direction. Right now anyone who has a working configure file can continue to use it even if they don't have autotools installed. If we make "maintainer mode" the default, then these people will be forced to install autotools before they can build from current source. Fine, they can do that. But meanwhile we'll get a stream of complaints/queries/bug-reports that say "I've had no trouble building gnuplot from source in the past, but now all of a sudden it gives me error messages about missing autoconf packages". Ethan |
|
From: Allin C. <cot...@wf...> - 2011-02-18 03:04:05
|
On Thu, 17 Feb 2011, Ethan A Merritt wrote: > > Hans-Bernhard Br�ker wrote: > > On 17.02.2011 22:48, Ethan A Merritt wrote: > > > On Wednesday, February 16, 2011 03:38:13 pm Hans-Bernhard Br�ker wrote: > > > > >> 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. > > > > They're there (see the top-level Makefile, look for am__configure_deps > > and its uses), but they're disabled. You actually disabled those > > yourself, Ethan, when you put the AM_MAINTAINER_MODE macro into > > configure.in. > > > > Now people need to run configure with --enable-maintainer-mode to get > > back those rules, but since neither ./prepare nor any of the README > > files mentions this fact, just about everybody, including yourself, > > missed that. IMHO that rather convincingly proves that > > AM_MAINTAINER_MODE is a bad idea, and I suggest we take back that change. > > I myself do not care much one way or the other, but if we remove > AM_MAINTAINER_MODE then I predict we will get complaints in the other > direction. Right now anyone who has a working configure file can continue > to use it even if they don't have autotools installed. One data-point, FWIW. In my project, gretl.sourceforge.net, we decided to put the configure script into CVS even though (as Hans-Bernhard says) as a generated file it doesn't belong there, strictly speaking. The rationale for this is that given by Ethan: it lowers the bar for people who want to build the latest and greatest from CVS but who are not equipped with autotools. Plus, it's not a very big deal since configure.in changes only rarely. (I don't speak of configure.am since IMO that level of attempted automation is evil.) Allin Cottrell |
