Re: syncing Emacs from sources maintained elsewhere

> Date: Mon, 24 Jan 2011 15:48:30 -0800 > From: Paul Eggert > CC: emacs-de...@gnu.org, bug-gnulib@gnu.org > > I also suggest looking at HAVE_ATTRIBUTE_ALIGNED, > HAVE_C99_STRTOLD, HAVE_LOCALTIME_R, HAVE_WCHAR_T, > inline, and restrict. Sure. I didn't ask about them because their meaning is clea

Re: Files from gnulib

> Date: Mon, 24 Jan 2011 15:26:06 -0800 > From: Paul Eggert > CC: Stefan Monnier , bug-gnulib@gnu.org, > emacs-de...@gnu.org > > On 01/23/11 20:01, Eli Zaretskii wrote: > > The program used to unpack the .tar.gz archives automatically renames > > ant .FOO files to _FOO while unpacking, so that'

Re: [PATCH] build: speed up configure for releases

Hi Eric, > What do you think of this patch? > > It speeds up ./configure of a release tarball (no time at all > spent on any HAVE_RAW_DECL_* checks), while defaulting to > leaving that in during development. I think it's a bad idea to make release tarballs work differently than the development e

Re: bootstrap bug with tests directory

Hi Eric, > Is the bug that > gnulib-tool outputs relative paths, and then bootstrap changes the > relative directory structure which breaks those paths? Yes. gnulib-tool computes the appropriates number of ../ (see variable testsbase_inverse and its use in AM_CPPFLAGS). The purpose of passing opt

bootstrap bug with tests directory

I'm not sure where to look, but I'm seeing some weird behavior with gnulib's bootstrap script as used by libvirt. I don't think the automake version is relevant; Serge Hallyn originally reported it to me, but I've reproduced it with both automake 1.9.6 and automake 1.11.1. Since the problem occurs

Re: syncing Emacs from sources maintained elsewhere

On 01/23/11 20:08, Eli Zaretskii wrote: > So the only macros that need work are the HAVE_DECL_* and > HAVE_RAW_DECL_*, is that right? You don't need to worry about HAVE_RAW_DECL_* any more; I recently added some stuff to gnulib to make them go away and they are no longer in the Emacs trunk. You d

Re: Files from gnulib

On 01/23/11 20:01, Eli Zaretskii wrote: > The program used to unpack the .tar.gz archives automatically renames > ant .FOO files to _FOO while unpacking, so that's not a problem. OK, so it sounds like there's already part of a solution here, in that files are automatically renamed to avoid the MS-

Re: Documentation for the regexp module

On 01/24/2011 01:57 PM, Jose E. Marchesi wrote: > > POSIX BREs and EREs > > And the GNU extensions that we should all be supporting by default > :). > > Just to be sure. By importing the 'regex' gnulib module and including > REG_EXTENDED in the cflags parameter of regcom

Re: Still unable to build trunk

> There is , but it's the > history filtered through git, which is not the same thing. There is no filtering, the history is identical. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 82

Re: Documentation for the regexp module

On 01/23/2011 05:27 PM, Karl Berry wrote: > As an available-now alternative, James (Youngman) developed some > automatically-generated Texinfo for each syntax for findutils. I'd > suggest going that way for recutils. I don't remember why we never > generated/imported/exported

Re: Documentation for the regexp module

POSIX BREs and EREs And the GNU extensions that we should all be supporting by default :). Just to be sure. By importing the 'regex' gnulib module and including REG_EXTENDED in the cflags parameter of regcomp we can be sure that we are supporting the GNU extensions, righ

Re: Still unable to build trunk

On 01/24/11 10:14, Eli Zaretskii wrote: > I thought something like "autoreconf -I m4" > was needed to build successfully after synchronizing with the > repository, if my last synchronization was before the import from > gnulib. If that's not true, are you saying that just "./configure" > should b

Re: [PATCH] build: speed up configure for releases

On 01/24/11 10:31, Eric Blake wrote: > Hmm, it may still make sense to do both things - make it possible > to completely elide HAVE_RAW_DECL_* (this patch) for configure > built for a tarball, as well as to provide a configure option > (rather than the current ad-hoc approach of > make CFLAGS=-DGNU

Re: Documentation for the regexp module

On 01/23/2011 05:27 PM, Karl Berry wrote: > As an available-now alternative, James (Youngman) developed some > automatically-generated Texinfo for each syntax for findutils. I'd > suggest going that way for recutils. I don't remember why we never > generated/imported/exported those docs in gnulib

[PATCH] build: speed up configure for releases

* gnulib: Update to latest, for posixcheck improvement. * configure.ac (gl_ASSERT_NO_GNULIB_POSIXCHECK): Conditionally define, according to whether git-version-gen output included '-'. --- What do you think of this patch? It speeds up ./configure of a release tarball (no time at all spent on any

Re: Still unable to build trunk

> Date: Sun, 23 Jan 2011 13:23:39 -0800 > From: Paul Eggert > CC: Jim Meyering , c...@stupidchicken.com, > jan@swipnet.se, emacs-de...@gnu.org, bug-gnulib > > I dunno, I just started doing some Emacs development after > about five years' absence, and it was a pretty steep learning > curve

Re: speed up 'configure' by removing HAVE_RAW_DECL_*

On 01/22/2011 07:08 PM, Paul Eggert wrote: > To do this, one way to would be to follow the example of > >+# gl_ASSERT_NO_GNULIB_POSIXCHECK >+# asserts that there will never be a need to #define GNULIB_POSIXCHECK. >+# and thereby enables an optimization of configure and config.h. >+

Re: Still unable to build trunk

Stefan Monnier writes: >> For example, nowhere is it stated that one really should use the >> obsolescent Python version 2.6.6, and that the current Python versions >> 2.7.1 and 3.1.3 do not work well with the current bzr version. I had >> to find that out myself, the hard way, by making hard-to-