gnuplot-beta

Automatically keeping "last modified" up to date

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

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.

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

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

[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

[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

[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

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

[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

[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

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

[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: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

[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

[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

[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: 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: Automatically keeping "last modified" up to date

[Juhász P. <pet...@gm...>]

On Wed, 2013-08-07 at 09:42 +0100, Allin Cottrell wrote:
> 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.
> 

My 2 cents:

The technical issue we have here is rooted in a deeper matter of
principle. In any source repository there may be source files that are
"static" in the sense that they are not changed during the make process
and fed to the compiler as is, and template files, which are not
compiled directly, but some process generates the required source files
from them. Version.c, as we have it now, tries to be both: there is a
magical process in place that modifies it with the current date, but it
happens to be compilable without modification (likely because someone
have checked in a processed version to the repository earlier).

There ought to be a separation between the two kinds of files, one that
is clearly reflected in the naming convention.
So the one and only file in the repository should be a template file,
called version.c.templ or something, and the magical update process
should create from it the source file version.c, which should not be
under version control. This magical process would substitute the current
date into the file, as it does now, but, in extreme cases where there is
no sed available etc., it could fall back to simply copying the contents
of the file (which means that the default contents should be sensible
and compilable).

Peter Juhasz

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

The attached patch does the trick for me, but it probably fails 
for those same out-of-tree builds that were failing already.

It replaces the stuff currently in src/Makefile.maint with the following:
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
version.o: modification_date

modification_date: ../ChangeLog
        @echo Making $@
        echo "#undef LAST_MODIFIED" >> ../config.h
        echo "#define LAST_MODIFIED \"${last_change}\"" >> ../config.h
        echo "#define LAST_MODIFIED \"${last_change}\"" > modification_date
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

modification_date is declared a BUILT_FILE in Makefile.am so it gets 
created before anything else.

The main problem with this from my perspective is that if you touch
the ChangeLog at all, it triggers a rebuild of everything, not just version.o,
because it appends the date to config.h and everything depends on that.

I imagine there is a way to generate a new file at the top level that, 
like config.h, is considered OK to modify.  But I don't know how to do that.

If the people who don't like the current mechanism are happier with
this one, please help clean up the out-of-tree builds.
Is it just a matter of adding $(top_srcdir) etc throughout Makefile.maint?

	Ethan