gnuplot-beta — Developers and beta testers of new gnuplot code

Segmentation core dump in fillbetween.dem due to "%lf %lf %lf"

[Daniel J S. <dan...@ie...>]

I'm seeing a core dump in one of the demos, fillbetween.dem:

	G N U P L O T
	Version 4.7 patchlevel 0    last modified 2012-06-19

	Copyright (C) 1986-1993, 1998, 2004, 2007-2012
	Thomas Williams, Colin Kelley and many others

	gnuplot home:     http://www.gnuplot.info
	mailing list:     gnu...@li...
	faq, bugs, etc:   type "help FAQ"
	immediate help:   type "help"  (plot window: hit 'h')

Terminal type set to 'qt'
gnuplot> set title "Fill area between two curves"
gnuplot> set style data lines
gnuplot> set xrange [10:*]
gnuplot> set yrange [0:175]
gnuplot> plot 'silver.dat' u 1:2:3 "%lf %lf %lf" w filledcu, \
>      '' u 1:2 lt -1 notitle, '' u 1:3 lt -1 notitle
Segmentation fault (core dumped)


Removing the "%lf %lf %lf" format specifier fixes the problem:

Terminal type set to 'qt'
gnuplot> set title "Fill area between two curves"
gnuplot> set style data lines
gnuplot> set xrange [10:*]
gnuplot> set yrange [0:175]
gnuplot> plot 'silver.dat' u 1:2:3  w filledcu, \
>     '' u 1:2 lt -1 notitle, '' u 1:3 lt -1 notitle


I think the problem is a recent change:

http://gnuplot.cvs.sourceforge.net/viewvc/gnuplot/gnuplot/src/datafile.c?r1=1.260&r2=1.261

I looks like there are some tricky string writes and memory frees.  This 
line looks suspicious:

      snprintf(placeholder+11, 4, "%02d@", column_for_key_title);

if

static char placeholder[] = "@COLUMNHEAD00@";

Adding 11 to the placeholder pointer puts the pointer at the first 0 of 
"...00@".  If I'm not mistaken, %02d means a minimum of 2 digits so it 
could be more than 2 digits wide.  If it is more than two digits wide, 
then either the @ or some other numeral is in the fourth position and 
will overwrite the null terminating string and memory could be accessed 
outside of a segment from a run-away string.  It should be

      snprintf(placeholder+11, 3, "%02d@", column_for_key_title);

but if one wants to ensure that an at-symbol @ appears at the end of the 
string and there is adequate space for a large number, then some other 
strategy is needed.

Could be in clearing the headers, on the other hand.

Dan

Re: Automatically keeping "last modified" up to date

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

On 07.08.2013 19:49, sfeam (Ethan Merritt) wrote:

> How about changing version.c to something like
>
> #ifndef LAST_MODIFIED
> #define LAST_MODIFIED "2012-06-19"
> #endif
> const char gnuplot_date[] = LAST_MODIFIED;
>
> And then using some autotools magic that I would have to hunt for
> do something along the lines of

It would have to be different magic, I'm afraid.  Autotools isn't run at 
the point in time that counts: a simple re-make of an already configured 
source tree.

> LAST_MODIFIED = <some magic involving awk or grep>
> DEFS = $DEFS -DLAST_MODIFIED=${LAST_MODIFIED}

> That should reproduce the current behavior without modifying
> any source files.

Not quite.  Changes to non-source files (like the Makefile) don't 
trigger re-builds of version.o.  There has to be some artificial 
dependence of version.o on ChangeLog added to the generated Makefile.

Re: Automatically keeping "last modified" up to date

[sfeam (E. Merritt) <eam...@gm...>]

On Wednesday, 07 August 2013, Hans-Bernhard Bröker wrote:
> On 07.08.2013 10:53, Lars Hecking wrote:
> >   I'm wondering if the best option is to put all the changeable items into
> >   a generated header file that is included by version.c; even config.h would
> >   do.
> 
> That approach would have its own downsides.  The first that comes to 
> mind is that there are builds of gnuplot that do _not_ use autotools, 
> thus no (automaticallly updated) config.h either.  Right now, only one 
> of those (config/mingw/Makefile) tries to duplicate the effect of 
> modifying version.c on-the-fly.  The others only get that effect if 
> either autotools or the MinGW makefile did the modification already.
> 
> Generally, any extra file this information would go into will be missing 
> completely in non-autotools builds.
> 
> And if you put that stuff into the main config.h, that that would defeat 
> the purpose of make, because every time you update ChangeLog, the entire 
> program would be rebuilt.  That can't be right.

How about changing version.c to something like

#ifndef LAST_MODIFIED
#define LAST_MODIFIED "2012-06-19"
#endif
const char gnuplot_date[] = LAST_MODIFIED;

And then using some autotools magic that I would have to hunt for
do something along the lines of

LAST_MODIFIED = <some magic involving awk or grep>
DEFS = $DEFS -DLAST_MODIFIED=${LAST_MODIFIED}

That should reproduce the current behavior without modifying
any source files. 

	Ethan
	
> 
> As far as I'm concerned, I haven't seen that mechanism actually working 
> for so long I didn't even know it existed before this discussion.  I run 
> builds using multiple compilers, and the out-of-tree builds that 
> requires break the version.c update mechanism.
> 
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead. 
> Download for free and get started troubleshooting in minutes. 
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: Automatically keeping "last modified" up to date

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

On 07.08.2013 10:53, Lars Hecking wrote:
>   I'm wondering if the best option is to put all the changeable items into
>   a generated header file that is included by version.c; even config.h would
>   do.

That approach would have its own downsides.  The first that comes to 
mind is that there are builds of gnuplot that do _not_ use autotools, 
thus no (automaticallly updated) config.h either.  Right now, only one 
of those (config/mingw/Makefile) tries to duplicate the effect of 
modifying version.c on-the-fly.  The others only get that effect if 
either autotools or the MinGW makefile did the modification already.

Generally, any extra file this information would go into will be missing 
completely in non-autotools builds.

And if you put that stuff into the main config.h, that that would defeat 
the purpose of make, because every time you update ChangeLog, the entire 
program would be rebuilt.  That can't be right.

As far as I'm concerned, I haven't seen that mechanism actually working 
for so long I didn't even know it existed before this discussion.  I run 
builds using multiple compilers, and the out-of-tree builds that 
requires break the version.c update mechanism.

Re: confusing option name for wxWidgets configuration

[sfeam (E. Merritt) <eam...@gm...>]

On Wednesday, 07 August 2013, Mojca Miklavec wrote:
> On Wed, Aug 7, 2013 at 7:19 AM, sfeam (Ethan Merritt) wrote:

> all I'm saying is that it would be better to have the configure option
> names consistent with upstream wxWidgets (and possibly also more
> configurable, but I can live with what is there now).

I disagree. 
It makes more sense for gnuplot's own "configure" command
to be consistent with itself.  We already have

  --with-gihdir=DIR       location of .gih help text file
                          (default PREFIX/share/PACKAGE/VERSION)
  --with-ggi=DIR        enable the ggi driver (EXPERIMENTAL)
  --with-xmi=DIR        ggi's xmi support for pm3d (EXPERIMENTAL)
  --with-readline=DIR      specify the location of GNU readline
  --with-gd=DIR         where to find Tom Boutell's gd library
  --with-pdf=DIR        enable pdf terminal

I think it's reasonable that all the optional terminal drivers can
be selected by --with-XXX=DIR

Arguably it is confusing that for wxt  ./configure --help 
uses the word PATH rather than DIR:

  --with-wx-config=PATH   Use the given path to wx-config, the wxWidgets
                                           configuration program (default search in $PATH)

But it does say that the search is done in $PATH which should be a 
huge clue that it is talking about directories, not file names. 


>> The "official" options are:
>>     AC_ARG_WITH(wxdir,
>>                 [  --with-wxdir=PATH       Use uninstalled version of wxWidgets in PATH],
>>                 [ wx_config_name="$withval/wx-config"

Wait. Are you saying it would be better to have
   --with-wxdir=PATH
than it is to have the current
   --with-wx-config=PATH
??

I don't mind that, but either way it asks for a PATH not a filename.
And you'd still have to create the file $withval/wx-config


Finally, I don't understand why there is a problem having both versions
2.8 and 2.9 installed.  For better or worse (mostly the latter) OSX does
not have a system-wide ld.so.conf list of library paths, so there should not
be a problem that causes only one of the two versions to be found as
default by all programs.

Re: Automatically keeping "last modified" up to date

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

On Wed, Aug 7, 2013 at 10:42 AM, Allin Cottrell wrote:
>
> I build several pieces
> of autotooled software from VC, and gnuplot is the only case
> where a straight build, with no editing, leaves me with a file
> in the source tree that is marked as "modified" relative to
> the repository.

I sympathize with everyone else here: I also don't particularly like
the fact that version.c and pdffigures.tex keep getting modified all
the time (while on the other hand the extremely useful "./configure"
script is excluded with the argument that generated files don't belong
to the source repository).

Mojca

Re: confusing option name for wxWidgets configuration

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

On Wed, Aug 7, 2013 at 7:19 AM, sfeam (Ethan Merritt) wrote:
> On Sunday, 04 August 2013, Mojca Miklavec wrote:
>> Hello,
>>
>> Background: I've been working on a side-by-side installation of
>> wxWidgets 2.8 and 2.9. The main problem on Mac is that wxWidgets 2.8
>> cannot be compiled on operating systems newer than 10.6 (released 4
>> years ago) and a lot of programs still don't support version 2.9. In
>> such a scenario wx-config cannot be in path for both 2.8 and 2.9, so
>> we need a way to specify which one to use.
>>
>> When playing with configuration, the first thing I tried to do was
>>     ./configure --with-wx-config=/opt/local/lib/wx/config/osx_cocoa-unicode-2.9
>> until I realized that gnuplot ignored this completely. Later I
>> realized that --with-wx-config expects a *PATH* where an exacutable
>> wx-config needs to be (no other name allowed), not the link to
>> wx-config file itself.
>
> Yes.  That's what the help message says and what all the other
> similar options require.

It is what the help message says, but it's inconsistent with what the
upstream (wxWidgets) envisioned the option to mean.

>> So I created
>> /opt/local/libexec/wxwidgets/2.9/wx-config with a symlink to the file
>> mentioned above and now
>>     ./configure --with-wx-config=/opt/local/libexec/wxwidgets/2.9
>> works fine.
>
> Yup.  That's the idea.  Except that you shouldn't have to create the
> symlink yourself.  It should already be part of the distribution
> package for that version of wxwidgets.

To paraphrase: I had to go the extra mile and change the packaging of
wxWidgets to explicitly make that symlink. I thought that it would be
enough to specify the exact path, like:
    ./configure --with-wx-config=/opt/local/lib/wx/config/osx_cocoa-unicode-2.9
or like specifying things like
    MAKE=gmake
or
    EMACS=/some/weird/path/Emacs
where it doesn't really matter how the executable is called as long as
it's working.

>> While the implementation in gnuplot is already a lot better than what
>> the majority of software does, it's a minor inconvenience that the
>> option name/meaning is different from the one officially provided by
>> wxWidgets in the file aclocal/wxwin.m4 (see
>> https://github.com/wxWidgets/wxWidgets/blob/master/wxwin.m4) and that
>> one cannot use an executable with a different name.
>
> Well, no.  That's another method of configuration altogether.

Not really that different. It doesn't set any cflags/ldflags. It still
invokes wx-config for all the configuration.

> Yes, we could in theory import or link to an *.m4 file and use that
> during configuration.  But that's not the method used for other
> gnuplot options

That's not entirely true. Gnuplot contains m4/pkg.m4 for example,
m4/apple.m4 (that one doesn't come from any 'upstream' though) and
aclocal.m4 contains definitions like AC_DEFUN([AM_PATH_LISPDIR],...)

This is not another method of configuration. It only does things like

dnl WX_CONFIG_OPTIONS
dnl
dnl adds support for --wx-prefix, --wx-exec-prefix, --with-wxdir and
dnl --wx-config command line options

to make it easier to support flags like --with-wx-config (to find the
right wx-config) out-of-the-box and to make it easier to specify
things like
    WX_CONFIG_CHECK([2.5.3], [wxWin=1])
instead of this block for example:

    dnl Ckeck for wxWidgets version
    if expr 2.5.3 \> `${WX_CONFIG} --version` >/dev/null; then
      AC_MSG_WARN([Your development package for wxWidgets is too old,
you need at least version 2.5.3. The wxWidgets terminal will not be
compiled.])
      enable_wxwidgets_ok=no
    fi

All the compiler and linker flags would still work the same way as they do now.

> and I don't see any advantage over just invoking
> wx-config.

It's not a different method: wx-config would still be invoked and work
in exactly the same way. The advantage is that you could replace the
following code block in configure.in:

  dnl The user can specify another path for wx-config
  WXWIDGETS_PATH="${PATH}"
  AC_ARG_WITH(wx-config,dnl
  [--with-wx-config=PATH   Use the given path to wx-config, the
wxWidgets configuration program
    (default search in $PATH)],
    [ if test "${with_wx_config}" != "no" ; then
  WXWIDGETS_PATH="${with_wx_config}:${PATH}"
     fi ])

  dnl Look for wx-config in the path
  AC_PATH_PROG(WX_CONFIG, wx-config, no, ${WXWIDGETS_PATH})
  if test "${WX_CONFIG}" = "no"; then
    AC_MSG_WARN([wxWidgets can't be found. You can try
--with-wx-config-path to give the right path to wx-config. The
wxWidgets terminal will not be compiled.])
    enable_wxwidgets_ok=no
  else

    dnl Ckeck for wxWidgets version
    if expr 2.5.3 \> `${WX_CONFIG} --version` >/dev/null; then
      AC_MSG_WARN([Your development package for wxWidgets is too old,
you need at least version 2.5.3. The wxWidgets terminal will not be
compiled.])
      enable_wxwidgets_ok=no
    fi

    dnl Make sure we're using more than the 'base' wxWidgets. Those
    if expr `${WX_CONFIG} --basename` : '.*base' >/dev/null; then
      AC_MSG_WARN([You only have the 'base' flavor of wxWidgets. A
full wxWidgets library is required. On Debian/Ubuntu, please make sure
that you have a 'libwx...-dev' package other than just 'libwxbase-dev'
installed. The wxWidgets terminal will not be compiled.])
      enable_wxwidgets_ok=no
    fi
  fi

with maybe three or four autoconfig macro calls and offer the
packagers of gnuplot more flexibility and more standard options to
configure script.

>> The "official"
>> options are:
>>
>> AC_DEFUN([WX_CONFIG_OPTIONS],
>> [
>>     AC_ARG_WITH(wxdir,
>>                 [  --with-wxdir=PATH       Use uninstalled version of
>> wxWidgets in PATH],
>>                 [ wx_config_name="$withval/wx-config"
>>                   wx_config_args="--inplace"])
>>     AC_ARG_WITH(wx-config,
>>                 [  --with-wx-config=CONFIG wx-config script to use (optional)],
>>                 wx_config_name="$withval" )
>>     AC_ARG_WITH(wx-prefix,
>>                 [  --with-wx-prefix=PREFIX Prefix where wxWidgets is
>> installed (optional)],
>>                 wx_config_prefix="$withval", wx_config_prefix="")
>>     AC_ARG_WITH(wx-exec-prefix,
>>                 [  --with-wx-exec-prefix=PREFIX
>>                           Exec prefix where wxWidgets is installed (optional)],
>>                 wx_config_exec_prefix="$withval", wx_config_exec_prefix="")
>> ])
>>
>> So instead of
>>     ./configure --with-wx-config=/opt/local/libexec/wxwidgets/2.9
>> I would expect either of the following options to work:
>>     ./configure --with-wx-config=/opt/local/libexec/wxwidgets/2.9/wx-config
>>     ./configure --with-wx-config=/opt/local/lib/wx/config/osx_cocoa-unicode-2.9
>>     ./configure --with-wxdir=/opt/local/libexec/wxwidgets/2.9
>>
>> I didn't try to research the history of this option in gnuplot. I only
>> know that MacPorts tried to use
>> --with-wx-config=/opt/local/bin/wx-config until now, but nobody
>> realized that it didn't work. (It picked the right wx-config, but only
>> because it was the first one in PATH, not because --with-wx-config
>> would work the way the package maintainer imagined/expected it to
>> work.)
>>
>> My question is the following: would it be acceptable for gnuplot to either:
>> a) [probably best option] include the official wxwin.m4 from upstream
>> in its sources and call the few macros as documented in the link above
>> (I can help with implementation and testing)
>> b) change the option name and make sure that
>> --with-wx-config/--with-wxdir would behave approximately the same as
>> in upstream (as opposed to --with-wx-config behaving as upstream's
>> --with-wxdir)
>
> I would recommend reporting the lack of a file with the standard name
> wx-config as a bug to whoever prepared your packaged distribution
> of wxwidgets.

There's no-one to report it to because I'm experimenting with the
packaging myself.

Off topic, but just to explain:

It's a horribly situation because version 2.8 doesn't compile on
recent macs at all (it only works up to Snow Leopard that has been
released four years ago, and even then it can only be compiled as
32-bit on a 64-bit machine which means that all of its dependencies
also need to be built as 32-bit), while a lot of developers of
wxWidgets-based software resist to support 2.9 (arguing that 2.9 is
experimental and that it should not be used - the truth is, 2.8 cannot
be used at all, so there is no choice).

Now, the package manager support systems ranging from Mac OS X 10.4
(officially 10.6) up to the latest versions. It supports x86_64, i386
(and unofficially also the ppc). And wxWidgets 2.8 work on 10.6.

So it makes it particularly useful if both wxWidgets 2.8 and 2.9 can
be installed side-by-side. Libraries and include dirs are already
different by default, so allowing a side-by-side installation
basically boils down to not installing ${prefix}/bin/wx-config for
both 2.8 and 2.9; wx-config cannot exist in PATH for both 2.8 and 2.9
at the same time.

> It's supposed to be there.  Here is a relevant link to
> the wx wiki:
>
>     http://wiki.wxwidgets.org/Wx-Config

But one cannot have both wx-config for 2.8 and wx-config for 2.9
active at the same time. So even when 2.9 is active, the package
manager needs to be able to compile packages against wxWidgets 2.8 and
in that case the package manager really needs to tell the configure
script how to configure for wxWidgets 2.8 without having the desired
wx-config in path.

In case of gnuplot I can do that now with
    ./configure --with-wx-config=/opt/local/libexec/wxwidgets/2.9
all I'm saying is that it would be better to have the configure option
names consistent with upstream wxWidgets (and possibly also more
configurable, but I can live with what is there now).

Mojca

Re: Automatically keeping "last modified" up to date

[Allin C. <cot...@wf...>]

On Tue, 6 Aug 2013, Ethan A Merritt wrote:

> On Tuesday, August 06, 2013 01:01:07 pm Allin Cottrell wrote:
>> On Tue, 6 Aug 2013, Ethan A Merritt wrote:
>>
>>> On Tuesday, August 06, 2013 12:26:04 pm Allin Cottrell wrote:
>>>> There's one other fishy thing in that neighborhood. When I do
>>>> a cvs update it seems I quite often get the cvs 'M' flag
>>>> indicating that src/version.c is modified, when I certainly
>>>> haven't edited that file.
>>>> Allin Cottrell
>>>
>>> Exactly.  That's as expected.
>>> When you run "make" it changes gnuplot_date[] in version.c file to reflect
>>> the most recently modified date.  So if you later update from CVS it sees
>>> that your local copy of version.c is different from the base copy in CVS.
>>
>> OK, I see. And I don't think this is a big deal. But isn't it
>> sort of a principle of version control to operate a strict
>> separation between files that are supplied from the repository
>> (and hence are, in a sense, "read-only") and files that are
>> automatically generated in the course of a build? Gnuplot's
>> version.c seems to cross that line.
>>
>> Allin Cottrell
>
> Well, that obviously doesn't make sense if your purpose in downloading
> from CVS is to work on development.  The files are clearly not read-only.
> You are editing and re-editing them constantly during the course of an
> edit/build/debug cycle.

That's why I said "in a sense, read-only": the "sense" was 
supposed to be that they are in effect read-only if you're 
just building gnuplot from CVS. You don't want to modify 
anything inadvertently. If you're hacking on the code, 
obviously you're free to modify any file.

> The Makefile in the released version doesn't do this modification;
> the date in version.c is fixed at the release date.  That's the idea behind
> having a separate Makefile.maint that is only invoked during development,
> not during a build from the packaged release.
>
> So far as I know, this and most of the rest of the autotools-based
> build procedure were put together years ago by Lars Hecking.
> I try not to touch them if possible :-)

I agree that not monkeying with standard autotools procedures 
is good policy. My point is just this: I build several pieces 
of autotooled software from VC, and gnuplot is the only case 
where a straight build, with no editing, leaves me with a file 
in the source tree that is marked as "modified" relative to 
the repository.

Allin Cottrell

Re: confusing option name for wxWidgets configuration

[sfeam (E. Merritt) <eam...@gm...>]

On Sunday, 04 August 2013, Mojca Miklavec wrote:
> Hello,
> 
> Background: I've been working on a side-by-side installation of
> wxWidgets 2.8 and 2.9. The main problem on Mac is that wxWidgets 2.8
> cannot be compiled on operating systems newer than 10.6 (released 4
> years ago) and a lot of programs still don't support version 2.9. In
> such a scenario wx-config cannot be in path for both 2.8 and 2.9, so
> we need a way to specify which one to use.
> 
> When playing with configuration, the first thing I tried to do was
>     ./configure --with-wx-config=/opt/local/lib/wx/config/osx_cocoa-unicode-2.9
> until I realized that gnuplot ignored this completely. Later I
> realized that --with-wx-config expects a *PATH* where an exacutable
> wx-config needs to be (no other name allowed), not the link to
> wx-config file itself. 

Yes.  That's what the help message says and what all the other
similar options require.

> So I created
> /opt/local/libexec/wxwidgets/2.9/wx-config with a symlink to the file
> mentioned above and now
>     ./configure --with-wx-config=/opt/local/libexec/wxwidgets/2.9
> works fine.

Yup.  That's the idea.  Except that you shouldn't have to create the
symlink yourself.  It should already be part of the distribution 
package for that version of wxwidgets.

> While the implementation in gnuplot is already a lot better than what
> the majority of software does, it's a minor inconvenience that the
> option name/meaning is different from the one officially provided by
> wxWidgets in the file aclocal/wxwin.m4 (see
> https://github.com/wxWidgets/wxWidgets/blob/master/wxwin.m4) and that
> one cannot use an executable with a different name. 

Well, no.  That's another method of configuration altogether.
Yes, we could in theory import or link to an *.m4 file and use that
during configuration.  But that's not the method used for other
gnuplot options and I don't see any advantage over just invoking
wx-config.

> The "official"
> options are:
> 
> AC_DEFUN([WX_CONFIG_OPTIONS],
> [
>     AC_ARG_WITH(wxdir,
>                 [  --with-wxdir=PATH       Use uninstalled version of
> wxWidgets in PATH],
>                 [ wx_config_name="$withval/wx-config"
>                   wx_config_args="--inplace"])
>     AC_ARG_WITH(wx-config,
>                 [  --with-wx-config=CONFIG wx-config script to use (optional)],
>                 wx_config_name="$withval" )
>     AC_ARG_WITH(wx-prefix,
>                 [  --with-wx-prefix=PREFIX Prefix where wxWidgets is
> installed (optional)],
>                 wx_config_prefix="$withval", wx_config_prefix="")
>     AC_ARG_WITH(wx-exec-prefix,
>                 [  --with-wx-exec-prefix=PREFIX
>                           Exec prefix where wxWidgets is installed (optional)],
>                 wx_config_exec_prefix="$withval", wx_config_exec_prefix="")
> ])
> 
> So instead of
>     ./configure --with-wx-config=/opt/local/libexec/wxwidgets/2.9
> I would expect either of the following options to work:
>     ./configure --with-wx-config=/opt/local/libexec/wxwidgets/2.9/wx-config
>     ./configure --with-wx-config=/opt/local/lib/wx/config/osx_cocoa-unicode-2.9
>     ./configure --with-wxdir=/opt/local/libexec/wxwidgets/2.9
> 
> I didn't try to research the history of this option in gnuplot. I only
> know that MacPorts tried to use
> --with-wx-config=/opt/local/bin/wx-config until now, but nobody
> realized that it didn't work. (It picked the right wx-config, but only
> because it was the first one in PATH, not because --with-wx-config
> would work the way the package maintainer imagined/expected it to
> work.)
> 
> My question is the following: would it be acceptable for gnuplot to either:
> a) [probably best option] include the official wxwin.m4 from upstream
> in its sources and call the few macros as documented in the link above
> (I can help with implementation and testing)
> b) change the option name and make sure that
> --with-wx-config/--with-wxdir would behave approximately the same as
> in upstream (as opposed to --with-wx-config behaving as upstream's
> --with-wxdir)

I would recommend reporting the lack of a file with the standard name
wx-config as a bug to whoever prepared your packaged distribution
of wxwidgets.   It's supposed to be there.  Here is a relevant link to
the wx wiki:

    http://wiki.wxwidgets.org/Wx-Config

		Ethan

Re: Automatically keeping "last modified" up to date

[Daniel J S. <dan...@ie...>]

On 08/06/2013 04:11 PM, Ethan A Merritt wrote:

> FWIW, my work flow is such that I never build on top of the directory
> that CVS downloads into.   I have a script that builds via the sequence
> 1) create a new working directory
> 2) copy the CVS download into this new directory
> 3) cd to that directory
> 4) ./prepare
> 5) ./configure
> 6) make
>
> When doing development I only modify and rebuild from files in this
> working directory, so the issue of divergence from the pure CVS copy
> does not arise.  To prepare a patch corresponding to the work I have
> just done, I can do a "diff -urp" between the pristine CVS directory
> and the working directory.  I realize that other people have other
> work flows.

This approach is fine with CVS, but with something like mercurial/git 
probably wouldn't work.  The clone is tied to a certain directory and 
deviating from that would cause problems.  With mercurial, the diff 
facility is incorporated into the software, i.e., "hg diff".  To 
transfer modifications, one would actually create a changeset first, 
i.e., "hg commit", and then either push that to the canonical repository 
or create a patch file with "hg export" that someone else could import 
to test.

Dan

Re: Automatically keeping "last modified" up to date

[Daniel J S. <dan...@ie...>]

On 08/06/2013 04:05 PM, Hans-Bernhard Bröker wrote:
> On 06.08.2013 22:26, Daniel J Sebald wrote:
>
>> that sed script is not occurring (I checked the log). Probably because
>> version.c no longer appears in the src/ directory of the build root.
>
> Indeed. The materiel in both Makefile.maint files is not equipped to
> work in out-of-tree builds. I could probably fix src/Makefile.maint.
> Should I?

It depends on how much work you think it is.  It would be nice if it 
were an easy change.  With my new system I'm finding that gnuplot 
compiles in less than half a minute it seems.  I got in the habit of 
building separate from the source tree because some of these large C++ 
projects take close to an hour to build so comparing via rebuilding 
isn't efficient.

Thanks,

Dan

Re: Automatically keeping "last modified" up to date

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

On Tuesday, August 06, 2013 01:01:07 pm Allin Cottrell wrote:
> On Tue, 6 Aug 2013, Ethan A Merritt wrote:
> 
> > On Tuesday, August 06, 2013 12:26:04 pm Allin Cottrell wrote:
> >> There's one other fishy thing in that neighborhood. When I do
> >> a cvs update it seems I quite often get the cvs 'M' flag
> >> indicating that src/version.c is modified, when I certainly
> >> haven't edited that file.
> >> Allin Cottrell
> >
> > Exactly.  That's as expected.
> > When you run "make" it changes gnuplot_date[] in version.c file to reflect
> > the most recently modified date.  So if you later update from CVS it sees
> > that your local copy of version.c is different from the base copy in CVS.
> 
> OK, I see. And I don't think this is a big deal. But isn't it 
> sort of a principle of version control to operate a strict 
> separation between files that are supplied from the repository 
> (and hence are, in a sense, "read-only") and files that are 
> automatically generated in the course of a build? Gnuplot's 
> version.c seems to cross that line.
> 
> Allin Cottrell

Well, that obviously doesn't make sense if your purpose in downloading
from CVS is to work on development.  The files are clearly not read-only.
You are editing and re-editing them constantly during the course of an
edit/build/debug cycle.  

The Makefile in the released version doesn't do this modification;
the date in version.c is fixed at the release date.  That's the idea behind
having a separate Makefile.maint that is only invoked during development,
not during a build from the packaged release.

So far as I know, this and most of the rest of the autotools-based
build procedure were put together years ago by Lars Hecking.
I try not to touch them if possible :-)

FWIW, my work flow is such that I never build on top of the directory
that CVS downloads into.   I have a script that builds via the sequence
1) create a new working directory
2) copy the CVS download into this new directory
3) cd to that directory
4) ./prepare
5) ./configure
6) make

When doing development I only modify and rebuild from files in this
working directory, so the issue of divergence from the pure CVS copy
does not arise.  To prepare a patch corresponding to the work I have
just done, I can do a "diff -urp" between the pristine CVS directory
and the working directory.  I realize that other people have other
work flows.

Anyhow, if I were designing the mechanism for tracking modification
date from scratch I would do it differently - probably by making the
modification date a defined constant and placing the definition in
the compilation command used by the Makefile.  If someone wants to
send a patch that does this (or something equivalent) I'd be happy
to try it out.

	Ethan

Re: Automatically keeping "last modified" up to date

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

On 06.08.2013 22:26, Daniel J Sebald wrote:

> that sed script is not occurring (I checked the log).  Probably because
> version.c no longer appears in the src/ directory of the build root.

Indeed.  The materiel in both Makefile.maint files is not equipped to 
work in out-of-tree builds.  I could probably fix src/Makefile.maint. 
Should I?

Re: Automatically keeping "last modified" up to date

[Daniel J S. <dan...@ie...>]

On 08/06/2013 03:48 PM, Allin Cottrell wrote:
> On Tue, 6 Aug 2013, Daniel J Sebald wrote:
>
>> On 08/06/2013 03:01 PM, Allin Cottrell wrote:
>>> On Tue, 6 Aug 2013, Ethan A Merritt wrote:
>>>
>>>> On Tuesday, August 06, 2013 12:26:04 pm Allin Cottrell wrote:
>>>>> There's one other fishy thing in that neighborhood. When I do
>>>>> a cvs update it seems I quite often get the cvs 'M' flag
>>>>> indicating that src/version.c is modified, when I certainly
>>>>> haven't edited that file.
>>>>> Allin Cottrell
>>>>
>>>> Exactly. That's as expected.
>>>> When you run "make" it changes gnuplot_date[] in version.c file to
>>>> reflect
>>>> the most recently modified date. So if you later update from CVS it
>>>> sees
>>>> that your local copy of version.c is different from the base copy in
>>>> CVS.
>>>
>>> OK, I see. And I don't think this is a big deal. But isn't it
>>> sort of a principle of version control to operate a strict
>>> separation between files that are supplied from the repository
>>> (and hence are, in a sense, "read-only") and files that are
>>> automatically generated in the course of a build? Gnuplot's
>>> version.c seems to cross that line.
>>
>> This is sort of the assumption I made and hence the confusion. Maybe
>> it would be better to not do the "mv" step of:
>>
>> sed -e '/^const char gnuplot_date/ s/"[^"]*"/"2013-08-06 "/' \
>> version.c > version.ct;
>> mv version.ct version.c
>>
>> and just compile the derivative file. If that were the case, then my
>> build outside the source tree would have failed because version.ct
>> would not appear. I suppose the intent here is to allow building to
>> proceed if the user doesn't have "sed" on their system, for example.
>>
>> Are you building outside of the source tree? Perhaps we are running
>> into the same issue.
>
> I build gnuplot in its own source tree, so that's not the issue for me.
>
> I just tried a CVS update and build, and this time it worked fine,
> showing the current date. Maybe something extraneous caused a problem
> before, but it seems to me there's a certain brittleness here.
>
> Allin Cottrell

OK.

I still am definitely seeing that if I build outside the source tree the 
version isn't working properly.

The ./configure process will create a Makefile inside the build 
directory.  Say I have:

gnuplot/gnuplot/src
gnuplot/build1/src

(gnuplot/build1 is where I run ./configure) then I see

gnuplot/build1/src/Makefile

after ./configure.  If I look at that Makefile, I see:

EXTRA_DIST = GNUmakefile Makefile.maint NeXT OpenStep README \
genopt.com gnuplot.opt x11.opt linkopt.vms \
makefile.all makefile.awc os2 win \

Could it be that make is expecting to find

gnuplot/build1/src/Makefile.maint

when actually that file is located in the src tree

gnuplot/gnuplot/src/Makefile.maint

?  The make process would have to reorient itself to the source tree src 
directory somehow to run that sed script inside Makefile.maint.

Dan

Re: Automatically keeping "last modified" up to date

[Allin C. <cot...@wf...>]

On Tue, 6 Aug 2013, Daniel J Sebald wrote:

> On 08/06/2013 03:01 PM, Allin Cottrell wrote:
>> On Tue, 6 Aug 2013, Ethan A Merritt wrote:
>> 
>>> On Tuesday, August 06, 2013 12:26:04 pm Allin Cottrell wrote:
>>>> There's one other fishy thing in that neighborhood. When I do
>>>> a cvs update it seems I quite often get the cvs 'M' flag
>>>> indicating that src/version.c is modified, when I certainly
>>>> haven't edited that file.
>>>> Allin Cottrell
>>> 
>>> Exactly.  That's as expected.
>>> When you run "make" it changes gnuplot_date[] in version.c file to reflect
>>> the most recently modified date.  So if you later update from CVS it sees
>>> that your local copy of version.c is different from the base copy in CVS.
>> 
>> OK, I see. And I don't think this is a big deal. But isn't it
>> sort of a principle of version control to operate a strict
>> separation between files that are supplied from the repository
>> (and hence are, in a sense, "read-only") and files that are
>> automatically generated in the course of a build? Gnuplot's
>> version.c seems to cross that line.
>
> This is sort of the assumption I made and hence the confusion.  Maybe it 
> would be better to not do the "mv" step of:
>
> sed -e '/^const char gnuplot_date/ s/"[^"]*"/"2013-08-06 "/' \
>     version.c > version.ct;
> mv version.ct version.c
>
> and just compile the derivative file.  If that were the case, then my build 
> outside the source tree would have failed because version.ct would not 
> appear.  I suppose the intent here is to allow building to proceed if the 
> user doesn't have "sed" on their system, for example.
>
> Are you building outside of the source tree?  Perhaps we are running into the 
> same issue.

I build gnuplot in its own source tree, so that's not the 
issue for me.

I just tried a CVS update and build, and this time it worked 
fine, showing the current date. Maybe something extraneous 
caused a problem before, but it seems to me there's a certain 
brittleness here.

Allin Cottrell

Re: Automatically keeping "last modified" up to date

[Daniel J S. <dan...@ie...>]

On 08/06/2013 03:01 PM, Allin Cottrell wrote:
> On Tue, 6 Aug 2013, Ethan A Merritt wrote:
>
>> On Tuesday, August 06, 2013 12:26:04 pm Allin Cottrell wrote:
>>> There's one other fishy thing in that neighborhood. When I do
>>> a cvs update it seems I quite often get the cvs 'M' flag
>>> indicating that src/version.c is modified, when I certainly
>>> haven't edited that file.
>>> Allin Cottrell
>>
>> Exactly.  That's as expected.
>> When you run "make" it changes gnuplot_date[] in version.c file to reflect
>> the most recently modified date.  So if you later update from CVS it sees
>> that your local copy of version.c is different from the base copy in CVS.
>
> OK, I see. And I don't think this is a big deal. But isn't it
> sort of a principle of version control to operate a strict
> separation between files that are supplied from the repository
> (and hence are, in a sense, "read-only") and files that are
> automatically generated in the course of a build? Gnuplot's
> version.c seems to cross that line.

This is sort of the assumption I made and hence the confusion.  Maybe it 
would be better to not do the "mv" step of:

sed -e '/^const char gnuplot_date/ s/"[^"]*"/"2013-08-06 "/' \
      version.c > version.ct;
mv version.ct version.c

and just compile the derivative file.  If that were the case, then my 
build outside the source tree would have failed because version.ct would 
not appear.  I suppose the intent here is to allow building to proceed 
if the user doesn't have "sed" on their system, for example.

Are you building outside of the source tree?  Perhaps we are running 
into the same issue.

Dan

Re: Automatically keeping "last modified" up to date

[Daniel J S. <dan...@ie...>]

On 08/06/2013 02:56 PM, Daniel J Sebald wrote:
[snip]
> I'm not seeing that:
>
> [gnuplot]# make version.o
> make: *** No rule to make target `version.o'.  Stop.
>
> [gnuplot]# make -v
> GNU Make 3.82
> Built for x86_64-redhat-linux-gnu
> Copyright (C) 2010  Free Software Foundation, Inc.
>
> When the build process is carried out, it must be using the version.c
> that exists in the repository instead of an updated version.c.  Now that
> I know what it is supposed to look like, I can investigate.

I was looking at the Makefile.maint in the root directory.  I see there 
is another in the src/ directory as well.

I downloaded a fresh CVS source tree and check date on version.c:

[gnuplot]# ls -l src/version.c
-rw-r--r--. 1 root root 2151 Feb 26 17:38 src/version.c

I ran "prepare" and "configure".

[gnuplot]# ls -l src/version.c
-rw-r--r--. 1 root root 2151 Feb 26 17:38 src/version.c

Change to the src directory:

[root@moorglade src]# make version.o
Making version.c
sed -e '/^const char gnuplot_date/ s/"[^"]*"/"2013-08-06 "/' \
     version.c > version.ct;
mv version.ct version.c
gcc -DHAVE_CONFIG_H -I. -I..  -I../term -I../term 
-DBINDIR=\"/usr/local/bin\" 
-DX11_DRIVER_DIR=\"/usr/local/libexec/gnuplot/4.7\" 
-DQT_DRIVER_DIR=\"/usr/local/libexec/gnuplot/4.7\" 
-DGNUPLOT_SHARE_DIR=\"/usr/local/share/gnuplot/4.7\" 
-DGNUPLOT_PS_DIR=\"/usr/local/share/gnuplot/4.7/PostScript\" 
-DGNUPLOT_JS_DIR=\"/usr/local/share/gnuplot/4.7/js\" 
-DGNUPLOT_LUA_DIR=\"/usr/local/share/gnuplot/4.7/lua\" 
-DCONTACT=\"gnu...@li...\" 
-DHELPFILE=\"/usr/local/share/gnuplot/4.7/gnuplot.gih\" 
-DGNUPLOT_X11=\"`echo gnuplot_x11 | sed 's,x,x,'`\" 
-DXAPPLRESDIR=\"/etc/X11/app-defaults/\"  -I/usr/local/include  -g -O2 
-MT version.o -MD -MP -MF .deps/version.Tpo -c -o version.o version.c
mv -f .deps/version.Tpo .deps/version.Po

OK, that looks right now.

So I think I see what the issue is--when I built gnuplot from outside 
the source tree, e.g.,

mkdir ../build1
cd ../build1
../gnuplot/configure
make

that sed script is not occurring (I checked the log).  Probably because 
version.c no longer appears in the src/ directory of the build root.

Dan

Re: Automatically keeping "last modified" up to date

[Allin C. <cot...@wf...>]

On Tue, 6 Aug 2013, Daniel J Sebald wrote:

> On 08/06/2013 02:37 PM, Ethan A Merritt wrote:
>> On Tuesday, August 06, 2013 12:25:08 pm Daniel J Sebald wrote:
> [snip]
>>> Well, I see the file Makefile.maint, but I'm not sure what I'm looking
>>> at.  I see some THIS_VERSION, PREV_VERSION , etc. but I don't know how
>>> that ties into what I see in the source code.  In show.c is the line:
>>>
>>>       fprintf(fp, fmt,
>>> 	    p,			/* empty line */
>>> 	    p, PROGRAM,
>>> 	    p, gnuplot_version, gnuplot_patchlevel, gnuplot_date,
>>>
>>> in which gnuplot_date is the "last modified" date.  And that variable
>>> comes from version.c, i.e.,
>>>
>>> const char gnuplot_date[] = "2012-06-19 ";
>>>
>>> but I can't find anything in a make file that indicates gnuplot_date[]
>>> is automatically generated.  One has to manually change that, correct?
>>
>> No.
>> It is automatically updated during "make".
>> I've never had any problem with this, so I don't know what might be going
>> wrong on your machine.
>>
>> Here's what I see:
>>
>> chauvet [92] make version.o
>> Making version.c
>> sed -e '/^const char gnuplot_date/ s/"[^"]*"/"2013-07-25 "/' \
>>              version.c>  version.ct;
>> mv version.ct version.c
>> gcc -DHAVE_CONFIG_H -I. -I..  -I../term -I../term -DBINDIR=\"/usr/local/bin\" -DX11_DRIVER_DIR=\"/usr/local/libexec/gnuplot/4.7\" -DQT_DRIVER_DIR=\"/usr/local/libexec/gnuplot/4.7\" -DGNUPLOT_SHARE_DIR=\"/usr/local/share/gnuplot/4.7\" -DGNUPLOT_PS_DIR=\"/usr/local/share/gnuplot/4.7/PostScript\" -DGNUPLOT_JS_DIR=\"/usr/local/share/gnuplot/4.7/js\" -DGNUPLOT_LUA_DIR=\"/usr/local/share/gnuplot/4.7/lua\" -DCONTACT=\"gnu...@li...\" -DHELPFILE=\"/usr/local/share/gnuplot/4.7/gnuplot.gih\" -DGNUPLOT_X11=\"`echo gnuplot_x11 | sed 's,x,x,'`\" -DXAPPLRESDIR=\"/etc/X11/app-defaults/\"  -I/usr/local/include -I/usr/local/include   -pthread -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include   -pthread -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/l
> ib/glib-2.0/include    -g -O2 -MT version.o -MD -MP -MF .deps/version.Tpo -c -o version.o version.c
>> mv -f .deps/version.Tpo .deps/version.Po
>>
>
> I'm not seeing that:
>
> [gnuplot]# make version.o
> make: *** No rule to make target `version.o'.  Stop.

You'll get that in the top-level gnuplot directory. But the 
overall "make" moves into the src subdirectory, where there 
are rules for both version.o and version.c.

Allin Cottrell

Re: Automatically keeping "last modified" up to date

[Allin C. <cot...@wf...>]

On Tue, 6 Aug 2013, Ethan A Merritt wrote:

> On Tuesday, August 06, 2013 12:26:04 pm Allin Cottrell wrote:
>> There's one other fishy thing in that neighborhood. When I do
>> a cvs update it seems I quite often get the cvs 'M' flag
>> indicating that src/version.c is modified, when I certainly
>> haven't edited that file.
>> Allin Cottrell
>
> Exactly.  That's as expected.
> When you run "make" it changes gnuplot_date[] in version.c file to reflect
> the most recently modified date.  So if you later update from CVS it sees
> that your local copy of version.c is different from the base copy in CVS.

OK, I see. And I don't think this is a big deal. But isn't it 
sort of a principle of version control to operate a strict 
separation between files that are supplied from the repository 
(and hence are, in a sense, "read-only") and files that are 
automatically generated in the course of a build? Gnuplot's 
version.c seems to cross that line.

Allin Cottrell

Re: Automatically keeping "last modified" up to date

[Daniel J S. <dan...@ie...>]

On 08/06/2013 02:37 PM, Ethan A Merritt wrote:
> On Tuesday, August 06, 2013 12:25:08 pm Daniel J Sebald wrote:
[snip]
>> Well, I see the file Makefile.maint, but I'm not sure what I'm looking
>> at.  I see some THIS_VERSION, PREV_VERSION , etc. but I don't know how
>> that ties into what I see in the source code.  In show.c is the line:
>>
>>       fprintf(fp, fmt,
>> 	    p,			/* empty line */
>> 	    p, PROGRAM,
>> 	    p, gnuplot_version, gnuplot_patchlevel, gnuplot_date,
>>
>> in which gnuplot_date is the "last modified" date.  And that variable
>> comes from version.c, i.e.,
>>
>> const char gnuplot_date[] = "2012-06-19 ";
>>
>> but I can't find anything in a make file that indicates gnuplot_date[]
>> is automatically generated.  One has to manually change that, correct?
>
> No.
> It is automatically updated during "make".
> I've never had any problem with this, so I don't know what might be going
> wrong on your machine.
>
> Here's what I see:
>
> chauvet [92] make version.o
> Making version.c
> sed -e '/^const char gnuplot_date/ s/"[^"]*"/"2013-07-25 "/' \
>              version.c>  version.ct;
> mv version.ct version.c
> gcc -DHAVE_CONFIG_H -I. -I..  -I../term -I../term -DBINDIR=\"/usr/local/bin\" -DX11_DRIVER_DIR=\"/usr/local/libexec/gnuplot/4.7\" -DQT_DRIVER_DIR=\"/usr/local/libexec/gnuplot/4.7\" -DGNUPLOT_SHARE_DIR=\"/usr/local/share/gnuplot/4.7\" -DGNUPLOT_PS_DIR=\"/usr/local/share/gnuplot/4.7/PostScript\" -DGNUPLOT_JS_DIR=\"/usr/local/share/gnuplot/4.7/js\" -DGNUPLOT_LUA_DIR=\"/usr/local/share/gnuplot/4.7/lua\" -DCONTACT=\"gnu...@li...\" -DHELPFILE=\"/usr/local/share/gnuplot/4.7/gnuplot.gih\" -DGNUPLOT_X11=\"`echo gnuplot_x11 | sed 's,x,x,'`\" -DXAPPLRESDIR=\"/etc/X11/app-defaults/\"  -I/usr/local/include -I/usr/local/include   -pthread -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include   -pthread -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/l
ib/glib-2.0/include    -g -O2 -MT version.o -MD -MP -MF .deps/version.Tpo -c -o version.o version.c
> mv -f .deps/version.Tpo .deps/version.Po
>

I'm not seeing that:

[gnuplot]# make version.o
make: *** No rule to make target `version.o'.  Stop.

[gnuplot]# make -v
GNU Make 3.82
Built for x86_64-redhat-linux-gnu
Copyright (C) 2010  Free Software Foundation, Inc.

When the build process is carried out, it must be using the version.c 
that exists in the repository instead of an updated version.c.  Now that 
I know what it is supposed to look like, I can investigate.

Thanks,

Dan

Re: Automatically keeping "last modified" up to date

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

On Tuesday, August 06, 2013 12:26:04 pm Allin Cottrell wrote:
> On Tue, 6 Aug 2013, Ethan Merritt wrote:
> 
> > On Tuesday, August 06, 2013 10:25:33 am Daniel J Sebald wrote:
> >> I just built the most recent version of gnuplot and noticed that the
> >> "last modified" date in the intro refers back to 2012 and is manually
> >> entered.  Why can't that automatically be generated?  It would be nice
> >> to do this so that when one builds/installs the latest version, upon
> >> launching the program it is immediate clear that the install process was
> >> successful by looking at the "last modified" date.
> >>
> >> Here are some approaches that could be tried:
> >>
> >> 1) There is this configure.in file containing:
> >>
> >> dnl $Id: configure.in,v 1.332 2013/07/18 23:22:17 sfeam Exp $
> >>
> >> Is that file somehow generated by the CVS/repository to reflect the most
> >> recent modification of the repository?  If so, that would be great as it
> >> would also contain a time stamp.  Could write a script to search for
> >> that and define LAST_MODIFIED in some header file using the extracted
> >> "2013/07/18 23:22:17" string.
> >>
> >> 2) Is there some way during make to get the most recent date of all the
> >> pertinent files?  "make" does date checking, so perhaps there is a make
> >> variable/macro that reflects that.
> >>
> >> 3) Similar to #2, we could maybe write an OS script that does the same
> >> thing by looking for the date of the most recent file in the source tree.
> >>
> >> 4) Ethan keeps the ChangeLog up to date.  It would be easy to search for
> >> the most recent date near the top of the file and use that as a
> >> definition for LAST_MODIFIED.
> >
> > The file .../src/Makefile.maint exists for exactly this purpose.
> > It updates the version string based on the most recent date in ChangeLog.
> > This file is included during "make" by gnu make.
> > Possibly you are using some other make program?
> 
> I think there's something wrong with this. I definitely use 
> gnu make, but sometimes when I update from CVS, do prepare, 
> configure and make, I get a "last modified" date that is 
> (e.g.) 6 months ago and clearly wrong.

I believe you, but I don't know why this would happen.
I could imagine a state in which you had updated version.c once
in such a way that subsequent automatic updates failed.
This would leave the reported version stuck at some intermediate
date stamp, but it wouldn't be the one in the base CVS copy of the file.

> There's one other fishy thing in that neighborhood. When I do 
> a cvs update it seems I quite often get the cvs 'M' flag 
> indicating that src/version.c is modified, when I certainly 
> haven't edited that file.
> Allin Cottrell

Exactly.  That's as expected.
When you run "make" it changes gnuplot_date[] in version.c file to reflect
the most recently modified date.  So if you later update from CVS it sees
that your local copy of version.c is different from the base copy in CVS.

	Ethan

Re: Automatically keeping "last modified" up to date

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

On Tuesday, August 06, 2013 12:25:08 pm Daniel J Sebald wrote:
> On 08/06/2013 01:39 PM, Ethan Merritt wrote:
> > On Tuesday, August 06, 2013 10:25:33 am Daniel J Sebald wrote:
> >> I just built the most recent version of gnuplot and noticed that the
> >> "last modified" date in the intro refers back to 2012 and is manually
> >> entered.  Why can't that automatically be generated?  It would be nice
> >> to do this so that when one builds/installs the latest version, upon
> >> launching the program it is immediate clear that the install process was
> >> successful by looking at the "last modified" date.
> >>
> >> Here are some approaches that could be tried:
> >>
> >> 1) There is this configure.in file containing:
> >>
> >> dnl $Id: configure.in,v 1.332 2013/07/18 23:22:17 sfeam Exp $
> >>
> >> Is that file somehow generated by the CVS/repository to reflect the most
> >> recent modification of the repository?  If so, that would be great as it
> >> would also contain a time stamp.  Could write a script to search for
> >> that and define LAST_MODIFIED in some header file using the extracted
> >> "2013/07/18 23:22:17" string.
> >>
> >> 2) Is there some way during make to get the most recent date of all the
> >> pertinent files?  "make" does date checking, so perhaps there is a make
> >> variable/macro that reflects that.
> >>
> >> 3) Similar to #2, we could maybe write an OS script that does the same
> >> thing by looking for the date of the most recent file in the source tree.
> >>
> >> 4) Ethan keeps the ChangeLog up to date.  It would be easy to search for
> >> the most recent date near the top of the file and use that as a
> >> definition for LAST_MODIFIED.
> >
> > The file .../src/Makefile.maint exists for exactly this purpose.
> > It updates the version string based on the most recent date in ChangeLog.
> > This file is included during "make" by gnu make.
> > Possibly you are using some other make program?
> >
> > 	Ethan
> 
> Well, I see the file Makefile.maint, but I'm not sure what I'm looking 
> at.  I see some THIS_VERSION, PREV_VERSION , etc. but I don't know how 
> that ties into what I see in the source code.  In show.c is the line:
> 
>      fprintf(fp, fmt,
> 	    p,			/* empty line */
> 	    p, PROGRAM,
> 	    p, gnuplot_version, gnuplot_patchlevel, gnuplot_date,
> 
> in which gnuplot_date is the "last modified" date.  And that variable 
> comes from version.c, i.e.,
> 
> const char gnuplot_date[] = "2012-06-19 ";
> 
> but I can't find anything in a make file that indicates gnuplot_date[] 
> is automatically generated.  One has to manually change that, correct?

No. 
It is automatically updated during "make".
I've never had any problem with this, so I don't know what might be going
wrong on your machine.

Here's what I see:

chauvet [92] make version.o
Making version.c
sed -e '/^const char gnuplot_date/ s/"[^"]*"/"2013-07-25 "/' \
            version.c > version.ct;
mv version.ct version.c
gcc -DHAVE_CONFIG_H -I. -I..  -I../term -I../term -DBINDIR=\"/usr/local/bin\" -DX11_DRIVER_DIR=\"/usr/local/libexec/gnuplot/4.7\" -DQT_DRIVER_DIR=\"/usr/local/libexec/gnuplot/4.7\" -DGNUPLOT_SHARE_DIR=\"/usr/local/share/gnuplot/4.7\" -DGNUPLOT_PS_DIR=\"/usr/local/share/gnuplot/4.7/PostScript\" -DGNUPLOT_JS_DIR=\"/usr/local/share/gnuplot/4.7/js\" -DGNUPLOT_LUA_DIR=\"/usr/local/share/gnuplot/4.7/lua\" -DCONTACT=\"gnu...@li...\" -DHELPFILE=\"/usr/local/share/gnuplot/4.7/gnuplot.gih\" -DGNUPLOT_X11=\"`echo gnuplot_x11 | sed 's,x,x,'`\" -DXAPPLRESDIR=\"/etc/X11/app-defaults/\"  -I/usr/local/include -I/usr/local/include   -pthread -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include   -pthread -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include    -g -O2 -MT version.o -MD -MP -MF .deps/version.Tpo -c -o version.o version.c
mv -f .deps/version.Tpo .deps/version.Po

 
> I do see at the top of the file version.c:
> 
> #ifndef lint
> static char *RCSid() { return RCSid("$Id: version.c,v 1.107 2013/02/26 
> 23:38:42 sfeam Exp $"); }
> #endif
> 
> which looks like it has something to do with revision control system, 
> but perhaps on a single file basis.  We would want something on a 
> project-wide basis.  Is that what configure.in is?

No. That is something else entirely, not relevant to the current issue.

Re: Automatically keeping "last modified" up to date

[Allin C. <cot...@wf...>]

On Tue, 6 Aug 2013, Ethan Merritt wrote:

> On Tuesday, August 06, 2013 10:25:33 am Daniel J Sebald wrote:
>> I just built the most recent version of gnuplot and noticed that the
>> "last modified" date in the intro refers back to 2012 and is manually
>> entered.  Why can't that automatically be generated?  It would be nice
>> to do this so that when one builds/installs the latest version, upon
>> launching the program it is immediate clear that the install process was
>> successful by looking at the "last modified" date.
>>
>> Here are some approaches that could be tried:
>>
>> 1) There is this configure.in file containing:
>>
>> dnl $Id: configure.in,v 1.332 2013/07/18 23:22:17 sfeam Exp $
>>
>> Is that file somehow generated by the CVS/repository to reflect the most
>> recent modification of the repository?  If so, that would be great as it
>> would also contain a time stamp.  Could write a script to search for
>> that and define LAST_MODIFIED in some header file using the extracted
>> "2013/07/18 23:22:17" string.
>>
>> 2) Is there some way during make to get the most recent date of all the
>> pertinent files?  "make" does date checking, so perhaps there is a make
>> variable/macro that reflects that.
>>
>> 3) Similar to #2, we could maybe write an OS script that does the same
>> thing by looking for the date of the most recent file in the source tree.
>>
>> 4) Ethan keeps the ChangeLog up to date.  It would be easy to search for
>> the most recent date near the top of the file and use that as a
>> definition for LAST_MODIFIED.
>
> The file .../src/Makefile.maint exists for exactly this purpose.
> It updates the version string based on the most recent date in ChangeLog.
> This file is included during "make" by gnu make.
> Possibly you are using some other make program?

I think there's something wrong with this. I definitely use 
gnu make, but sometimes when I update from CVS, do prepare, 
configure and make, I get a "last modified" date that is 
(e.g.) 6 months ago and clearly wrong.

There's one other fishy thing in that neighborhood. When I do 
a cvs update it seems I quite often get the cvs 'M' flag 
indicating that src/version.c is modified, when I certainly 
haven't edited that file.

Allin Cottrell

Re: Automatically keeping "last modified" up to date

[Daniel J S. <dan...@ie...>]

On 08/06/2013 01:39 PM, Ethan Merritt wrote:
> On Tuesday, August 06, 2013 10:25:33 am Daniel J Sebald wrote:
>> I just built the most recent version of gnuplot and noticed that the
>> "last modified" date in the intro refers back to 2012 and is manually
>> entered.  Why can't that automatically be generated?  It would be nice
>> to do this so that when one builds/installs the latest version, upon
>> launching the program it is immediate clear that the install process was
>> successful by looking at the "last modified" date.
>>
>> Here are some approaches that could be tried:
>>
>> 1) There is this configure.in file containing:
>>
>> dnl $Id: configure.in,v 1.332 2013/07/18 23:22:17 sfeam Exp $
>>
>> Is that file somehow generated by the CVS/repository to reflect the most
>> recent modification of the repository?  If so, that would be great as it
>> would also contain a time stamp.  Could write a script to search for
>> that and define LAST_MODIFIED in some header file using the extracted
>> "2013/07/18 23:22:17" string.
>>
>> 2) Is there some way during make to get the most recent date of all the
>> pertinent files?  "make" does date checking, so perhaps there is a make
>> variable/macro that reflects that.
>>
>> 3) Similar to #2, we could maybe write an OS script that does the same
>> thing by looking for the date of the most recent file in the source tree.
>>
>> 4) Ethan keeps the ChangeLog up to date.  It would be easy to search for
>> the most recent date near the top of the file and use that as a
>> definition for LAST_MODIFIED.
>
> The file .../src/Makefile.maint exists for exactly this purpose.
> It updates the version string based on the most recent date in ChangeLog.
> This file is included during "make" by gnu make.
> Possibly you are using some other make program?
>
> 	Ethan

Well, I see the file Makefile.maint, but I'm not sure what I'm looking 
at.  I see some THIS_VERSION, PREV_VERSION , etc. but I don't know how 
that ties into what I see in the source code.  In show.c is the line:

     fprintf(fp, fmt,
	    p,			/* empty line */
	    p, PROGRAM,
	    p, gnuplot_version, gnuplot_patchlevel, gnuplot_date,

in which gnuplot_date is the "last modified" date.  And that variable 
comes from version.c, i.e.,

const char gnuplot_date[] = "2012-06-19 ";

but I can't find anything in a make file that indicates gnuplot_date[] 
is automatically generated.  One has to manually change that, correct?

I do see at the top of the file version.c:

#ifndef lint
static char *RCSid() { return RCSid("$Id: version.c,v 1.107 2013/02/26 
23:38:42 sfeam Exp $"); }
#endif

which looks like it has something to do with revision control system, 
but perhaps on a single file basis.  We would want something on a 
project-wide basis.  Is that what configure.in is?

Dan

Re: Automatically keeping "last modified" up to date

[Ethan M. <merritt@u.washington.edu>]

On Tuesday, August 06, 2013 10:25:33 am Daniel J Sebald wrote:
> I just built the most recent version of gnuplot and noticed that the 
> "last modified" date in the intro refers back to 2012 and is manually 
> entered.  Why can't that automatically be generated?  It would be nice 
> to do this so that when one builds/installs the latest version, upon 
> launching the program it is immediate clear that the install process was 
> successful by looking at the "last modified" date.
> 
> Here are some approaches that could be tried:
> 
> 1) There is this configure.in file containing:
> 
> dnl $Id: configure.in,v 1.332 2013/07/18 23:22:17 sfeam Exp $
> 
> Is that file somehow generated by the CVS/repository to reflect the most 
> recent modification of the repository?  If so, that would be great as it 
> would also contain a time stamp.  Could write a script to search for 
> that and define LAST_MODIFIED in some header file using the extracted 
> "2013/07/18 23:22:17" string.
> 
> 2) Is there some way during make to get the most recent date of all the 
> pertinent files?  "make" does date checking, so perhaps there is a make 
> variable/macro that reflects that.
> 
> 3) Similar to #2, we could maybe write an OS script that does the same 
> thing by looking for the date of the most recent file in the source tree.
> 
> 4) Ethan keeps the ChangeLog up to date.  It would be easy to search for 
> the most recent date near the top of the file and use that as a 
> definition for LAST_MODIFIED.

The file .../src/Makefile.maint exists for exactly this purpose.
It updates the version string based on the most recent date in ChangeLog.
This file is included during "make" by gnu make.  
Possibly you are using some other make program?

	Ethan



> 
> Dan
> 
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead. 
> Download for free and get started troubleshooting in minutes. 
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
University of Washington, Seattle 98195-7742