Menu
▾
▴
gnuplot-beta
|
From: Ethan A M. <sf...@us...> - 2012-09-17 23:12:10
|
The NEWS file lists 30 bug fixes that have accummulated since the release of version 4.6. That is more than is usual between incremental releases. Is anyone aware of an unresolved bug or other reason to hold off release of version 4.6.1? If not, I will probably package it up for release next weekend. Ethan |
|
From: Daniel J S. <dan...@ie...> - 2012-09-18 06:22:20
|
On 09/17/2012 06:08 PM, Ethan A Merritt wrote: > The NEWS file lists 30 bug fixes that have accummulated since the > release of version 4.6. That is more than is usual between > incremental releases. > > Is anyone aware of an unresolved bug or other reason to hold off > release of version 4.6.1? If not, I will probably package it up > for release next weekend. Is Qt terminal in 4.6.1? The only thing I can think of is supporting Windows properly in Qt term, but no volunteers with a Windows machine have stepped forward yet. Oh well. Dan > > Ethan > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > -- Dan Sebald email: daniel(DOT)sebald(AT)ieee(DOT)org URL: http://www(DOT)dansebald(DOT)com |
|
From: Ethan A M. <sf...@us...> - 2012-09-18 18:51:54
|
> On Monday, September 17, 2012 04:08:25 pm Ethan A Merritt wrote: > > Is anyone aware of an unresolved bug or other reason to hold off > > release of version 4.6.1? If not, I will probably package it up > > for release next weekend. > === qt === > Daniel J Sebald <dan...@ie...> > Is Qt terminal in 4.6.1? The only thing I can think of is supporting > Windows properly in Qt term, but no volunteers with a Windows machine > have stepped forward yet. Qt was already added in 4.6.0. 4.6.1 will contain a few already-applied patches related to installation on OSX. === emacs === > Mojca Miklavec <moj...@gm...> > Not a major showstopper, but I would be grateful if someone could take > a look at the attached patch for emacs (and apply before the release > it if possible). The problem is that setting > EMACS=/path/to/some/Emacs ./configure > is later "reset" with > EMACS=`basename $EMACS` > in lisp/configure[.in], so version checking and all further > emacs-related operation fail to work properly since they call whatever > emacs/xemacs comes first in PATH instead of the one requested by user. I am very reluctant to make changes to the configuration system for 4.6.1 that have not previously been tested in the development tree. That said, I am willing to have a look at this if you can you clarify what the problem actually is. Which of these is happening? 1) you have an "emacs" in your path that is incapable of compiling the three files gnuplot.elc gnuplot-gui.elc gnuplot-eldoc.elc? 2) The version check to see if emacs is older than version 20.3 fails? 3) The *.elc files are compiled properly but installed in the wrong site-lisp directory? As to (2) is any of this still needed? The README says that the info-look.xxx files are a work-around for incompatibilities in ancient versions of emacs and Xemacs. Can we just get rid of these files and get rid of that section of the Makefile? === Aquaterm === > Mojca Miklavec <moj...@gm...> > I would be very very grateful if this patch could be applied: > http://trac.macports.org/browser/trunk/dports/math/gnuplot/files/patch-configure-aquaterm.diff?rev=96897 > (only "configure.in", "m4/apple.m4" and the first line of "term/aquaterm.trm") > --- configure.in.orig > +++ configure.in > @@ -1366,5 +1366,5 @@ > > -if test "$ac_cv_lib_aquaterm_aqtInit" = yes; then > +if test "$with_aquaterm" = yes; then > AC_MSG_RESULT([ aqua terminal: yes]) > else > AC_MSG_RESULT([ aqua terminal: no]) That change is not in the main branch. Are you sure it is needed? > m4/apple.m4 This patch bears little resemblance to what is currently in 4.7. Does the build system in 4.7 work, or not? If the 4.7 version does work, should I just copy it to 4.6? If not, then please submit a patch against 4.7 rather than 4.6 and we'll work from there. > term/aquaterm.trm > --- term/aquaterm.trm.orig > +++ term/aquaterm.trm > @@ -94,3 +94,3 @@ > #ifdef TERM_BODY > -#import <aquaterm/AQTAdapter.h> > +#import <AquaTerm/AQTAdapter.h> OK. === BOOLEANS === > Mojca Miklavec <moj...@gm...> > Definitions of BOOL are still problematic (and configuration is broken > on Solaris, older Macs, ...). My understanding of the situation on Solaris is that no single fix will work for all versions of Solaris. The versions differ from each other, and the requirements for C++ reportedly conflict with those for C. But I'm working from ignorance, relying on Solaris users to provide help. I have 2 (3?) times previously applied patches that were submitted to handle Bool on some version of Solaris, and each time people reported that the change caused breakage on other systems. So unless someone has a patch that has been well tested on multiple versions of Solaris, I won't touch this. It is of course unfortunate that the Solaris compilers have a problem with standard C/C++ Booleans. It is likewise unfortunate that MSVC isn't ANSI-compliant with regard to initializing named fields in a structure, and unfortunate that some platforms lack a usable version of snprintf(). We do try to accommodate in the source code where possible, but at some point it's just not worth the effort. Anyhow, this is clearly a long-term issue and not something that can quickly be patched for 4.6.1. Ethan |
|
From: Mojca M. <moj...@gm...> - 2012-09-18 23:29:55
|
On Tue, Sep 18, 2012 at 8:48 PM, Ethan A Merritt wrote:
>
> === emacs ===
>> Mojca Miklavec <moj...@gm...>
>> Not a major showstopper, but I would be grateful if someone could take
>> a look at the attached patch for emacs (and apply before the release
>> it if possible). The problem is that setting
>> EMACS=/path/to/some/Emacs ./configure
>> is later "reset" with
>> EMACS=`basename $EMACS`
>> in lisp/configure[.in], so version checking and all further
>> emacs-related operation fail to work properly since they call whatever
>> emacs/xemacs comes first in PATH instead of the one requested by user.
>
> I am very reluctant to make changes to the configuration system for 4.6.1
> that have not previously been tested in the development tree.
> That said, I am willing to have a look at this if you can you clarify
> what the problem actually is.
To understand the problem better please try the following
ln -s /usr/bin/emacs /tmp/myemacs
EMACS=/tmp/myemacs ./configure
> Which of these is happening?
>
> 1) you have an "emacs" in your path that is incapable of compiling the
> three files gnuplot.elc gnuplot-gui.elc gnuplot-eldoc.elc?
> 2) The version check to see if emacs is older than version 20.3 fails?
> 3) The *.elc files are compiled properly but installed in the wrong
> site-lisp directory?
In my case none of the above. But two other things go wrong:
1.) The code
if test "$EMACS" = emacs ; then
doesn't recognize uppercase "Emacs". There's nothing wrong with that
since I'm not interested in the patch anyway, but the "else" part
doesn't reset
INFO_LOOK_ELC=
so after
EMACS=/Applications/Emacs.app/Contents/MacOS/Emacs
../gnuplot/configure && make
I end up with
Wrote /tmp/gnuplot-build/lisp/gnuplot.elc
Emacs -batch -q -no-site-file -l ../../gnuplot/lisp/dot.el -f
batch-byte-compile gnuplot-gui.el
Wrote /tmp/gnuplot-build/lisp/gnuplot-gui.elc
make[2]: *** No rule to make target `info-look.elc', needed by `elcs'. Stop.
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
2.) Version checking is either done with the wrong EMACS binary, or
not at all (if that binary is not the first one with the same name in
path). Gnuplot first accepts user's explicit request to use a specific
binary like
/Applications/Emacs.app/Contents/MacOS/Emacs
in my case, but then tries to call
Emacs --version
which either uses /usr/bin/emacs or /opt/local/bin/emacs (a different
binary) from PATH or completely fails in case of case sensitive file
systems. In the example I suggested above compilation breaks with
./doc2gih ../../gnuplot/docs/gnuplot.doc gnuplot.gih
Making all in lisp
myemacs -batch -q -no-site-file -l ../../gnuplot/lisp/dot.el -f
batch-byte-compile gnuplot.el
make[2]: myemacs: No such file or directory
make[2]: *** [gnuplot.elc] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
> As to (2) is any of this still needed? The README says that the
> info-look.xxx files are a work-around for incompatibilities in ancient
> versions of emacs and Xemacs. Can we just get rid of these files and
> get rid of that section of the Makefile?
(I wanted to suggest that, but didn't dare to.)
Mojca
|
|
From: Mojca M. <moj...@gm...> - 2012-09-18 23:57:18
Attachments:
aquaterm.patch
apple.m4
|
On Tue, Sep 18, 2012 at 8:48 PM, Ethan A Merritt wrote: > > === Aquaterm === >> Mojca Miklavec <moj...@gm...> >> I would be very very grateful if this patch could be applied: >> http://trac.macports.org/browser/trunk/dports/math/gnuplot/files/patch-configure-aquaterm.diff?rev=96897 >> (only "configure.in", "m4/apple.m4" and the first line of "term/aquaterm.trm") >> --- configure.in.orig >> +++ configure.in >> @@ -1366,5 +1366,5 @@ >> >> -if test "$ac_cv_lib_aquaterm_aqtInit" = yes; then >> +if test "$with_aquaterm" = yes; then >> AC_MSG_RESULT([ aqua terminal: yes]) >> else >> AC_MSG_RESULT([ aqua terminal: no]) > > That change is not in the main branch. Are you sure it is needed? The main branch has not been patched either. (This patch is only valid [and required] iff new m4/apple.m4 is included.) >> m4/apple.m4 > This patch bears little resemblance to what is currently in 4.7. That patch was against 4.6.0. I'm attaching apple.m4 just in case. > Does the build system in 4.7 work, or not? Not without extra fiddling of the system. > If the 4.7 version does work, should I just copy it to 4.6? > If not, then please submit a patch against 4.7 rather than 4.6 > and we'll work from there. Attached. >> term/aquaterm.trm >> --- term/aquaterm.trm.orig >> +++ term/aquaterm.trm >> @@ -94,3 +94,3 @@ >> #ifdef TERM_BODY >> -#import <aquaterm/AQTAdapter.h> >> +#import <AquaTerm/AQTAdapter.h> > > OK. The same holds here: this should only be included iff the m4/apple.m4 is patched at the same time. Mojca |
|
From: Mojca M. <moj...@gm...> - 2012-09-19 00:24:21
|
On Tue, Sep 18, 2012 at 8:48 PM, Ethan A Merritt wrote:
>
> === BOOLEANS ===
>> Mojca Miklavec <moj...@gm...>
>> Definitions of BOOL are still problematic (and configuration is broken
>> on Solaris, older Macs, ...).
>
> My understanding of the situation on Solaris is that no single fix will
> work for all versions of Solaris.
I admit that I don't know enough of Solaris, but the current approach with
#if defined(__SUNPRO_CC)
and so on (possibly for every single compiler on the planet) is
somewhat doomed to fail.
The problematic code is not the solaris-specific one, but the whole
block in src/syscfg.h starting with #if HAVE_STDBOOL_H.
The reason why 99.9% users don't notice any problem is because of this chunk:
#if HAVE_STDBOOL_H
# include <stdbool.h> /* this part is OK and covers 99% users */
#else
/* here is where it gets problematic/wrong; it works/workeded only
until C++ code has been added ... */
#fi
Most users never see the problematic else part. In principle that part
should work for everyone (even thouse with HAVE_STDBOOL_H defined to
true), but currently that is not the case.
> The versions differ from each other,
> and the requirements for C++ reportedly conflict with those for C.
True. The main problem is that one can have _Bool and the other one
not. Actually, there is no reason why C++ would need a "_Bool" type if
it already has "bool". So most of the time it's only a question of
whether _Bool is defined in C. But the conditional behaves as if _Bool
either has to be defined in both C/C++ or in none of them, and then
tries to do
# define bool _Bool
in C++, that is: break a previously working "bool" by redefining it to
a nonexistent "_Bool".
> But I'm working from ignorance, relying on Solaris users to provide help.
> I have 2 (3?) times previously applied patches that were submitted to
> handle Bool on some version of Solaris, and each time people reported
> that the change caused breakage on other systems. So unless someone has
> a patch that has been well tested on multiple versions of Solaris,
> I won't touch this.
Why not trusting developers of gnulib with a wide user base and their
code being used on most exotic system?
Or simply use the most trivial code that works?
My guess would be that the following should work (or at least cover 9
out of 10 currently problematic cases):
#if HAVE_STDBOOL_H
# include <stdbool.h>
#else
# ifndef __cplusplus
# if ! HAVE__BOOL
typedef unsigned char _Bool;
# endif
# define bool _Bool
# define false 0
# define true 1
# endif
#endif
but then again, taking code from gnulib should be a much better tested
solution. (If any system lacks "bool" in C++, the code above won't
cover that.)
> It is of course unfortunate that the Solaris compilers have a problem
> with standard C/C++ Booleans. It is likewise unfortunate that MSVC isn't
> ANSI-compliant with regard to initializing named fields in a structure,
> and unfortunate that some platforms lack a usable version of snprintf().
> We do try to accommodate in the source code where possible, but at some
> point it's just not worth the effort.
>
> Anyhow, this is clearly a long-term issue and not something that can
> quickly be patched for 4.6.1.
Given the broad number of exotic software where this needs to be tested ...
I agree, putting a patch into trunk might actually be a safer bet.
Mojca
PS: current code from gnulib, with comments stripped off:
#if defined __BEOS__ && !defined __HAIKU__
# include <OS.h> /* defines bool but not _Bool */
# undef false
# undef true
#endif
#ifdef __cplusplus
# define _Bool bool
# define bool bool
#else
# if defined __BEOS__ && !defined __HAIKU__
# if !HAVE__BOOL
typedef bool _Bool;
# endif
# else
# if !defined __GNUC__
# define _Bool signed char
# else
# if !HAVE__BOOL
typedef enum { _Bool_must_promote_to_int = -1, false = 0, true = 1 } _Bool;
# endif
# endif
# endif
# define bool _Bool
#endif
#ifdef __cplusplus
# define false false
# define true true
#else
# define false 0
# define true 1
#endif
#define __bool_true_false_are_defined 1
|
|
From: Mojca M. <moj...@gm...> - 2012-09-22 07:02:16
|
On Tue, Sep 18, 2012 at 8:48 PM, Ethan A Merritt wrote:
>
> === emacs ===
>> Mojca Miklavec <moj...@gm...>
>> Not a major showstopper, but I would be grateful if someone could take
>> a look at the attached patch for emacs (and apply before the release
>> it if possible). The problem is that setting
>> EMACS=/path/to/some/Emacs ./configure
>> is later "reset" with
>> EMACS=`basename $EMACS`
>> in lisp/configure[.in], so version checking and all further
>> emacs-related operation fail to work properly since they call whatever
>> emacs/xemacs comes first in PATH instead of the one requested by user.
>
> I am very reluctant to make changes to the configuration system for 4.6.1
> that have not previously been tested in the development tree.
> That said, I am willing to have a look at this if you can you clarify
> what the problem actually is.
>
> Which of these is happening?
> 1) you have an "emacs" in your path that is incapable of compiling the
> three files gnuplot.elc gnuplot-gui.elc gnuplot-eldoc.elc?
> 2) The version check to see if emacs is older than version 20.3 fails?
> 3) The *.elc files are compiled properly but installed in the wrong
> site-lisp directory?
>
> As to (2) is any of this still needed? The README says that the
> info-look.xxx files are a work-around for incompatibilities in ancient
> versions of emacs and Xemacs. Can we just get rid of these files and
> get rid of that section of the Makefile?
I'm very grateful for removing that ancient portion of code from
lisp/configure.in, however the
EMACS=`basename $EMACS`
line is still causing problems (both in trunk and in branch-4-6-stable).
Can someone else please test if the following works or fails for you?
# provided that /usr/bin/emacs is a valid emacs binary
ln -s /usr/bin/emacs /tmp/myemacs
which myemacs
# should not return anything
cd /path/to/gnuplot
EMACS=/tmp/myemacs ./configure
make
For me it fails with:
./doc2gih ../../original/docs/gnuplot.doc gnuplot.gih
Making all in lisp
myemacs -batch -q -no-site-file -l ../../original/lisp/dot.el -f
batch-byte-compile gnuplot.el
make[2]: myemacs: No such file or directory
make[2]: *** [gnuplot.elc] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
And the following trivial patch solves the issue:
--- a/lisp/configure.in
+++ b/lisp/configure.in
@@ -13,8 +13,6 @@ AC_SET_MAKE
AC_PROG_INSTALL
AM_PATH_LISPDIR
-EMACS=`basename $EMACS`
-
AC_CHECK_PROGS(DVIPS, dvips, no)
AC_CHECK_PROGS(LATEX, latex latex2e, no)
AC_PATH_PROG(MAKEINFO, makeinfo, no)
Is this only a problem on my machine or are others able to reproduce
the problem?
(The line used to be used until recently to be able to compare if
$EMACS equals to "emacs" or "xemacs", but those lines have gone, so I
don't see any good reason to keep that line any more.)
Thank you very much,
Mojca
PS: I know that calling emacs "myemacs" might seems like an imaginary
problem, but it is a real problem on Mac OS X where (the desired)
EMACS binary is often not in PATH and it is called "Emacs", with
uppercase, and it either fails completely or uses the wrong binary.
This is just a simple minimal example which should demonstrate the
problem on systems other than Mac.
|
|
From: sfeam (E. Merritt) <eam...@gm...> - 2012-09-22 22:09:24
|
On Thursday, 20 September 2012, Mojca Miklavec wrote: > On Thu, Sep 20, 2012 at 6:58 PM, Ethan Merritt wrote: > > On Thu, Sep 20, 2012 at 4:34 AM, Mojca Miklavec > > <moj...@gm...> wrote: > >> The problem is that files > >> docs/gnuplot-eldoc.el > >> docs/gnuplot-eldoc.elc > >> docs/gnuplot.texi > >> are generated inside sources instead of being generated in the > >> directory where configure script is run (when doing out-of-source > >> build). This seems to be a bug in Makefile.in. The files gnuplot.elc > >> and gnuplot-gui.elc are installed properly (generated in the proper > >> place). The gnuplot-eldoc.el[c] is not. > >> > >> Mojca > > > > I can't reproduce that under any set of conditions: > > 1) normal emacs - check > > 2) no emacs - check > > 3) renamed emacs - check > > > > Are you building/installing directly from the CVS tree or are you > > creating a distribution tarball and testing that? > > I'm building directly from the CVS tree (branch-4-6-stable), but I'm > doing an *out of source* configure/make. > > Here would be the exact rules to reproduce the error: > > ~> mkdir gnuplot && cd gnuplot > ~/gnuplot> mkdir sources > ~/gnuplot> mkdir build > ~/gnuplot> cd sources > ~/gnuplot/sources> <checkout here> > ~/gnuplot/sources> ./prepare > ~/gnuplot/sources> cd ../build > ~/gnuplot/build> ../sources/configure --prefix=$PWD/install > ~/gnuplot/build> make > ~/gnuplot/build> make install # this fails After fighting with this all day yesterday, I decided to instead backport the emacs+info related Makefile scripting from 4.7 to 4.6. Please let me know whether the modified .../docs/Makefile.in from today's CVS resolves your out-of-source build problems. Ethan |
|
From: Mojca M. <moj...@gm...> - 2012-09-23 00:42:18
|
On Sun, Sep 23, 2012 at 12:09 AM, sfeam (Ethan Merritt) wrote:
>
> After fighting with this all day yesterday, I decided to instead
> backport the emacs+info related Makefile scripting from 4.7 to 4.6.
> Please let me know whether the modified .../docs/Makefile.in
> from today's CVS resolves your out-of-source build problems.
Thank you very much.
The "make" phase seems to work without any problems (including usage
of obscure emacs, but only in branch 4.6, not yet in trunk), but the
"make install" fails here:
Making install in docs
../../original/mkinstalldirs
/Users/m/gnuplot/build-original/inst/share/gnuplot/4.6
/opt/local/bin/ginstall -c -m 644 gnuplot.gih
/Users/m/gnuplot/build-original/inst/share/gnuplot/4.6/gnuplot.gih
make[1]: *** No rule to make target
`../../original/docs/gnuplot.texi', needed by `gnuplot.info'. Stop.
make: *** [install-recursive] Error 1
I first naively tried adding $(srcdir) in front of gnuplot.texi:
--- a/docs/Makefile.in
+++ b/docs/Makefile.in
@@ -393,7 +393,7 @@ gnuplot.info: $(srcdir)/gnuplot.texi
$(MAKEINFO) -I$(srcdir) $(srcdir)/gnuplot.texi --no-split --output=$@
# Thanks to Bruce Ravel for doc2texi.el!
-gnuplot.texi $(srcdir)/gnuplot-eldoc.el $(srcdir)/gnuplot-eldoc.elc:
$(srcdir)/doc2texi.el $(srcdir)/gnuplot.doc
+$(srcdir)/gnuplot.texi $(srcdir)/gnuplot-eldoc.el
$(srcdir)/gnuplot-eldoc.elc: $(srcdir)/doc2texi.el
$(srcdir)/gnuplot.doc
@echo "Creating texinfo and eldoc strings file"
@if test "$(EMACS)" != no; then \
@test "$(top_srcdir)" = "$(top_builddir)" || echo "COPYING
GNUPLOT.DOC" ; \
which made the "make install" proceed a lot further. In particular,
the same chunk proceeded with
Making install in docs
../../original/mkinstalldirs
/Users/m/gnuplot/build-original/inst/share/gnuplot/4.6
/opt/local/bin/ginstall -c -m 644 gnuplot.gih
/Users/m/gnuplot/build-original/inst/share/gnuplot/4.6/gnuplot.gih
Creating texinfo and eldoc strings file
/bin/sh: @test: command not found
COPYING GNUPLOT.DOC
/bin/sh: @test: command not found
Loading /opt/local/share/emacs/site-lisp/subdirs.el (source)...
Inserting help for terminals ...
Analyzing doc file ...
Converting to texinfo ...
Menus, nodes, xrefs ...
Loading texinfo...
Making texinfo nodes ...
(I pasted this portion because I wasn't sure if "@test: command not
found" was something to be expected or not.)
But then it failed at
Updated level "3" menu following node: Bugs ...
Making or updating menus in *doc2texi*...done
Done...updated all the menus. You may save the buffer.
Saving file /Users/m/gnuplot/build-original/docs/gnuplot.texi...
Wrote /Users/m/gnuplot/build-original/docs/gnuplot.texi
Compiling gnuplot-eldoc.el
Loading /opt/local/share/emacs/site-lisp/subdirs.el (source)...
Wrote /Users/m/gnuplot/build-original/docs/gnuplot-eldoc.elc
/bin/sh /Users/m/gnuplot/original/missing --run makeinfo
-I../../original/docs ../../original/docs/gnuplot.texi --no-split
--output=gnuplot.info
../../original/docs/gnuplot.texi: No such file or directory
make[1]: *** [gnuplot.info] Error 1
make: *** [install-recursive] Error 1
I was able to fix this by replacing
$(MAKEINFO) -I$(srcdir) $(srcdir)/gnuplot.texi --no-split --output=$@
with
$(MAKEINFO) -I$(srcdir) gnuplot.texi --no-split --output=$@
The problem was that gnuplot.texi was only inside build/docs/, not
inside sources.
All in all, the following patch solved the problem for me (the first
part is commented out and I didn't test anything there):
--- a/docs/Makefile.in
+++ b/docs/Makefile.in
@@ -237,8 +237,8 @@ doc2ms.o: doc2ms.c $(BUILT_SOURCES)
html: htmldocs/gnuplot.html
# requires makeinfo (GNU texinfo) 4.0 or better
-# htmldocs/gnuplot.html: $(srcdir)/gnuplot.texi
-# $(MAKEINFO) --html -I$(srcdir) $(srcdir)/gnuplot.texi --no-split --output=$@
+# htmldocs/gnuplot.html: gnuplot.texi
+# $(MAKEINFO) --html -I$(srcdir) gnuplot.texi --no-split --output=$@
# requires a working latex2html, which is hard to find these days
# htmldocs/gnuplot.html: $(srcdir)/gnuplot.tex
@@ -389,8 +389,8 @@ wxhelp/doc2html: wxhelp/doc2html.o termdoc.o
xref.o ../src/version.o
### GNU info format
info: gnuplot.info
-gnuplot.info: $(srcdir)/gnuplot.texi
- $(MAKEINFO) -I$(srcdir) $(srcdir)/gnuplot.texi --no-split --output=$@
+gnuplot.info: gnuplot.texi
+ $(MAKEINFO) -I$(srcdir) gnuplot.texi --no-split --output=$@
# Thanks to Bruce Ravel for doc2texi.el!
gnuplot.texi $(srcdir)/gnuplot-eldoc.el $(srcdir)/gnuplot-eldoc.elc:
$(srcdir)/doc2texi.el $(srcdir)/gnuplot.doc
But the patch might need a second pair of eyes to confirm that it
actually makes sense.
Mojca
PS: gnuplot then crashed during distcheck, but that might be a problem
of underlying libraries, and in any case completely unrelated:
(process:9196): Pango-CRITICAL **: void
pango_fontset_foreach(PangoFontset *, PangoFontsetForeachFunc,
gpointer): assertion `PANGO_IS_FONTSET (fontset)' failed
(process:9196): Pango-WARNING **: failed to choose a font, expect ugly
output. engine-type='PangoRenderCoreText', script='common'
(process:9196): GLib-GObject-CRITICAL **: g_object_ref: assertion
`G_IS_OBJECT (object)' failed
(process:9196): Pango-WARNING **: couldn't load font "frscript
Not-Rotated 400", modified variant/weight/stretch as fallback, expect
ugly output.
(process:9196): GLib-GObject-CRITICAL **: g_object_ref: assertion
`G_IS_OBJECT (object)' failed
(process:9196): Pango-ERROR **: Could not load fallback font, bailing out.
/bin/sh: line 1: 9196 Trace/BPT trap: 5 PATH=$bdir/../src:$PATH
GNUPLOT_DRIVER_DIR=$bdir/../src GNUPLOT_LIB=../../demo gnuplot all.dem
< /dev/null
make[3]: *** [check-noninteractive] Error 133
make[2]: *** [check-am] Error 2
make[1]: *** [check-recursive] Error 1
make: *** [distcheck] Error 1
|
|
From: Mojca M. <moj...@gm...> - 2012-09-24 13:37:34
Attachments:
texi.patch
|
On Sun, Sep 23, 2012 at 4:35 AM, sfeam (Ethan Merritt) wrote: > >> Making install in docs >> ../../original/mkinstalldirs >> /Users/m/gnuplot/build-original/inst/share/gnuplot/4.6 >> /opt/local/bin/ginstall -c -m 644 gnuplot.gih >> /Users/m/gnuplot/build-original/inst/share/gnuplot/4.6/gnuplot.gih >> make[1]: *** No rule to make target >> `../../original/docs/gnuplot.texi', needed by `gnuplot.info'. Stop. >> make: *** [install-recursive] Error 1 > > Ah, but here I think you are seeing a difference of building from > CVS vs. building from the distribution tarball. The distribution > tarball explicitly contains an up-to-date copy of gnuplot.texi, so > it doesn't need to be rebuilt and this make rule is not needed. > > Try doing "make gnuplot.texi" manually before your subsequent testing, > which should reproduce the state saved in the tarball. It doesn't help. I can only run "make gnuplot.texi" in build tree (I cannot run it in source tree when doing an out of source build). The file *is* generated, already now. The problem is that Makefile declares dependency on gnuplot.texi being present in $(srcdir) and there is no way that the file can end up there unless it comes as precompiled in distribution. What about trying to copy the file explicitly if already present (in the same way as 'gnuplot.doc')? @@ -389,18 +389,20 @@ wxhelp/doc2html: wxhelp/doc2html.o termdoc.o xref.o ../src/version.o ### GNU info format info: gnuplot.info -gnuplot.info: $(srcdir)/gnuplot.texi - $(MAKEINFO) -I$(srcdir) $(srcdir)/gnuplot.texi --no-split --output=$@ +gnuplot.info: gnuplot.texi + $(MAKEINFO) -I$(srcdir) gnuplot.texi --no-split --output=$@ # Thanks to Bruce Ravel for doc2texi.el! gnuplot.texi $(srcdir)/gnuplot-eldoc.el $(srcdir)/gnuplot-eldoc.elc: $(srcdir)/doc2texi.el $(srcdir)/gnuplot.doc @echo "Creating texinfo and eldoc strings file" @if test "$(EMACS)" != no; then \ - @test "$(top_srcdir)" = "$(top_builddir)" || echo "COPYING GNUPLOT.DOC" ; \ - @test "$(top_srcdir)" = "$(top_builddir)" || cp $(srcdir)/gnuplot.doc . ; \ + test "$(top_srcdir)" = "$(top_builddir)" || echo "COPYING GNUPLOT.DOC" ; \ + test "$(top_srcdir)" = "$(top_builddir)" || cp $(srcdir)/gnuplot.doc . ; \ $(EMACS) -batch -l $(srcdir)/doc2texi.el -f d2t-doc-to-texi ; \ echo "Compiling gnuplot-eldoc.el" ; \ $(EMACS) -batch --eval='(byte-compile-file "gnuplot-eldoc.el")' ; \ + elif [ "$(top_srcdir)" != "$(top_builddir)" ] && [ -f $(srcdir)/gnuplot.texi ]; then \ + cp $(srcdir)/gnuplot.texi . ; \ else \ echo "No emacs found - cannot create texinfo file" ; \ fi I didn't test this patch extensively yet - I would first like to know if the idea would be acceptable. Mojca |
