gnulib strftime imported into Emacs

gnulib strftime imported into Emacs

[Paul Eggert]

OK, since the Windows build works with the other gnulib modules,
it's time to try the next one on the list, namely strftime.
I committed to the trunk the following, which migrates Emacs to use
an up-to-date strftime.  This will let us add support for
higher-resolution time stamps in format-time-string, among
other things.  In the patch quoted below, I omit the automatically
generated files.

For Windows I expect that HAVE_STDBOOL_H and HAVE__BOOL should
be 1 in config.h.  You no longer need to worry about HAVE_STRFTIME.
Also, the build procedure needs to be modified to take into account
the fact that strftime.c is now in lib, not in src.

I don't see any major problems here, but I'm not a Windows expert.

=== modified file 'ChangeLog'
--- ChangeLog	2011-01-30 19:22:02 +0000
+++ ChangeLog	2011-01-30 23:29:33 +0000
@@ -1,5 +1,21 @@
 2011-01-30  Paul Eggert  <eggert@cs.ucla.edu>
 
+	strftime: import from gnulib
+	* Makefile.in (GNULIB_MODULES): Add strftime.
+	* configure.in (AC_FUNC_STRFTIME, my_strftime): Remove; no longer
+	needed.
+	* aclocal.m4, configure, lib/Makefile.in, lib/gnulib.mk, m4/gl-comp.m4:
+	Regenerate.
+	* lib/strftime.c, lib/strftime.h, lib/stdbool.in.h: New files,
+	imported from gnulib.
+	* m4/strftime.m4, m4/stdbool.m4, m4/tm_gmtoff.m4: Likewise.
+	This incorporates many changes from gnulib, including simpler
+	handling of multibyte formats, porting to mingw32 and other
+	platforms, and support for higher-resolution time stamps.
+	Emacs does not yet use the higher-resolution interface.
+
+2011-01-30  Paul Eggert  <eggert@cs.ucla.edu>
+
 	gnulib: import mktime and move-if-change fixes from gnulib
 
 	* configure: Regenerate from the following.

=== modified file 'Makefile.in'
--- Makefile.in	2011-01-28 00:25:24 +0000
+++ Makefile.in	2011-01-30 22:41:19 +0000
@@ -330,7 +330,7 @@
 # Update modules from gnulib, for maintainers, who should have it in
 # $(gnulib_srcdir) (relative to $(srcdir) and should have build tools
 # as per $(gnulib_srcdir)/DEPENDENCIES.
-GNULIB_MODULES = dtoastr getopt-gnu mktime
+GNULIB_MODULES = dtoastr getopt-gnu mktime strftime
 GNULIB_TOOL_FLAGS = \
  --import --no-changelog --no-vc-files --makefile-name=gnulib.mk
 sync-from-gnulib: $(gnulib_srcdir)

=== modified file 'admin/ChangeLog'
--- admin/ChangeLog	2011-01-25 05:10:02 +0000
+++ admin/ChangeLog	2011-01-30 23:29:52 +0000
@@ -1,3 +1,8 @@
+2011-01-30  Paul Eggert  <eggert@cs.ucla.edu>
+
+	strftime: import from gnulib
+	* notes/copyright: strftime.c moved from src to lib.
+
 2011-01-25  Glenn Morris  <rgm@gnu.org>
 
 	* bzrmerge.el (bzrmerge-skip-regexp): New variable.

=== modified file 'admin/notes/copyright'
--- admin/notes/copyright	2011-01-25 04:08:28 +0000
+++ admin/notes/copyright	2011-01-30 22:41:19 +0000
@@ -635,7 +635,6 @@
     src/gmalloc.c
     src/md5.c
     src/md5.h
-    src/strftime.c
     src/termcap.c
     src/tparam.c
 

=== modified file 'configure.in'
--- configure.in	2011-01-25 04:08:28 +0000
+++ configure.in	2011-01-30 22:41:19 +0000
@@ -517,7 +517,7 @@
     machine=hp800 opsys=hpux11
     ## FIXME.  Peter O'Gorman reports that dumping using unexelf.o doesn't
     ## work either: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6811
-    CANNOT_DUMP=yes    
+    CANNOT_DUMP=yes
   ;;
 
   hppa*-*-linux-gnu* )
@@ -2675,8 +2675,6 @@
 gl_ASSERT_NO_GNULIB_TESTS
 gl_INIT
 
-AC_FUNC_STRFTIME
-
 # UNIX98 PTYs.
 AC_CHECK_FUNCS(grantpt)
 
@@ -3528,8 +3526,6 @@
 #endif
 #endif
 
-#define my_strftime nstrftime	/* for strftime.c */
-
 /* These default definitions are good for almost all machines.
    The exceptions override them in m/MACHINE.h.  */
 

=== modified file 'src/ChangeLog'
--- src/ChangeLog	2011-01-30 22:22:58 +0000
+++ src/ChangeLog	2011-01-30 22:58:16 +0000
@@ -1,5 +1,15 @@
 2011-01-30  Paul Eggert  <eggert@cs.ucla.edu>
 
+	strftime: import from gnulib
+	* Makefile.in (obj): Remove strftime.o, as gnulib now does this for us.
+	* deps.mk (strftime.o): Remove.
+	* editfns.c: Include <strftime.h>, supplied by gnulib.
+	(emacs_strftimeu): Remove decl.
+	(emacs_memftimeu): Use nstrftime (the gnulib name) rather than
+	emacs_strftimeu.
+	* config.in: Regenerate.
+	* strftime.c: Remove; we now use strftime from gnulib.
+
 	Use SSDATA when the context wants char *.
 	* alloc.c, buffer.c, bytecode.c, callproc.c, dired.c:
 	* dispnew.c, doc.c, editfns.c, emacs.c, fileio.c, filelock.c:

=== modified file 'src/Makefile.in'
--- src/Makefile.in	2011-01-25 04:08:28 +0000
+++ src/Makefile.in	2011-01-30 22:41:20 +0000
@@ -353,7 +353,7 @@
 	syntax.o $(UNEXEC_OBJ) bytecode.o \
 	process.o gnutls.o callproc.o \
 	region-cache.o sound.o atimer.o \
-	doprnt.o strftime.o intervals.o textprop.o composite.o md5.o xml.o \
+	doprnt.o intervals.o textprop.o composite.o md5.o xml.o \
 	$(MSDOS_OBJ) $(MSDOS_X_OBJ) $(NS_OBJ) $(CYGWIN_OBJ) $(FONT_OBJ)
 
 ## Object files used on some machine or other.

=== modified file 'src/deps.mk'
--- src/deps.mk	2011-01-25 04:08:28 +0000
+++ src/deps.mk	2011-01-30 22:41:20 +0000
@@ -168,7 +168,6 @@
    $(INTERVALS_H) \
    lisp.h $(config_h)
 sound.o: sound.c dispextern.h syssignal.h lisp.h $(config_h) atimer.h systime.h
-strftime.o: strftime.c $(config_h)
 syntax.o: syntax.c syntax.h buffer.h commands.h category.h character.h \
    keymap.h regex.h $(INTERVALS_H) lisp.h $(config_h)
 sysdep.o: sysdep.c syssignal.h systty.h systime.h syswait.h blockinput.h \

=== modified file 'src/editfns.c'
--- src/editfns.c	2011-01-30 22:17:44 +0000
+++ src/editfns.c	2011-01-30 22:48:52 +0000
@@ -45,6 +45,7 @@
 #endif
 
 #include <ctype.h>
+#include <strftime.h>
 
 #include "intervals.h"
 #include "buffer.h"
@@ -82,9 +83,6 @@
     (1000 - TM_YEAR_BASE <= (tm_year) && (tm_year) <= 9999 - TM_YEAR_BASE)
 #endif
 
-extern size_t emacs_strftimeu (char *, size_t, const char *,
-                               const struct tm *, int);
-
 #ifdef WINDOWSNT
 extern Lisp_Object w32_get_internal_run_time (void);
 #endif
@@ -1556,8 +1554,8 @@
    determine how many bytes would be written, use NULL for S and
    ((size_t) -1) for MAXSIZE.
 
-   This function behaves like emacs_strftimeu, except it allows null
-   bytes in FORMAT.  */
+   This function behaves like nstrftime, except it allows null
+   bytes in FORMAT and it does not support nanoseconds.  */
 static size_t
 emacs_memftimeu (char *s, size_t maxsize, const char *format, size_t format_len, const struct tm *tp, int ut)
 {
@@ -1566,7 +1564,7 @@
   /* Loop through all the null-terminated strings in the format
      argument.  Normally there's just one null-terminated string, but
      there can be arbitrarily many, concatenated together, if the
-     format contains '\0' bytes.  emacs_strftimeu stops at the first
+     format contains '\0' bytes.  nstrftime stops at the first
      '\0' byte so we must invoke it separately for each such string.  */
   for (;;)
     {
@@ -1576,7 +1574,7 @@
       if (s)
 	s[0] = '\1';
 
-      result = emacs_strftimeu (s, maxsize, format, tp, ut);
+      result = nstrftime (s, maxsize, format, tp, ut, 0);
 
       if (s)
 	{

Re: gnulib strftime imported into Emacs

[Eli Zaretskii]

> Date: Sun, 30 Jan 2011 15:43:04 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> OK, since the Windows build works with the other gnulib modules,
> it's time to try the next one on the list, namely strftime.
> I committed to the trunk the following, which migrates Emacs to use
> an up-to-date strftime.  This will let us add support for
> higher-resolution time stamps in format-time-string, among
> other things.  In the patch quoted below, I omit the automatically
> generated files.
> 
> For Windows I expect that HAVE_STDBOOL_H and HAVE__BOOL should
> be 1 in config.h.  You no longer need to worry about HAVE_STRFTIME.
> Also, the build procedure needs to be modified to take into account
> the fact that strftime.c is now in lib, not in src.
> 
> I don't see any major problems here, but I'm not a Windows expert.

One major problem is that the Windows build is broken again, and will
probably remain broken till the next weekend, because I don't think
I'll have time to work on this until then.  (Volunteers are welcome to
beat me to it, but the experience of the last week shows they don't.)
It also means that Tom will have to wait for yet another week with his
threading related changes, at least that's what I'm asking.

Could we please talk before making such disruptive changes in the
future?  Ideally, Windows related changes should be committed to the
repository at approximately the same time as the changes for Posix
platforms, but that's only possible if you let me see the changes
_before_ they are committed, and if we coordinate the commit to happen
when I have time to work on that.  Is such cooperation possible?

Re: gnulib strftime imported into Emacs

[Paul Eggert]

On 01/30/2011 08:00 PM, Eli Zaretskii wrote:

> Could we please talk before making such disruptive changes in the
> future?

We did talk; for example,
<http://lists.gnu.org/archive/html/emacs-devel/2011-01/msg01025.html>.
I thought this was enough, but apparently I was mistaken.

> Ideally, Windows related changes should be committed to the
> repository at approximately the same time as the changes for Posix
> platforms, but that's only possible if you let me see the changes
> _before_ they are committed, and if we coordinate the commit to happen
> when I have time to work on that.  Is such cooperation possible?

I worry that this would mean that every time I want to make a
nontrivial change to a makefile, I would have to run the exact change
by you first.  And, as you say, you don't have much free time, and can't be
expected to respond quickly; it might need to wait until the next weekend,
say.  That wouldn't be a good recipe for development; it would slow things
down too much on the trunk.

If this turns into a continuing problem, perhaps it would be better to establish
a branch for Microsoft-related platforms, and to merge changes from the trunk
into that branch whenever you have time.  People could then do Microsoft builds
from that branch.

> It also means that Tom will have to wait for yet another week with his
> threading related changes

Sorry, I don't get the connection.  Tom can't put in his threading
related changes until Emacs builds on Microsoft platforms?

Re: gnulib strftime imported into Emacs

[joakim]

Paul Eggert <eggert@cs.ucla.edu> writes:

> On 01/30/2011 08:00 PM, Eli Zaretskii wrote:
>
>> Could we please talk before making such disruptive changes in the
>> future?
>
> We did talk; for example,
> <http://lists.gnu.org/archive/html/emacs-devel/2011-01/msg01025.html>.I thought this was enough, but apparently I was mistaken.
>
>> Ideally, Windows related changes should be committed to the
>> repository at approximately the same time as the changes for Posix
>> platforms, but that's only possible if you let me see the changes
>> _before_ they are committed, and if we coordinate the commit to happen
>> when I have time to work on that.  Is such cooperation possible?
>
> I worry that this would mean that every time I want to make a
> nontrivial change to a makefile, I would have to run the exact change
> by you first.  And, as you say, you don't have much free time, and can't be
> expected to respond quickly; it might need to wait until the next weekend,
> say.  That wouldn't be a good recipe for development; it would slow things
> down too much on the trunk.
>
> If this turns into a continuing problem, perhaps it would be better to establish
> a branch for Microsoft-related platforms, and to merge changes from the trunk
> into that branch whenever you have time.  People could then do Microsoft builds
> from that branch.
>
>> It also means that Tom will have to wait for yet another week with his
>> threading related changes
>
> Sorry, I don't get the connection.  Tom can't put in his threading
> related changes until Emacs builds on Microsoft platforms?

Emacs doesnt seem to have a spelled out policy but the following
approach is liked by many projects:
- commits to trunk should not knowingly break compilation
- feature development occurs on branches and are merged to trunk when
apropriate

The problem with this approach for Emacs is that it is very difficult
to test all configurations, so one can't be very sure even seemingly
trivial changes wont break compilation.

I have a Hudson continuous build server for Emacs now, building a couple
of branches on Fedora 14. I intend to set up a couple of more build
slaves for different platforms. I can reasonably expect to be able to
provide slaves for a couple of gnu/linux distributions, windows, dos,
osx, and some ARM based platform.

This won't happen soonish so it won't solve short term issues. Anyway,
in the end it will be possible for a developer to be reasonably sure a
feature branch wont break trunk builds on any supported platforms when
merged.

I'm aware that this subject is somewhat sensitive and there are various
opinions how trunk should be used etc. I'm not claiming a mandate to
enforce a policy, only offering to provide a service to enable a
particular strategy that doesn't exclude others.

-- 
Joakim Verona

Re: gnulib strftime imported into Emacs

[Miles Bader]

joakim@verona.se writes:
> The problem with this approach for Emacs is that it is very difficult
> to test all configurations, so one can't be very sure even seemingly
> trivial changes wont break compilation.

I'd be happy if people always tested before committing with at least
_one_ configuration (e.g., their own)...!

-miles

-- 
Carefully crafted initial estimates reward you not only with
reduced computational effort, but also with understanding and
increased self-esteem.         -- Numerical methods in C,
  Chapter 9. "Root Finding and Nonlinear Sets of Equations"

Re: gnulib strftime imported into Emacs

[joakim]

Miles Bader <miles@gnu.org> writes:

> joakim@verona.se writes:
>> The problem with this approach for Emacs is that it is very difficult
>> to test all configurations, so one can't be very sure even seemingly
>> trivial changes wont break compilation.
>
> I'd be happy if people always tested before committing with at least
> _one_ configuration (e.g., their own)...!

Well, I'm normally impressed with the quality of Emacs trunk. It's
normaly higher than many commercial projects I partake in.

Thats no excuse for not improving the quality further of course.

> -miles

-- 
Joakim Verona

Re: gnulib strftime imported into Emacs

[Miles Bader]

joakim@verona.se writes:
>> I'd be happy if people always tested before committing with at least
>> _one_ configuration (e.g., their own)...!
>
> Well, I'm normally impressed with the quality of Emacs trunk. It's
> normaly higher than many commercial projects I partake in.

It's not too bad, considering.

Still, obviously-not-tested changes are kinda annoying..

-miles

-- 
Egotist, n. A person of low taste, more interested in himself than in me.

Re: gnulib strftime imported into Emacs

[Eli Zaretskii]

> Date: Mon, 31 Jan 2011 00:02:21 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: emacs-devel@gnu.org
> 
> On 01/30/2011 08:00 PM, Eli Zaretskii wrote:
> 
> > Could we please talk before making such disruptive changes in the
> > future?
> 
> We did talk; for example,
> <http://lists.gnu.org/archive/html/emacs-devel/2011-01/msg01025.html>.
> I thought this was enough, but apparently I was mistaken.

That was a general heads-up (thanks!).  I'm talking about actually
saying something like "I'm about to commit changes that will break the
Windows build."

> I worry that this would mean that every time I want to make a
> nontrivial change to a makefile, I would have to run the exact change
> by you first.

I didn't ask to run every nontrivial change by me.  Inadvertent
breakage is a fact of life, and cannot be helped.  I'm talking only
about changes that are known in advance to break some platform, and
for which you are not providing the corresponding changes as part of
the changeset.  I'm asking whether it would be possible to talk a
short while before committing such changes, when you already have your
feature branch ready to merge onto the trunk.

> And, as you say, you don't have much free time, and can't be
> expected to respond quickly; it might need to wait until the next
> weekend

I usually respond to email within a few hours.  In extreme rare cases,
it could take a day.  So the response will be fast.  If the change
needs non-trivial corresponding changes in the Windows build process,
I might indeed ask to wait a few days.

And it's not just me personally.  There are others on this list who
could (and hopefully would) pick up the gauntlet and provide the fix
as fast as possible.

> That wouldn't be a good recipe for development; it would slow things
> down too much on the trunk.

Emacs 24 is still very far from a release, so why is it important to
commit changes urgently (except changes that fix bad bugs)?  We are
using a dVCS now, so waiting with a changeset should not slow down
others, nor even you yourself, with any further development.  Am I
missing something?

> If this turns into a continuing problem

It wasn't until now.  I don't see why it has to become a continuing
problem.

> perhaps it would be better to establish a branch for
> Microsoft-related platforms, and to merge changes from the trunk
> into that branch whenever you have time.  People could then do
> Microsoft builds from that branch.

I'm talking only about Windows (and any other radically different
platforms whose builds you cannot test).  MS-DOS is not related to
this.  No MS-DOS users except myself are tracking the trunk
development, so the MS-DOS build can stay broken for as much as I can
afford.

I think a separate branch for Windows is unjustified, but if we are
talking separate branches, an alternative would be to establish a
separate branch for synchronizing with gnulib, and only merge it to
the trunk when all major supported platforms are known to build on
that branch.  (FWIW, that's what I did before merging the bidi
support.)  Judging by the last week's experience, the number of people
who get annoyed by not being able to build the latest trunk on Windows
is not negligible (I myself generally build only on weekends), so a
non-urgent change that will certainly break it could be first
committed to a public branch.

> > It also means that Tom will have to wait for yet another week with his
> > threading related changes
> 
> Sorry, I don't get the connection.  Tom can't put in his threading
> related changes until Emacs builds on Microsoft platforms?

The threading changes are certain to break any platform where Tom is
unable to test, and in fact the error messages during the build are
the main device to find the way of making those changes work on any
given platform (IIUC).  So I asked Tom to postpone his commit until
the Windows build is working again.  Otherwise, it would be very hard
to know how to fix the threading changes on Windows when there are two
or more possible reasons for error messages.  Tom asked to give him a
notice when the Windows build becomes usable again, which I did two
days ago.  Now I must again ask Tom to wait, for the same reason.

Re: gnulib strftime imported into Emacs

[Lennart Borgman]

On Mon, Jan 31, 2011 at 9:02 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:
>
>> Ideally, Windows related changes should be committed to the
>> repository at approximately the same time as the changes for Posix
>> platforms, but that's only possible if you let me see the changes
>> _before_ they are committed, and if we coordinate the commit to happen
>> when I have time to work on that.  Is such cooperation possible?
>
> I worry that this would mean that every time I want to make a
> nontrivial change to a makefile, I would have to run the exact change
> by you first.  And, as you say, you don't have much free time, and can't be
> expected to respond quickly; it might need to wait until the next weekend,
> say.  That wouldn't be a good recipe for development; it would slow things
> down too much on the trunk.
>
> If this turns into a continuing problem, perhaps it would be better to establish
> a branch for Microsoft-related platforms, and to merge changes from the trunk
> into that branch whenever you have time.  People could then do Microsoft builds
> from that branch.

The problem is not that things are submitted for w32 that breaks the
trunk for others. The problem is that things are submitted to the
trunk that you know breaks the w32 build. So AFAICS it will not help
at all having a special w32 branch. It will just create much more work
for nearly everyone. Or do you think differently?


I did suggest before that you establish a branch for things that you
know might break the build. Are there any problems for you doing that
for changes that you know beaks builds on other systems than those you
know?


Could you please revert the last submit to the trunk that breaks the
w32 build? (I think it is a good change, but not on the trunk until it
works for w32.)

I am glad you

Re: gnulib strftime imported into Emacs

[Eli Zaretskii]

> From: joakim@verona.se
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> Date: Mon, 31 Jan 2011 10:44:09 +0100
> 
> The problem with this approach for Emacs is that it is very difficult
> to test all configurations, so one can't be very sure even seemingly
> trivial changes wont break compilation.

I'm only talking about changes that are known in advance to
unconditionally break some platform.  I think it's unreasonable to
request anything more than that, since we are all volunteers working
on our free time.

> I have a Hudson continuous build server for Emacs now, building a couple
> of branches on Fedora 14. I intend to set up a couple of more build
> slaves for different platforms. I can reasonably expect to be able to
> provide slaves for a couple of gnu/linux distributions, windows, dos,
> osx, and some ARM based platform.

That'd be great, thanks.

Re: gnulib strftime imported into Emacs

[Andy Moreton]

On Mon 31 Jan 2011, Paul Eggert wrote:

> On 01/30/2011 08:00 PM, Eli Zaretskii wrote:
>
>> Could we please talk before making such disruptive changes in the
>> future?
>
> We did talk; for example,
> <http://lists.gnu.org/archive/html/emacs-devel/2011-01/msg01025.html>.
> I thought this was enough, but apparently I was mistaken.

That discussion seems to be an agreement in principle, not a concrete
set of changes. It would help if you published the actual patch, or a
location where it may be found, together with a description of the
change. This allows changes to be reviewed before they break the build.

>> Ideally, Windows related changes should be committed to the
>> repository at approximately the same time as the changes for Posix
>> platforms, but that's only possible if you let me see the changes
>> _before_ they are committed, and if we coordinate the commit to happen
>> when I have time to work on that.  Is such cooperation possible?
>
> I worry that this would mean that every time I want to make a
> nontrivial change to a makefile, I would have to run the exact change
> by you first.  And, as you say, you don't have much free time, and can't be
> expected to respond quickly; it might need to wait until the next weekend,
> say.  That wouldn't be a good recipe for development; it would slow things
> down too much on the trunk.

While the desire to avoid a slowdown is entirely reasonable, there is
another more important principle in any software development: do not
break the build. It happens occasionally due to an overlooked issue or a
bug, but it should never be done knowingly.

Your current approach is lilely to leave the Win32 build broken more
often than not, which is unhelpful.

> If this turns into a continuing problem, perhaps it would be better to establish
> a branch for Microsoft-related platforms, and to merge changes from the trunk
> into that branch whenever you have time.  People could then do Microsoft builds
> from that branch.

The Win32 does not need a separate branch as it is not diverging from
the main tree. It does need a little cooperation from developers on
POSIX systems to ensure that changes are coordinated where possible.

>> It also means that Tom will have to wait for yet another week with his
>> threading related changes
>
> Sorry, I don't get the connection.  Tom can't put in his threading
> related changes until Emacs builds on Microsoft platforms?

There is no point integrating a change that breaks the build if the build
is already broken...

    AndyM

Re: gnulib strftime imported into Emacs

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Mon, 31 Jan 2011 12:17:32 +0100
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> 
> Could you please revert the last submit to the trunk that breaks the
> w32 build?

I think this would be too radical and unnecessary (and extremely
unkind to Paul).  After all, "bzr revert -r103046" after updating from
the repository, will set you up for the Windows build.

Re: gnulib strftime imported into Emacs

[Lennart Borgman]

On Mon, Jan 31, 2011 at 12:37 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Lennart Borgman <lennart.borgman@gmail.com>
>> Date: Mon, 31 Jan 2011 12:17:32 +0100
>> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
>>
>> Could you please revert the last submit to the trunk that breaks the
>> w32 build?
>
> I think this would be too radical and unnecessary (and extremely
> unkind to Paul).  After all, "bzr revert -r103046" after updating from
> the repository, will set you up for the Windows build.


Thanks I will try that for now.

But that will only work as long as there are no other changes that
depends on this commit, or?

I do not want to be unkind to Paul. I understand that the changes are
necessary and I am very glad that he is doing this. However having a
temporary branch for things that is known to break other builds would
perhaps be much easier. Or is that much extra work for you, Paul?

Re: gnulib strftime imported into Emacs

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Mon, 31 Jan 2011 12:52:33 +0100
> Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org
> 
> > "bzr revert -r103046" after updating from the repository, will set
> > you up for the Windows build.
> 
> 
> Thanks I will try that for now.
> 
> But that will only work as long as there are no other changes that
> depends on this commit, or?

It will prevent you from using all the revisions after 103046, yes.
It is possible to do better by reverse cherry-picking r103047 (see
"bzr help merge"), but I don't recommend that, since it will make your
regular updates more complicated and error-prone, and the problem will
be likely fixed soon.

Re: gnulib strftime imported into Emacs

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> It will prevent you from using all the revisions after 103046, yes.
> It is possible to do better by reverse cherry-picking r103047 (see
> "bzr help merge"), but I don't recommend that, since it will make your
> regular updates more complicated and error-prone, and the problem will
> be likely fixed soon.

Though git makes it very easy to maintain such local changes.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: gnulib strftime imported into Emacs

[Lennart Borgman]

On Mon, Jan 31, 2011 at 2:01 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Lennart Borgman <lennart.borgman@gmail.com>
>> Date: Mon, 31 Jan 2011 12:52:33 +0100
>> Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org
>>
>> > "bzr revert -r103046" after updating from the repository, will set
>> > you up for the Windows build.
>>
>>
>> Thanks I will try that for now.
>>
>> But that will only work as long as there are no other changes that
>> depends on this commit, or?
>
> It will prevent you from using all the revisions after 103046, yes.


So it will makes it possible that other problems also jumps in and
makes things even more complicated when trying to fix things again?
(Since you can not check new things until r103046 is fixed.)

That sounds very troublesome to me.

Re: gnulib strftime imported into Emacs

[Tom Tromey]

Eli> Now I must again ask Tom to wait, for the same reason.

Let me know when it is ok.

Tom

Re: gnulib strftime imported into Emacs

[Eli Zaretskii]

> From: Tom Tromey <tromey@redhat.com>
> Cc: Paul Eggert <eggert@cs.ucla.edu>, emacs-devel@gnu.org
> Date: Mon, 31 Jan 2011 07:30:20 -0700
> 
> Eli> Now I must again ask Tom to wait, for the same reason.
> 
> Let me know when it is ok.

Will do, and sorry for the additional delay.

Re: gnulib strftime imported into Emacs

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Lennart Borgman <lennart.borgman@gmail.com>,  eggert@cs.ucla.edu,  emacs-devel@gnu.org
> Date: Mon, 31 Jan 2011 14:17:52 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > It will prevent you from using all the revisions after 103046, yes.
> > It is possible to do better by reverse cherry-picking r103047 (see
> > "bzr help merge"), but I don't recommend that, since it will make your
> > regular updates more complicated and error-prone, and the problem will
> > be likely fixed soon.
> 
> Though git makes it very easy to maintain such local changes.

As does bzr, but if Lennart doesn't already know how to do that, I
wouldn't suggest to learn now.

Re: gnulib strftime imported into Emacs

[Eli Zaretskii]

> From: Eli Zaretskii <eliz@gnu.org>
> Date: Mon, 31 Jan 2011 08:01:19 -0500
> Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org
> Reply-To: Eli Zaretskii <eliz@gnu.org>
> 
> > From: Lennart Borgman <lennart.borgman@gmail.com>
> > Date: Mon, 31 Jan 2011 12:52:33 +0100
> > Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org
> > 
> > > "bzr revert -r103046" after updating from the repository, will set
> > > you up for the Windows build.
> > 
> > 
> > Thanks I will try that for now.
> > 
> > But that will only work as long as there are no other changes that
> > depends on this commit, or?
> 
> It will prevent you from using all the revisions after 103046, yes.

For the record: I made a mistake with the revision: it's 103036.

Re: gnulib strftime imported into Emacs

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andreas Schwab <schwab@linux-m68k.org>
>> Cc: Lennart Borgman <lennart.borgman@gmail.com>,  eggert@cs.ucla.edu,  emacs-devel@gnu.org
>> Date: Mon, 31 Jan 2011 14:17:52 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > It will prevent you from using all the revisions after 103046, yes.
>> > It is possible to do better by reverse cherry-picking r103047 (see
>> > "bzr help merge"), but I don't recommend that, since it will make your
>> > regular updates more complicated and error-prone, and the problem will
>> > be likely fixed soon.
>> 
>> Though git makes it very easy to maintain such local changes.
>
> As does bzr,

If "It will prevent you from using all the revisions after 103046", then
it doesn't.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: gnulib strftime imported into Emacs

[Eli Zaretskii]

> Date: Sun, 30 Jan 2011 15:43:04 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> I committed to the trunk the following, which migrates Emacs to use
> an up-to-date strftime.

I found one unfortunate problem with your commit: it seems that you
"bzr remove"d src/strftime.c and then "bzr add"ed lib/strftime.c.
This means that all the previous revision history of strftime.c in the
Emacs repository is now effectively lost.  I think the Right Way to do
this is "bzr mv" (since Bazaar tracks file renames as atomic
operations).

It may still be possible to recover the lost information, by
temporarily restoring the old src/strftime.c and then using "bzr mv"
to replace it with the gnulib version.  If someone knows how to do
that off-hand, please post the recipe.

Re: gnulib strftime imported into Emacs

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: lennart.borgman@gmail.com,  eggert@cs.ucla.edu,  emacs-devel@gnu.org
> Date: Mon, 31 Jan 2011 15:54:20 +0100
> 
> >> Though git makes it very easy to maintain such local changes.
> >
> > As does bzr,
> 
> If "It will prevent you from using all the revisions after 103046", then
> it doesn't.

Ah, but what is "it" in this sentence?

Re: gnulib strftime imported into Emacs

[Stefan Monnier]

> It may still be possible to recover the lost information, by
> temporarily restoring the old src/strftime.c and then using "bzr mv"
> to replace it with the gnulib version.  If someone knows how to do
> that off-hand, please post the recipe.

I've done just that in the following way:

  % bzr merge -r 103037..103036
  % bzr revert <everything except {src,lib}/strftime.c
  % cp lib/strftime.c lib/strftime.c.gnulib
  % bzr rm lib/strftime.c
  % bzr mv src/strftime.c lib/strftime.c
  % mv lib/strftime.c.gnulib lib/strftime.c
  % bzr commit


-- Stefan

Re: gnulib strftime imported into Emacs

[Eli Zaretskii]

> From: Eli Zaretskii <eliz@gnu.org>
> Date: Mon, 31 Jan 2011 09:43:27 -0500
> Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org
> 
> > From: Tom Tromey <tromey@redhat.com>
> > Cc: Paul Eggert <eggert@cs.ucla.edu>, emacs-devel@gnu.org
> > Date: Mon, 31 Jan 2011 07:30:20 -0700
> > 
> > Eli> Now I must again ask Tom to wait, for the same reason.
> > 
> > Let me know when it is ok.
> 
> Will do, and sorry for the additional delay.

Done.  I suggest to hurry up with your changes, lest someone beats you
to it (again) ;-)

Re: gnulib strftime imported into Emacs

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Mon, 31 Jan 2011 12:17:32 +0100
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> 
> (I think it is a good change, but not on the trunk until it works
> for w32.)

It should work for w32 now.

Re: gnulib strftime imported into Emacs

[Eli Zaretskii]

> Date: Mon, 31 Jan 2011 06:00:14 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> One major problem is that the Windows build is broken again

I think I fixed it now.

The new strftime needs careful testing on Windows; I did only a couple
of simple test cases.  If someone has time to compare some old
revision of Emacs 23.x with the new version on the trunk, please do.

Of course, if there are any other problems I left behind, please
report that as well.

Re: gnulib strftime imported into Emacs

[Eli Zaretskii]

> Date: Sun, 30 Jan 2011 15:43:04 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> For Windows I expect that HAVE_STDBOOL_H and HAVE__BOOL should
> be 1 in config.h.

I didn't find any place where these are used in the Emacs sources.
Can you please tell me what I missed?  TIA

Re: gnulib strftime imported into Emacs

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Paul Eggert <eggert@cs.ucla.edu>,  emacs-devel@gnu.org
> Date: Mon, 31 Jan 2011 11:56:01 -0500
> 
> > It may still be possible to recover the lost information, by
> > temporarily restoring the old src/strftime.c and then using "bzr mv"
> > to replace it with the gnulib version.  If someone knows how to do
> > that off-hand, please post the recipe.
> 
> I've done just that

Thanks.

>   % bzr revert <everything except {src,lib}/strftime.c

How do you do that?

Re: gnulib strftime imported into Emacs

[Stefan Monnier]

>> % bzr revert <everything except {src,lib}/strftime.c
> How do you do that?

First

  % bzr status

then

  % bzr revert <type here the files you see mentioned in the previous output>

;-)

I think my sed-foo was just strong enough to automate it, but the list
of files was too short to motivate me, so I did it by hand.


        Stefan

Re: gnulib strftime imported into Emacs

[Paul Eggert]

On 01/31/11 03:06, Eli Zaretskii wrote:

> I'm talking only about changes that are known in advance to break
> some platform, and for which you are not providing the corresponding
> changes as part of the changeset.  I'm asking whether it would be
> possible to talk a short while before committing such changes,

Sure, I can send out some email when I'm coding up changes.  It should
be easy to do that, as part of normal development.

> when you already have your feature branch ready to merge onto the trunk.

This part sounds too strict, though.  Normally it takes quite some
time to prepare the change precisely for the trunk.  I develop on RHEL
5.5 x86-64, but for nontrivial changes before committing I test on
several other platforms that I have easy access to, including at least
one non-GNU platform.  I don't want to have to do that work multiple
times, as it takes far more work to prepare and test the changes
than it does to code them up.

> If the change needs non-trivial corresponding changes in the Windows
> build process, I might indeed ask to wait a few days.

This part worries me.  Mainline Emacs development shouldn't be held
back because of a lack of resources to port it to Windows.

> Emacs 24 is still very far from a release, so why is it important to
> commit changes urgently (except changes that fix bad bugs)?

Because we want it as easy as possible to make improvements to Emacs.
There are many obstacles to improvements, and we can't remove all the
obstacles, but we should do that when it's easy, which ought to be the
case here.

The argument "it's far from a release" cuts the other way, actually.
If we were close to release, then we would be quite careful of
nontrivial changes regardless of platform, because we wouldn't have
time to try them out.  But now, when it *is* far from a release, it's
a good time to make this kind of change.  And we don't want to slow
that process down unnecessarily.

> We are using a dVCS now, so waiting with a changeset should not slow
> down others, nor even you yourself, with any further development.

Yes it would, because it would cost more integration and testing time,
for mainline developers.  Also it would slow us down in making further
improvements that depend on earlier improvements.  The burden of
integration and testing for Windows platforms should be on the people
contributing to the Windows ports, not on mainline developers.

> I don't see why it has to become a continuing problem.

I hope not too.

> I asked Tom to postpone his commit until the Windows build is
> working again.  Otherwise, it would be very hard to know how to fix
> the threading changes on Windows when there are two or more possible
> reasons for error messages.

If it's easier to test Windows builds with half of Tom's changes
first, then the Windows developers can do that.  This may make it a
bit harder on the Windows developers temporarily, but it's not that
hard: that is what version control is for.  However, if the difficulty
in doing the port to Windows is substantially slowing down Tom's
changes to Emacs proper, then there's something wrong with the overall
process, and we should fix that.  Tom shouldn't have to be waiting for
Windows developers to port his stuff.

Re: gnulib strftime imported into Emacs

[Lennart Borgman]

On Mon, Jan 31, 2011 at 11:19 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
> On 01/31/11 03:06, Eli Zaretskii wrote:
>
>> I'm talking only about changes that are known in advance to break
>> some platform, and for which you are not providing the corresponding
>> changes as part of the changeset.  I'm asking whether it would be
>> possible to talk a short while before committing such changes,
>
> Sure, I can send out some email when I'm coding up changes.  It should
> be easy to do that, as part of normal development.
>
>> when you already have your feature branch ready to merge onto the trunk.
>
> This part sounds too strict, though.  Normally it takes quite some
> time to prepare the change precisely for the trunk.  I develop on RHEL
> 5.5 x86-64, but for nontrivial changes before committing I test on
> several other platforms that I have easy access to, including at least
> one non-GNU platform.  I don't want to have to do that work multiple
> times, as it takes far more work to prepare and test the changes
> than it does to code them up.
>
>> If the change needs non-trivial corresponding changes in the Windows
>> build process, I might indeed ask to wait a few days.
>
> This part worries me.  Mainline Emacs development shouldn't be held
> back because of a lack of resources to port it to Windows.


I do not want to take part in the C coding, but I wonder if it would
help you if other people had a checkout of your branch on w32 and at
least could test it? Do you have tests for it that we could run on
w32? (If you have it would be a small problem for me to run some tests
on w32.)

Re: gnulib strftime imported into Emacs

[Paul Eggert]

On 01/31/11 11:54, Eli Zaretskii wrote:
>> From: Paul Eggert <eggert@cs.ucla.edu>
>>
>> For Windows I expect that HAVE_STDBOOL_H and HAVE__BOOL should
>> be 1 in config.h.
> 
> I didn't find any place where these are used in the Emacs sources.
> Can you please tell me what I missed?  TIA

On further investigation you're right, you shouldn't need to worry
about configuring these symbols on a platform that
already has stdbool.h, which I assume is true for Microsoft
platforms.

Re: gnulib strftime imported into Emacs

[Paul Eggert]

On 01/31/11 14:29, Lennart Borgman wrote:
> I wonder if it would
> help you if other people had a checkout of your branch on w32 and at
> least could test it? Do you have tests for it that we could run on
> w32?

I don't have a publishable branch right now.  What I have is a collection
of several branches, none of which build right now, each of which contains
ideas for improving Emacs.  When I get something coded up that builds,
and which I expect might break Windows, I was planning to email it to here,
and then Windows-oriented developers can take a quick look at it.

I don't have special tests.  As I understand it, there's no consensus
for how "make check" should operate for Emacs.  It would be nice if there
were a consensus and if I could add to an already-existing test procedure
as needed, but that's a different project.

Re: gnulib strftime imported into Emacs

[Lennart Borgman]

On Tue, Feb 1, 2011 at 12:57 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:
> On 01/31/11 14:29, Lennart Borgman wrote:
>> I wonder if it would
>> help you if other people had a checkout of your branch on w32 and at
>> least could test it? Do you have tests for it that we could run on
>> w32?
>
> I don't have a publishable branch right now.  What I have is a collection
> of several branches, none of which build right now, each of which contains
> ideas for improving Emacs.  When I get something coded up that builds,
> and which I expect might break Windows, I was planning to email it to here,
> and then Windows-oriented developers can take a quick look at it.

Perhaps it would be easier to publish the branch on Launchpad for
example? If you do that it is easy to automate the build so at least
the build process can be checked.


> I don't have special tests.  As I understand it, there's no consensus
> for how "make check" should operate for Emacs.

There is currently a test subdirectory in the repository. Can't you
put tests there?

Re: gnulib strftime imported into Emacs

[Paul Eggert]

On 01/31/11 16:15, Lennart Borgman wrote:
> Perhaps it would be easier to publish the branch on Launchpad for
> example? If you do that it is easy to automate the build so at least
> the build process can be checked.

Let's try doing it by patch-emailing first instead.  That's less work
for me, and I expect just as reliable.  If it doesn't work we can try
something else.

> There is currently a test subdirectory in the repository. Can't you
> put tests there?

Well, I'm no expert, but as I understand it, the existence of
the tests subdirectory is controversial, it's not much used or
maintained, and it's not distributed as part of Emacs.  I don't know why
it's there, as it was put in while I wasn't paying much attention
to Emacs development.  Perhaps a maintainer who knows its status
better can comment.

Besides, adding tests to the test subdirectory wouldn't have affected the issues
that started this thread.  The problem wasn't a bug in a built Emacs.
The problem was that Emacs didn't build under Windows.  I expect that
future issues in this area will be similar.

Re: gnulib strftime imported into Emacs

[Lennart Borgman]

On Tue, Feb 1, 2011 at 1:24 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:
> On 01/31/11 16:15, Lennart Borgman wrote:
>> Perhaps it would be easier to publish the branch on Launchpad for
>> example? If you do that it is easy to automate the build so at least
>> the build process can be checked.
>
> Let's try doing it by patch-emailing first instead.  That's less work
> for me, and I expect just as reliable.  If it doesn't work we can try
> something else.

Ok.


>> There is currently a test subdirectory in the repository. Can't you
>> put tests there?
>
> Well, I'm no expert, but as I understand it, the existence of
> the tests subdirectory is controversial, it's not much used or
> maintained, and it's not distributed as part of Emacs.

It has not been used much but it is our goal to add tests to Emacs.
(However it looks like it will not be distributed by prebuilt Emacs.
Which I personally think is unfortunate.)

> Besides, adding tests to the test subdirectory wouldn't have affected the issues
> that started this thread.  The problem wasn't a bug in a built Emacs.
> The problem was that Emacs didn't build under Windows.  I expect that
> future issues in this area will be similar.

I see. I thought the built Emacs needed testing too.

Re: gnulib strftime imported into Emacs

[Eli Zaretskii]

> Date: Mon, 31 Jan 2011 14:19:48 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: emacs-devel@gnu.org
> 
> On 01/31/11 03:06, Eli Zaretskii wrote:
> 
> > I'm talking only about changes that are known in advance to break
> > some platform, and for which you are not providing the corresponding
> > changes as part of the changeset.  I'm asking whether it would be
> > possible to talk a short while before committing such changes,
> 
> Sure, I can send out some email when I'm coding up changes.  It should
> be easy to do that, as part of normal development.

Thanks, this should make things easier and more smooth.

> > when you already have your feature branch ready to merge onto the trunk.
> 
> This part sounds too strict, though.  Normally it takes quite some
> time to prepare the change precisely for the trunk.

I understand that this is because you don't actually build on your
feature branches, but instead merge onto the trunk first, and build
there.  IMO, that's an inefficient workflow when using a dVCS.  If you
would build your feature branches, then merging onto the trunk would
be an easier job, that basically boils down to a short test of your
changes with the latest mainline code.  That testing does not need to
repeat all the elaborate tests you did on a branch, because a few days
worth of Emacs development cannot change the code too much.

> > If the change needs non-trivial corresponding changes in the Windows
> > build process, I might indeed ask to wait a few days.
> 
> This part worries me.  Mainline Emacs development shouldn't be held
> back because of a lack of resources to port it to Windows.

You could port it yourself.  Most of the changes are trivially ported,
especially for someone who knows such a great deal about gnulib.

> > Emacs 24 is still very far from a release, so why is it important to
> > commit changes urgently (except changes that fix bad bugs)?
> 
> Because we want it as easy as possible to make improvements to Emacs.

As easy as possible, but no easier.

> > We are using a dVCS now, so waiting with a changeset should not slow
> > down others, nor even you yourself, with any further development.
> 
> Yes it would, because it would cost more integration and testing time,
> for mainline developers.  Also it would slow us down in making further
> improvements that depend on earlier improvements.

Using feature branches better should all but eliminate this
difficulty.

> The burden of integration and testing for Windows platforms should
> be on the people contributing to the Windows ports, not on mainline
> developers.

I never requested anything else.  But a bit of cooperative spirit
won't hurt anyone.

Re: gnulib strftime imported into Emacs

[Eli Zaretskii]

> Date: Mon, 31 Jan 2011 15:25:59 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: emacs-devel@gnu.org
> 
> On 01/31/11 11:54, Eli Zaretskii wrote:
> >> From: Paul Eggert <eggert@cs.ucla.edu>
> >>
> >> For Windows I expect that HAVE_STDBOOL_H and HAVE__BOOL should
> >> be 1 in config.h.
> > 
> > I didn't find any place where these are used in the Emacs sources.
> > Can you please tell me what I missed?  TIA
> 
> On further investigation you're right, you shouldn't need to worry
> about configuring these symbols on a platform that
> already has stdbool.h, which I assume is true for Microsoft
> platforms.

MinGW does have it (it comes with GCC), but MSVC doesn't, AFAICS.  I
still don't see how a platform that doesn't have stdbool.h in its
system headers use these symbols.  Could you please elaborate?

Re: gnulib strftime imported into Emacs

[Paul Eggert]

On 01/31/2011 08:07 PM, Eli Zaretskii wrote:
> MinGW does have it (it comes with GCC), but MSVC doesn't, AFAICS.  I
> still don't see how a platform that doesn't have stdbool.h in its
> system headers use these symbols.  Could you please elaborate?

HAVE_STDBOOL_H isn't used at all; it's a remnant of Autoconf.
I am looking into removing it from Emacs; see
<http://lists.gnu.org/archive/html/bug-gnulib/2011-01/msg00571.html>.

HAVE__BOOL is used only in lib/stdbool.in.h, and its value
is relevant only on platforms that do not have a working
stdbool.h and do not define __cplusplus.  It sounds like
MinGW has stdbool.h.  If MSVC defines __cplusplus, then you also
do not need to worry; otherwise, the stdbool.h build
procedure should substitute 1 or 0 for @HAVE__BOOL@
when reading from stdbool.in.h, depending on whether
MSVC has built-in support for _Bool.

Re: gnulib strftime imported into Emacs

[Paul Eggert]

On 01/31/2011 08:05 PM, Eli Zaretskii wrote:

> I understand that this is because you don't actually build on your
> feature branches, but instead merge onto the trunk first, and build
> there.

No, I never build on my copy of the trunk.  I use that copy only to
install already-tested new source code and immediately commit the
result to Savannah; if that commit fails due to a nearly-simultaneous
trunk commit by someone else, I typically just revert my copy of the
trunk and start over.

>> Mainline Emacs development shouldn't be held
>> back because of a lack of resources to port it to Windows.
> 
> You could port it yourself.

No thank you.  The people who are interested in
maintaining the Windows port should do the Windows port.
The Windows port should not require mainline developers
to spend significant chunks of their time.

>>> We are using a dVCS now, so waiting with a changeset should not slow
>>> down others, nor even you yourself, with any further development.
>>
>> Yes it would, because it would cost more integration and testing time,
>> for mainline developers.  Also it would slow us down in making further
>> improvements that depend on earlier improvements.
> 
> Using feature branches better should all but eliminate this
> difficulty.

I don't see how.  Waiting means a slowdown.

Anyway, as I've said before, I'm hoping that this is
not necessary, and that we don't need to use separate branches
to support Microsoft ports.

Re: gnulib strftime imported into Emacs

[Eli Zaretskii]

> Date: Mon, 31 Jan 2011 22:25:34 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: emacs-devel@gnu.org
> 
> HAVE__BOOL is used only in lib/stdbool.in.h, and its value
> is relevant only on platforms that do not have a working
> stdbool.h and do not define __cplusplus.  It sounds like
> MinGW has stdbool.h.  If MSVC defines __cplusplus, then you also
> do not need to worry; otherwise, the stdbool.h build
> procedure should substitute 1 or 0 for @HAVE__BOOL@
> when reading from stdbool.in.h, depending on whether
> MSVC has built-in support for _Bool.

Thanks, all is clear now.

Avoiding slowdown in trunk development (was: gnulib strftime imported into Emacs)

[Eli Zaretskii]

> Date: Mon, 31 Jan 2011 23:08:44 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: emacs-devel@gnu.org
> 
> On 01/31/2011 08:05 PM, Eli Zaretskii wrote:
> 
> > I understand that this is because you don't actually build on your
> > feature branches, but instead merge onto the trunk first, and build
> > there.
> 
> No, I never build on my copy of the trunk.  I use that copy only to
> install already-tested new source code and immediately commit the
> result to Savannah

In that case, I really don't see how waiting for corresponding Windows
changes could slow you down.  A couple of possible workflows come to
mind:

 . Continue working in the same branch where you developed the
   changeset that is waiting.  When the Windows changes are ready, you
   can merge onto the trunk only that one changeset (using the -r
   option to "bzr merge").

 . Start a new branch for further work, based on either the trunk or
   the branch you just worked on, and whose latest changeset awaits
   the commit.  Branching is pretty cheap with bzr, because it's a
   local operation.  Last time I tried, it took about 20 sec on a
   reasonably fast GNU/Linux system, plus a couple of minutes to
   bootstrap the tree (you could avoid the bootstrap by just copying
   over all the *.elc files).  With this workflow, you will be able to
   merge each feature independently.

These are just the simplest possibilities (and I'm quite sure you are
already familiar with them).

So I really don't see what worries you.

The only real delay is in delivering the new feature to the trunk.
But I don't see how a couple of days of delay could possibly be of any
practical importance; do you?  There are many other projects with more
disciplined commit policies, where e.g. a commit requires an a-priori
approval; surely it doesn't mean those projects are unduly slowing
down their development?

> if that commit fails due to a nearly-simultaneous
> trunk commit by someone else, I typically just revert my copy of the
> trunk and start over.

I hope by "revert" you meant "bzr up", not "bzr revert".  The short
time window for the kind of race condition that could happen in this
situation will rarely cause changes in parts that are related to your
changes.  So reverting is not needed.  Bazaar (as other dVCSs) is very
good at merging, so conflicts are rare even if the changes overlap.

> The Windows port should not require mainline developers
> to spend significant chunks of their time.

How is this different from spending time on fixing problems of other
proprietary platforms, e.g. Solaris?

Please also note that in Emacs, most of the development happens in
platform-independent and device-independent parts, so people who track
the development trunk are not used to breakage that affects a single
platform.  That is one reason for the annoyances you saw last week.

> Anyway, as I've said before, I'm hoping that this is
> not necessary, and that we don't need to use separate branches
> to support Microsoft ports.

Same here.

Re: Avoiding slowdown in trunk development

[Paul Eggert]

On 02/01/11 00:58, Eli Zaretskii wrote:

> A couple of possible workflows come to mind:

Both of those suggestions would take more developer time.  For example,
I might have to figure out which changes to cherry-pick from other
codelines and would have to deal with merge conflicts.  I often do
this sort of thing, but it consumes valuable think time and
context-switching time (i.e., the context inside my head :-) to
maintain a separate line of development.  It's more efficient to avoid
that when possible, as is the case here.

> But I don't see how a couple of days of delay could possibly be of any
> practical importance; do you?

Sure they can.  Either they slow down that line of development a
couple of days, which is bad in real-time, or they require more
context-switching and merging, which is bad in developer-time.

> There are many other projects with more
> disciplined commit policies, where e.g. a commit requires an a-priori
> approval; surely it doesn't mean those projects are unduly slowing
> down their development?

There are many reasons why projects might need a change control board
or similar mechanism.  Such mechanisms almost invariably slow down
development.  If they're needed anyway, despite that disadvantage,
then they are slowing down development for good reason.

But that's not the case here.  The special needs of the Windows port
are not a good reason to slow down mainline development.

>> > if that commit fails due to a nearly-simultaneous
>> > trunk commit by someone else, I typically just revert my copy of the
>> > trunk and start over.
> I hope by "revert" you meant "bzr up", not "bzr revert".  The short
> time window for the kind of race condition that could happen in this
> situation will rarely cause changes in parts that are related to your
> changes.

Near-simultaneous changes have caused problems for me.
bzr may be good at merging, but its errors are common enough to be of
concern to me.  So I take a more cautious approach using "bzr revert".
This approach has not caused problems.

At any rate, I don't see how that caution is relevant.  No matter
which bzr style one uses to merge changes, the main problem is
the hassle of merging, not the bzr style one uses to merge.

>> > The Windows port should not require mainline developers
>> > to spend significant chunks of their time.
> How is this different from spending time on fixing problems of other
> proprietary platforms, e.g. Solaris?

It is greatly different as a practical matter.  Solaris is quite easy
to port to, and mainline development is not significantly
impeded by concerns about a Solaris port.  In contrast,
Windows is not nearly as easy to port to, and concerns about the
Windows port are getting in the way of mainline development.

> Please also note that in Emacs, most of the development happens in
> platform-independent and device-independent parts, so people who track
> the development trunk are not used to breakage that affects a single
> platform.

In that case, perhaps all that's needed is a minor adjustment in
expectations.  When Emacs's platform-independent parts are being
changed, Windows developers can continue to expect Emacs to build.
When the platform-dependent parts change, they can expect builds to
fail temporarily, until someone who's versed in Windows adjusts the
Windows build procedure.  This approach is quite common in other
projects, and it works for Emacs as well.

Re: Avoiding slowdown in trunk development

[Lennart Borgman]

On Tue, Feb 1, 2011 at 8:04 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
>
> But that's not the case here.  The special needs of the Windows port
> are not a good reason to slow down mainline development.

Every platform has it special needs. There is no running Emacs without
platform dependent parts.


> In that case, perhaps all that's needed is a minor adjustment in
> expectations.  When Emacs's platform-independent parts are being
> changed, Windows developers can continue to expect Emacs to build.
> When the platform-dependent parts change, they can expect builds to
> fail temporarily, until someone who's versed in Windows adjusts the
> Windows build procedure.  This approach is quite common in other
> projects, and it works for Emacs as well.

After reading this I am quite sure we need a policy for changes that
are known to break some commonly used platform. My suggestion is
(again) using a separate branch.

I can't see any solid reason in your arguments not to have a separate
branch for such changes. Maybe I am wrong.

You have said that it takes you extra time to have such a branch and
also that it takes a lot of time to do the merges. I have a hard time
to understand that so I ask you:

- What are the cost of an extra branch? Is there something that could
make this cost less?

- Why do you think that the merge will be difficult? I expect it to be
rather few changes at the locations where you are changing things. Is
not that your expectation too?

I got a lot of patches and some of them are unfortunately in parts
where things are changed and that causes me a lot of trouble
sometimes. However that trouble is less if I am able to merge more
often. With your suggestions I would be able to merge and build less
often so your suggestions would really cause at least me trouble.

Re: Avoiding slowdown in trunk development

[Eli Zaretskii]

> Date: Tue, 01 Feb 2011 11:04:44 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: emacs-devel@gnu.org
> 
> On 02/01/11 00:58, Eli Zaretskii wrote:
> 
> > A couple of possible workflows come to mind:
> 
> Both of those suggestions would take more developer time.  For example,
> I might have to figure out which changes to cherry-pick from other
> codelines and would have to deal with merge conflicts.

That'd be rare, I imagine.  It is for me, when I withhold a changeset
for some reason or another.  Maybe you are talking from experience in
another project, which is not necessarily applicable to Emacs
development.

> It's more efficient to avoid that when possible, as is the case
> here.

Yes, but at what price?  Breaking the build for several people is a
heavy price in my book.

> > But I don't see how a couple of days of delay could possibly be of any
> > practical importance; do you?
> 
> Sure they can.  Either they slow down that line of development a
> couple of days, which is bad in real-time, or they require more
> context-switching and merging, which is bad in developer-time.

I asked about practical importance, not theoretical one.  Some amount
of friction is inevitable in a project developed simultaneously by
several people.  We cannot behave as if each one of us owns the
project, and to heck with others.

> > I hope by "revert" you meant "bzr up", not "bzr revert".  The short
> > time window for the kind of race condition that could happen in this
> > situation will rarely cause changes in parts that are related to your
> > changes.
> 
> Near-simultaneous changes have caused problems for me.
> bzr may be good at merging, but its errors are common enough to be of
> concern to me.  So I take a more cautious approach using "bzr revert".
> This approach has not caused problems.

But it slows you down and makes your work less efficient.  And that
affects others, because you are unwilling to modify your workflow on
behalf of merge problems which I personally saw maybe once, if at all.

> At any rate, I don't see how that caution is relevant.  No matter
> which bzr style one uses to merge changes, the main problem is
> the hassle of merging, not the bzr style one uses to merge.

There's no hassle, in my experience.  It "just works".

> In that case, perhaps all that's needed is a minor adjustment in
> expectations.

I can hardly imagine this is going to happen.

Re: Avoiding slowdown in trunk development

[Chong Yidong]

Paul Eggert <eggert@cs.ucla.edu> writes:

>>> > if that commit fails due to a nearly-simultaneous
>>> > trunk commit by someone else, I typically just revert my copy of the
>>> > trunk and start over.
>> I hope by "revert" you meant "bzr up", not "bzr revert".  The short
>> time window for the kind of race condition that could happen in this
>> situation will rarely cause changes in parts that are related to your
>> changes.
>
> Near-simultaneous changes have caused problems for me.
> bzr may be good at merging, but its errors are common enough to be of
> concern to me.  So I take a more cautious approach using "bzr revert".
> This approach has not caused problems.

For stuff like the gnulib merge, it would be easier for you to work in a
branch.  No need to worry about using "bzr revert".

If I'd realized the gnulib changes would have broken the Windows build
for so long, I would have recommended doing them in a branch on
savannah.gnu.org first.  Then Eli could have fixed the Windows
compilation problems in the branch, before the new code was merged into
the trunk.