Still unable to build trunk

Still unable to build trunk

[Chong Yidong]

On a fresh checkout of the trunk, I do `configure' followed by `make',
and the result is an infinite loop with the following messages:

  make[1]: Entering directory `/home/cyd/src/emacs/trunk2/lib'
  cd .. && make  am--refresh
  make[2]: Entering directory `/home/cyd/src/emacs/trunk2'
  make[2]: Nothing to be done for `am--refresh'.
  make[2]: Leaving directory `/home/cyd/src/emacs/trunk2'
   cd /home/cyd/src/emacs/trunk2 && /bin/bash /home/cyd/src/emacs/trunk2/missing --run automake-1.11 --gnu lib/Makefile
  /home/cyd/src/emacs/trunk2/missing: line 52: automake-1.11: command not found
  WARNING: `automake-1.11' is missing on your system.  You should only
         need it if you modified `Makefile.am', `acinclude.m4' or
         `configure.in'.  You might want to install the `Automake' and
         `Perl' packages.  Grab them from any GNU archive site.

I then installed automake, and did `configure' followed by `make', and
now compilation errors out:

  make[2]: Leaving directory `/home/cyd/src/emacs/trunk2'
   cd /home/cyd/src/emacs/trunk2 && /bin/bash /home/cyd/src/emacs/trunk2/missing --run automake-1.11 --gnu lib/Makefile
  configure.in: no proper invocation of AM_INIT_AUTOMAKE was found.
  configure.in: You should verify that configure.in invokes AM_INIT_AUTOMAKE,
  configure.in: that aclocal.m4 is present in the top-level directory,
  configure.in: and that aclocal.m4 was recently regenerated (using aclocal).
  /usr/local/share/automake-1.11/am/depend2.am: am__fastdepCC does not appear in AM_CONDITIONAL
  /usr/local/share/automake-1.11/am/depend2.am:   The usual way to define `am__fastdepCC' is to add `AC_PROG_CC'
  /usr/local/share/automake-1.11/am/depend2.am:   to `configure.in' and run `aclocal' and `autoconf' again.
  /usr/local/share/automake-1.11/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
  /usr/local/share/automake-1.11/am/depend2.am:   The usual way to define `AMDEP' is to add one of the compiler tests
  /usr/local/share/automake-1.11/am/depend2.am:     AC_PROG_CC, AC_PROG_CXX, AC_PROG_CXX, AC_PROG_OBJC,
  /usr/local/share/automake-1.11/am/depend2.am:     AM_PROG_AS, AM_PROG_GCJ, AM_PROG_UPC
  /usr/local/share/automake-1.11/am/depend2.am:   to `configure.in' and run `aclocal' and `autoconf' again.
  make[1]: *** [/home/cyd/src/emacs/trunk2/lib/Makefile.in] Error 1
  make[1]: Leaving directory `/home/cyd/src/emacs/trunk2/lib'
  make: *** [lib] Error 2

I notice, by the way, that the `make all' directive in lib/ ends up
deleting the top-level Makefile, which does not make sense given that
it's generated by doing `configure'.  Something is really wrong here.

Re: Still unable to build trunk

[Jan Djärv]

Chong Yidong skrev 2011-01-20 19.47:

>
>    make[2]: Leaving directory `/home/cyd/src/emacs/trunk2'
>     cd /home/cyd/src/emacs/trunk2&&  /bin/bash /home/cyd/src/emacs/trunk2/missing --run automake-1.11 --gnu lib/Makefile
>    configure.in: no proper invocation of AM_INIT_AUTOMAKE was found.
>    configure.in: You should verify that configure.in invokes AM_INIT_AUTOMAKE,
>    configure.in: that aclocal.m4 is present in the top-level directory,
>    configure.in: and that aclocal.m4 was recently regenerated (using aclocal).
>    /usr/local/share/automake-1.11/am/depend2.am: am__fastdepCC does not appear in AM_CONDITIONAL
>    /usr/local/share/automake-1.11/am/depend2.am:   The usual way to define `am__fastdepCC' is to add `AC_PROG_CC'
>    /usr/local/share/automake-1.11/am/depend2.am:   to `configure.in' and run `aclocal' and `autoconf' again.
>    /usr/local/share/automake-1.11/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
>    /usr/local/share/automake-1.11/am/depend2.am:   The usual way to define `AMDEP' is to add one of the compiler tests
>    /usr/local/share/automake-1.11/am/depend2.am:     AC_PROG_CC, AC_PROG_CXX, AC_PROG_CXX, AC_PROG_OBJC,
>    /usr/local/share/automake-1.11/am/depend2.am:     AM_PROG_AS, AM_PROG_GCJ, AM_PROG_UPC
>    /usr/local/share/automake-1.11/am/depend2.am:   to `configure.in' and run `aclocal' and `autoconf' again.
>    make[1]: *** [/home/cyd/src/emacs/trunk2/lib/Makefile.in] Error 1
>    make[1]: Leaving directory `/home/cyd/src/emacs/trunk2/lib'
>    make: *** [lib] Error 2
>

Running autoreconf -I m4 solved this for me.

	Jan D.

Re: Still unable to build trunk

[Chong Yidong]

Jan Djärv <jan.h.d@swipnet.se> writes:

> Running autoreconf -I m4 solved this for me.

I had to do autoreconf -I m4 --force.

The point, though, is that configure should not complete successfully if
the Makefiles that it generates cannot be used to make Emacs, due to a
missing aclocal.m4 or whatever other reason.  Nor should configure
produce a set of Makefiles that causes `make' to infloop.  That's a bug.

Re: Still unable to build trunk

[Paul Eggert]

On 01/20/2011 02:16 PM, Chong Yidong wrote:

> configure should not complete successfully if
> the Makefiles that it generates cannot be used to make Emacs, due to a
> missing aclocal.m4 or whatever other reason.  Nor should configure
> produce a set of Makefiles that causes `make' to infloop.  That's a bug.

I could not reproduce the bug from a fresh trunk checkout, even though
I tried lots of different ways (including environments that lacked
automake).  From your email, it appears that you ran 'configure'
without --enable-maintainer-mode, which means that automake should be
invoked only if lib/Makefile.in was somehow removed.  Perhaps
lib/Makefile.in was removed because you control-C'ed at some point?

Anyway, to avoid the problem with a missing aclocal.m4 I added
the following dependency to the top-level Makefile.in:

am--refresh: $(srcdir)/aclocal.m4 $(srcdir)/configure $(srcdir)/src/config.in

This should cause aclocal.m4 to be regenerated if it's somehow absent
when lib/Makefile decides that lib/Makefile.in needs to be rebuilt.
This appeared to be a crucial part of the failure scenario that you
reported.

> I notice, by the way, that the `make all' directive in lib/ ends up
> deleting the top-level Makefile, which does not make sense given that
> it's generated by doing `configure'.  Something is really wrong here.

Yes it is, but I cannot reproduce that problem either:

   $ cd lib
   $ make all
   make  all-am
   make[1]: Entering directory `/w/fac.2/cs/eggert/src/gnu/emacs/atest/lib'
   make[1]: Nothing to be done for `all-am'.
   make[1]: Leaving directory `/w/fac.2/cs/eggert/src/gnu/emacs/atest/lib'
   $ ls -l ../Makefile Makefile
   -rw-r--r-- 1 eggert csfac 35032 Jan 21 11:55 Makefile
   -rw-r--r-- 1 eggert csfac 37189 Jan 21 11:55 ../Makefile

Perhaps you ran an autotool without the crucial -I m4 option, and then
ran the resulting messed-up 'configure'?  If this was the problem, and
if this turns out to be a common failure mode, perhaps we can modify
'configure.in' so that the generated 'configure' refuses to run if
(for example) 'autoreconf' was used without -I m4.

Re: Still unable to build trunk

[Chong Yidong]

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

>> configure should not complete successfully if
>> the Makefiles that it generates cannot be used to make Emacs, due to a
>> missing aclocal.m4 or whatever other reason.  Nor should configure
>> produce a set of Makefiles that causes `make' to infloop.  That's a bug.
>
> I could not reproduce the bug from a fresh trunk checkout, even though
> I tried lots of different ways (including environments that lacked
> automake).  From your email, it appears that you ran 'configure'
> without --enable-maintainer-mode, which means that automake should be
> invoked only if lib/Makefile.in was somehow removed.  Perhaps
> lib/Makefile.in was removed because you control-C'ed at some point?
>
> Anyway, to avoid the problem with a missing aclocal.m4 I added
> the following dependency to the top-level Makefile.in:
>
> am--refresh: $(srcdir)/aclocal.m4 $(srcdir)/configure $(srcdir)/src/config.in

Now, when automake is installed, things seems to work OK.  However, when
automake is not installed:

   $ ./configure (completes successfully)
   $ make
   cd lib; make all                            \
        CC='gcc' CFLAGS='-g -O2' CPPFLAGS='' \
          LDFLAGS='-Wl,-znocombreloc ' MAKE='make'
   make[1]: Entering directory `/home/cyd/src/emacs/trunk2/lib'
   cd .. && make  am--refresh
   make[2]: Entering directory `/home/cyd/src/emacs/trunk2'
   cd /home/cyd/src/emacs/trunk2 && aclocal -I m4
   /bin/sh: aclocal: not found
   make[2]: *** [/home/cyd/src/emacs/trunk2/aclocal.m4] Error 127
   make[2]: Leaving directory `/home/cyd/src/emacs/trunk2'
   make[1]: *** [/home/cyd/src/emacs/trunk2/aclocal.m4] Error 2
   make[1]: Leaving directory `/home/cyd/src/emacs/trunk2/lib'
   make: *** [lib] Error 2

The fact that configure completes successfully, then fails to build, is
a bug.

Re: Still unable to build trunk

[Paul Eggert]

On 01/21/2011 05:29 PM, Chong Yidong wrote:
>    /bin/sh: aclocal: not found

OK, I see now.  When I tried to reproduce the problem, I failed
because I removed only 'automake' from my environment.  I also
needed to remove 'aclocal' to reproduce the problem.

One way to address this issue is to say that maintainers should
have automake installed.  That's normal for other packages, but
I'd rather minimize changes to the assumptions for Emacs.

So, another way is to revisit (again) the decision to omit
aclocal.m4 from the repository.  If we put aclocal.m4 in
the repository, we won't have this problem, because we won't
need to run aclocal to generate it.

Perhaps at some point we will assume that maintainers have
automake installed, and we can then go back and revisit
(again!) whether aclocal.m4 should be in the repository.

For now I made this change:

aclocal.m4: put this file back into repository
This way, we don't have to assume that the maintainer has
the automake package installed.  See
<http://lists.gnu.org/archive/html/emacs-devel/2011-01/msg00746.html>.
* .bzrignore: Remove aclocal.m4, undoing the previous change.
* Makefile.in (top_maintainer_clean): Do not remove aclocal.m4,
undoing the previous change.
* aclocal.m4: New file (actually, resurrected).
=== modified file '.bzrignore'
--- .bzrignore	2011-01-21 20:23:24 +0000
+++ .bzrignore	2011-01-22 07:09:21 +0000
@@ -13,7 +13,6 @@
 *.dSYM
 *.elc
 *.exe
-aclocal.m4
 autom4te.cache
 confdefs.h
 configure.lineno

=== modified file 'Makefile.in'
--- Makefile.in	2011-01-21 20:23:24 +0000
+++ Makefile.in	2011-01-22 07:11:49 +0000
@@ -833,8 +833,7 @@
 ###      begin to build the program.
 top_maintainer_clean=\
 	${top_distclean}; \
-	rm -fr autom4te.cache; \
-	rm -f aclocal.m4
+	rm -fr autom4te.cache
 maintainer-clean: bootstrap-clean FRC
 	(cd src;      $(MAKE) $(MFLAGS) maintainer-clean)
 	(cd lisp;     $(MAKE) $(MFLAGS) maintainer-clean)

=== added file 'aclocal.m4'
[...contents omitted to save space in my email...]

Re: Still unable to build trunk

[Eli Zaretskii]

> Date: Fri, 21 Jan 2011 23:25:26 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> Cc: Jan Djärv <jan.h.d@swipnet.se>, emacs-devel@gnu.org
> 
> One way to address this issue is to say that maintainers should
> have automake installed.  That's normal for other packages, but
> I'd rather minimize changes to the assumptions for Emacs.

What is the meaning of "maintainers" in this context?  Does that mean
anyone who builds the development trunk?  If so, that's a very large
population, most of them not really "maintain" Emacs, and I'm not sure
we want to request that all of them have automake installed.

In any case, if we do, there should be clear information about the
version(s) of all the auto-tools that are required to build Emacs
correctly and seamlessly.  The file INSTALL.BZR in the top-level
directory sounds like the right place.  It currently says nothing
about these requirements, AFICS.

Re: Still unable to build trunk

[Jim Meyering]

Eli Zaretskii wrote:
>> Date: Fri, 21 Jan 2011 23:25:26 -0800
>> From: Paul Eggert <eggert@cs.ucla.edu>
>> Cc: Jan Djärv <jan.h.d@swipnet.se>, emacs-devel@gnu.org
>>
>> One way to address this issue is to say that maintainers should
>> have automake installed.  That's normal for other packages, but
>> I'd rather minimize changes to the assumptions for Emacs.
>
> What is the meaning of "maintainers" in this context?  Does that mean
> anyone who builds the development trunk?  If so, that's a very large
> population, most of them not really "maintain" Emacs, and I'm not sure
> we want to request that all of them have automake installed.
>
> In any case, if we do, there should be clear information about the
> version(s) of all the auto-tools that are required to build Emacs
> correctly and seamlessly.  The file INSTALL.BZR in the top-level
> directory sounds like the right place.  It currently says nothing
> about these requirements, AFICS.

Hi Eli,

By "maintainers", he meant "anyone who builds from VC-cloned sources."

In many gnulib-using projects, we address two types of
users who build from source:
  - those who build from a distribution tarball
  - those who build from upstream clone/checkout

Obviously, when building from a tarball, there are only the usual, minimal
requirements specified in the GCS.  E.g., use of autoconf, automake, makeinfo,
etc. are not required.

However, those who build from the latest sources, as checked out
from version control must have tools that meet certain standards.
In coreutils, for example, we address that with the combination
of documentation via two README files:

  README-hacking
  README-prereq

  http://git.sv.gnu.org/cgit/coreutils.git/tree/README-hacking
  http://git.sv.gnu.org/cgit/coreutils.git/tree/README-prereq
  # We also have HACKING, but it targets those contributing patches:
  http://git.sv.gnu.org/cgit/coreutils.git/tree/HACKING

and an automated check for the presence and minimal-acceptable versions
of build-related tools (this is from bootstrap.conf):

  # Build prerequisites
  buildreq="\
  autoconf   2.62
  automake   1.11.1
  autopoint  -
  bison      -
  gettext    0.17
  git        1.4.4
  gperf      -
  gzip       -
  makeinfo   -
  patch      -
  perl       5.5
  rsync      -
  tar        -
  xz         -
  "

Since anyone building coreutils from VC'd sources must run our
./bootstrap script, they will learn very quickly if they lack one
of the required build tools.

Re: Still unable to build trunk

[Eli Zaretskii]

> From: Jim Meyering <jim@meyering.net>
> Cc: Paul Eggert <eggert@cs.ucla.edu>,  cyd@stupidchicken.com,  jan.h.d@swipnet.se,  emacs-devel@gnu.org
> Date: Sun, 23 Jan 2011 16:33:00 +0100
> 
> In many gnulib-using projects, we address two types of
> users who build from source:
>   - those who build from a distribution tarball
>   - those who build from upstream clone/checkout
> 
> Obviously, when building from a tarball, there are only the usual, minimal
> requirements specified in the GCS.  E.g., use of autoconf, automake, makeinfo,
> etc. are not required.
> 
> However, those who build from the latest sources, as checked out
> from version control must have tools that meet certain standards.
> [...]
> and an automated check for the presence and minimal-acceptable versions
> of build-related tools (this is from bootstrap.conf):
> 
>   # Build prerequisites
>   buildreq="\
>   autoconf   2.62
>   automake   1.11.1
>   autopoint  -
>   bison      -
>   gettext    0.17
>   git        1.4.4
>   gperf      -
>   gzip       -
>   makeinfo   -
>   patch      -
>   perl       5.5
>   rsync      -
>   tar        -
>   xz         -
>   "

It sounds harsh to me to ask every one who builds out of VCS to have
to climb such a steep curve.  If you read the reports in this forum,
you will see that many of those who do that are no more knowledgeable
in build tools than those who build distribution tarballs.  A person
who installs bzr does not necessarily know about autotools.  She is
not necessarily a "developer" of Emacs, just someone who wants the
latest and the greatest.

Even core Emacs maintainers have trouble with these prerequisites, for
any number of reasons (e.g., Autoconf installed on fencepost is too
old for what Paul added to the Emacs tree, so until the GNU admins
upgrade that at my request, I cannot build the current tree).  Imagine
what will happen to people with less experience and grey hair,
especially if they do that on systems they don't own.

Re: Still unable to build trunk

[Jim Meyering]

Eli Zaretskii wrote:
>> From: Jim Meyering <jim@meyering.net>
>> Cc: Paul Eggert <eggert@cs.ucla.edu>, cyd@stupidchicken.com,
>> jan.h.d@swipnet.se, emacs-devel@gnu.org
>> Date: Sun, 23 Jan 2011 16:33:00 +0100
>>
>> In many gnulib-using projects, we address two types of
>> users who build from source:
>>   - those who build from a distribution tarball
>>   - those who build from upstream clone/checkout
>>
>> Obviously, when building from a tarball, there are only the usual, minimal
>> requirements specified in the GCS.  E.g., use of autoconf, automake, makeinfo,
>> etc. are not required.
>>
>> However, those who build from the latest sources, as checked out
>> from version control must have tools that meet certain standards.
>> [...]
>> and an automated check for the presence and minimal-acceptable versions
>> of build-related tools (this is from bootstrap.conf):
>>
>>   # Build prerequisites
>>   buildreq="\
>>   autoconf   2.62
>>   automake   1.11.1
>>   autopoint  -
>>   bison      -
>>   gettext    0.17
>>   git        1.4.4
>>   gperf      -
>>   gzip       -
>>   makeinfo   -
>>   patch      -
>>   perl       5.5
>>   rsync      -
>>   tar        -
>>   xz         -
>>   "
>
> It sounds harsh to me to ask every one who builds out of VCS to have
> to climb such a steep curve.  If you read the reports in this forum,

Requiring the installation of a few commonly-used and very portable tools
does not make a steep curve.  It's more of a small, one-time investment.

Imposing new requirements like this is not harsh when you also
provide adequate instructions for meeting them.

Also, realize that if you're able to build-from-clone on at least one
system and want to build occasionally on another system that lacks some of
the required tools, one work-around is to build a tarball of your working
sources, copy that to the constrained system and just run ./configure &&
make as usual.  Of course, this is impractical if you have to do it more
than occasionally.

> you will see that many of those who do that are no more knowledgeable
> in build tools than those who build distribution tarballs.  A person
> who installs bzr does not necessarily know about autotools.  She is
> not necessarily a "developer" of Emacs, just someone who wants the
> latest and the greatest.

The build-from-clone process does not require knowing anything more
about autotools than the package names -- and that is only to install
the packages if they're not already available.

> Even core Emacs maintainers have trouble with these prerequisites, for
> any number of reasons (e.g., Autoconf installed on fencepost is too
> old for what Paul added to the Emacs tree, so until the GNU admins
> upgrade that at my request, I cannot build the current tree).

Run the script below on fencepost, following the instructions
in its --help, and you should be good to go.

> Imagine
> what will happen to people with less experience and grey hair,
> especially if they do that on systems they don't own.

It is most definitely a trade-off, but afaik, one that we have
managed well with coreutils, diffutils, gzip, grep, parted, etc.
On those projects, no one has reported trouble with the build process
for some time.

You have to balance the needs of the many (to be able to build
conveniently from the latest, cloned sources) against the desire of
the developers not to waste time with complications involved in using
version-controlled, yet generated, source files.

For those who are unable to install the required packages on a system
they use for development, I wrote a script that automates the process
of downloading and building-from source a few of the required packages:

  http://people.redhat.com/meyering/autotools-install

Here's its --help output:

    Usage: autotools-install [OPTION]...

    Download, build, and install some tools.

    Options:
     --prefix=PREFIX    install tools under specified directory
     --skip-check       do not run make check (this can save 50+ min)
     --help             display this help and exit

    For example, to install programs into $HOME/autotools/bin, run this command:

      autotools-install --prefix=$HOME/autotools

    If you've already verified that your system/environment can build working
    versions of these tools, you can make this script complete in just a
    minute or two (rather than about an hour if you let all make check
    tests run) by invoking it like this:

      autotools-install --prefix=$HOME/autotools --skip-check

Re: Still unable to build trunk

[Eli Zaretskii]

> From: Jim Meyering <jim@meyering.net>
> Cc: eggert@cs.ucla.edu,  cyd@stupidchicken.com,  jan.h.d@swipnet.se,  emacs-devel@gnu.org
> Date: Sun, 23 Jan 2011 18:35:17 +0100
> 
> Requiring the installation of a few commonly-used and very portable tools
> does not make a steep curve.  It's more of a small, one-time investment.

You forget about dependencies.  And about upgrading from time to time.
With every additional prerequisite, the burden gets exponentially more
heavy.  And it's certainly not on-time.

> > Even core Emacs maintainers have trouble with these prerequisites, for
> > any number of reasons (e.g., Autoconf installed on fencepost is too
> > old for what Paul added to the Emacs tree, so until the GNU admins
> > upgrade that at my request, I cannot build the current tree).
> 
> Run the script below on fencepost, following the instructions
> in its --help, and you should be good to go.

It's not my system, so I don't want private installation of
everything.  My home directory there is already one of the hugest.  I
was asked by sysadmins to go through them in cases such as this one,
in order to avoid bloating my home directory even more.

Anyway, this is just an example of why adding more prerequisites is
not something to do easily, IMO.

> > Imagine
> > what will happen to people with less experience and grey hair,
> > especially if they do that on systems they don't own.
> 
> It is most definitely a trade-off, but afaik, one that we have
> managed well with coreutils, diffutils, gzip, grep, parted, etc.
> On those projects, no one has reported trouble with the build process
> for some time.

I don't know if the comparison is valid.  More importantly, the fact
that the addition is due to syncing a couple of functions with gnulib
is troublesome -- it sounds like a tail that wags the dog.

Re: Still unable to build trunk

[Jim Meyering]

Eli Zaretskii wrote:
>> From: Jim Meyering <jim@meyering.net>
>> Cc: eggert@cs.ucla.edu, cyd@stupidchicken.com, jan.h.d@swipnet.se,
>> emacs-devel@gnu.org
>> Date: Sun, 23 Jan 2011 18:35:17 +0100
>>
>> Requiring the installation of a few commonly-used and very portable tools
>> does not make a steep curve.  It's more of a small, one-time investment.
>
> You forget about dependencies.

Hardly.  The few programs we're talking about
(mainly just m4, automake and autoconf) have very few dependencies.

> And about upgrading from time to time.

If fencepost were upgraded more often, this would not be a problem.
If you're worried about one of these privately-installed packages
being invalidated by a (rare) upgrade, then just rerun the script
to install them from scratch again.

> With every additional prerequisite, the burden gets exponentially more
> heavy.  And it's certainly not on-time.

People participating in emacs development (even if only building
from latest cloned sources) can be expected to follow a few simple
instructions.  If they have to rerun a few commands after someone
else upgrades their development system, that does not strike me as an
unreasonable burden, and certainly not as an exponentially heavy one.

>> > Even core Emacs maintainers have trouble with these prerequisites, for
>> > any number of reasons (e.g., Autoconf installed on fencepost is too
>> > old for what Paul added to the Emacs tree, so until the GNU admins
>> > upgrade that at my request, I cannot build the current tree).
>>
>> Run the script below on fencepost, following the instructions
>> in its --help, and you should be good to go.
>
> It's not my system, so I don't want private installation of
> everything.

If you run the script and have it install only m4, automake and
autoconf, the result occupies less than 6MiB.

> My home directory there is already one of the hugest.  I
> was asked by sysadmins to go through them in cases such as this one,
> in order to avoid bloating my home directory even more.

I see that you're using over 22GiB(!) there.
Remove just one of your many emacs-*.tar.gz files
and that will free far more space than any tiny tool
installation would consume.

> Anyway, this is just an example of why adding more prerequisites is
> not something to do easily, IMO.

If we recoil from every task that at first appears nontrivial,
we will never make progress.

>> > Imagine
>> > what will happen to people with less experience and grey hair,
>> > especially if they do that on systems they don't own.
>>
>> It is most definitely a trade-off, but afaik, one that we have
>> managed well with coreutils, diffutils, gzip, grep, parted, etc.
>> On those projects, no one has reported trouble with the build process
>> for some time.
>
> I don't know if the comparison is valid.  More importantly, the fact
> that the addition is due to syncing a couple of functions with gnulib
> is troublesome -- it sounds like a tail that wags the dog.

I have endured more than my fair share of conflicts due to
version-controlled sources that are also generated by the build process.
That taught me that avoiding such trouble is well worth this type of investment.

Re "just a couple gnulib functions", Paul deliberately made the
initial introduction small.  There are many more opportunities.

Re: Still unable to build trunk

[Eli Zaretskii]

> From: Jim Meyering <jim@meyering.net>
> Cc: eggert@cs.ucla.edu,  cyd@stupidchicken.com,  jan.h.d@swipnet.se,  emacs-devel@gnu.org
> Date: Sun, 23 Jan 2011 19:47:04 +0100
> 
> Eli Zaretskii wrote:
> >> From: Jim Meyering <jim@meyering.net>
> >> Cc: eggert@cs.ucla.edu, cyd@stupidchicken.com, jan.h.d@swipnet.se,
> >> emacs-devel@gnu.org
> >> Date: Sun, 23 Jan 2011 18:35:17 +0100
> >>
> >> Requiring the installation of a few commonly-used and very portable tools
> >> does not make a steep curve.  It's more of a small, one-time investment.
> >
> > You forget about dependencies.
> 
> Hardly.  The few programs we're talking about
> (mainly just m4, automake and autoconf) have very few dependencies.

You are talking about a specific example, while I'm talking about
adding prerequisites in principle.

> People participating in emacs development (even if only building
> from latest cloned sources) can be expected to follow a few simple
> instructions.  If they have to rerun a few commands after someone
> else upgrades their development system, that does not strike me as an
> unreasonable burden, and certainly not as an exponentially heavy one.

It's easy for us old-timers to say.  Not so easy for everyone else to
follow suit.

> I see that you're using over 22GiB(!) there.
> Remove just one of your many emacs-*.tar.gz files
> and that will free far more space than any tiny tool
> installation would consume.

Please believe me that I need everything that I have there.

> > Anyway, this is just an example of why adding more prerequisites is
> > not something to do easily, IMO.
> 
> If we recoil from every task that at first appears nontrivial,
> we will never make progress.

There's a world of possibilities between "recoil from" and "accept
without discussion".

> Re "just a couple gnulib functions", Paul deliberately made the
> initial introduction small.  There are many more opportunities.

You cannot fight the fire if you wait until it consumes the entire
building.

Re: Still unable to build trunk

[Jim Meyering]

Eli Zaretskii wrote:

>> From: Jim Meyering <jim@meyering.net>
>> Cc: eggert@cs.ucla.edu, cyd@stupidchicken.com, jan.h.d@swipnet.se,
>> emacs-devel@gnu.org
>> Date: Sun, 23 Jan 2011 19:47:04 +0100
>>
>> Eli Zaretskii wrote:
>> >> From: Jim Meyering <jim@meyering.net>
>> >> Cc: eggert@cs.ucla.edu, cyd@stupidchicken.com, jan.h.d@swipnet.se,
>> >> emacs-devel@gnu.org
>> >> Date: Sun, 23 Jan 2011 18:35:17 +0100
>> >>
>> >> Requiring the installation of a few commonly-used and very portable tools
>> >> does not make a steep curve.  It's more of a small, one-time investment.
>> >
>> > You forget about dependencies.
>>
>> Hardly.  The few programs we're talking about
>> (mainly just m4, automake and autoconf) have very few dependencies.
>
> You are talking about a specific example, while I'm talking about
> adding prerequisites in principle.

We are adding specific well-understood dependencies.
There is no need to worry about the complexities of adding additional,
theoretical dependencies.

>> People participating in emacs development (even if only building
>> from latest cloned sources) can be expected to follow a few simple
>> instructions.  If they have to rerun a few commands after someone
>> else upgrades their development system, that does not strike me as an
>> unreasonable burden, and certainly not as an exponentially heavy one.
>
> It's easy for us old-timers to say.  Not so easy for everyone else to
> follow suit.

I've tried to show (documentation, and successes with other projects)
that this is not a problem.  You persist in saying that it is.  Why?
Can you provide justification?

>> I see that you're using over 22GiB(!) there.
>> Remove just one of your many emacs-*.tar.gz files
>> and that will free far more space than any tiny tool
>> installation would consume.
>
> Please believe me that I need everything that I have there.

??
You must not realize that you have 11 gdb build directories,
each occupying up to 430 MiB.

Run du -csh gdb-*
That shows 3.1GiB just for those and their tarballs.
Access times suggest that many have been unused for a long time.

Run "make clean" in a few of those and you'll
remove plenty of cruft that hasn't been touched
for a few years.  I.e., do this:

    for i in gdb-*; do (test -d $i && cd $i && make clean); done

Most of the following tarballs are copies of released ones.
Why bother to keep them here?
With 5.2 and newer, you can just use or link to copies in this directory:
/srv/data/ftp-mirror/ftp/gnu/gdb/

    $ ls -1d gdb-*
    gdb-2.4+.aux.coff.tar.bz2
    gdb-2.5.3.tar.bz2
    gdb-2.8.1.tar.bz2
    gdb-3.1.tar.bz2
    gdb-3.3.tar.bz2
    gdb-3.4.tar.bz2
    gdb-3.5.tar.bz2
    gdb-4.0.1.tar.bz2
    gdb-4.11.tar.bz2
    gdb-4.12.tar.bz2
    gdb-4.13.tar.bz2
    gdb-4.14.tar.bz2
    gdb-4.16.tar.bz2
    gdb-4.17.tar.bz2
    gdb-4.18.tar.bz2
    gdb-4.1.tar.bz2
    gdb-4.2.tar.bz2
    gdb-4.3.tar.bz2
    gdb-4.4.tar.bz2
    gdb-4.5.tar.bz2
    gdb-4.6.tar.bz2
    gdb-4.7.tar.bz2
    gdb-4.8.tar.bz2
    gdb-4.9.tar.bz2
    gdb-6.0.tar.gz
    gdb-6.1/
    gdb-6.1.tar.gz
    gdb-6.2/
    gdb-6.2.tar.gz
    gdb-6.3/
    gdb-6.3.tar.gz
    gdb-6.4/
    gdb-6.4.tar.gz
    gdb-6.6/
    gdb-6.6.tar.bz2
    gdb-6.7.1/
    gdb-6.7.1.tar.bz2
    gdb-6.7.tar.bz2
    gdb-6.8/
    gdb-6.8.50.20090410/
    gdb-6.8.50.20090410.tar.bz2
    gdb-6.8.50.20090902.tar.bz2
    gdb-6.8.tar.bz2
    gdb-7.0/
    gdb-7.0.tar.bz2
    gdb-7.1/
    gdb-7.1.tar.bz2
    gdb-7.2/
    gdb-7.2.tar.bz2

Re: Still unable to build trunk

[Paul Eggert]

On 01/23/2011 09:00 AM, Eli Zaretskii wrote:
> It sounds harsh to me to ask every one who builds out of VCS to have
> to climb such a steep curve.

I dunno, I just started doing some Emacs development after
about five years' absence, and it was a pretty steep learning
curve for me.  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-diagnose screwups.
By comparison, the autotools requirements of Gnulib
are relatively tame; they are better documented and
they don't rely on people having older-than-current versions.

Anyway, the point is moot, no?  Right now the Emacs VCS
builds out of the box with the same tools as before.
Maintainers don't need to have automake installed
unless they also want to do gnulib-related development,
for which automake is required anyway.

Re: Still unable to build trunk

[Stefan Monnier]

>> It sounds harsh to me to ask every one who builds out of VCS to have
>> to climb such a steep curve.
> I dunno, I just started doing some Emacs development after
> about five years' absence, and it was a pretty steep learning
> curve for me.

We decided a long time ago that it should be possible to build Emacs
from the VCS without autotools.  While I don't like having `configure'
and other auto-generated files under the control of the VCS, we've
learned to live with it and some of those files are related to bootstrap
rather than to autotools, so even if we change the decision, we'll still
be left with such files.
IOW, we still wantfor people to be able to build Emacs from the VCS
without needing autotools.  If that means keeping aclocal.m4 under the
control of Bzr, then so be it.

> 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-diagnose
> screwups.

That's because noone knows that: the python mode is poorly maintained.


        Stefan

Re: Still unable to build trunk

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> 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-diagnose
>> screwups.
>
> That's because noone knows that: the python mode is poorly maintained.

I thought he meant that's what using bzr requires; at least the versions
of bzr on debian  (versions 2.3.0, 2.1.2, 1.5) have dependencies like
"python (<< 2.7), python (>= 2.5)" ...

-Miles

-- 
Inhumanity, n. One of the signal and characteristic qualities of humanity.

Re: Still unable to build trunk

[Glenn Morris]

[ removed bug-gnulib, don't think this is relevant to them ]

Stefan Monnier wrote:

> We decided a long time ago that it should be possible to build Emacs
> from the VCS without autotools.

Do you have a pointer to this discussion?

In any case, I hope you will reconsider this old decision, since the
arguments for changing this have been well made in this thread, IMO.

> While I don't like having `configure' and other auto-generated files
> under the control of the VCS, we've learned to live with it and some
> of those files are related to bootstrap rather than to autotools, so
> even if we change the decision, we'll still be left with such files.

I guess you mean ldefs-boot, cl-loaddefs etc. These don't seem to have
much bearing on the current question to me. Just because you can't get
rid of ALL generated files doesn't mean you should not get rid of
SOME, starting with the easiest. Especially if you find yourself
having to add more and more of a given class.

(FWIW, one of the systems I regularly build Emacs on has too old a
version of autoconf etc installed. I had no problem installing newer
versions of those tools for my own use.)

Re: Still unable to build trunk

[Stefan Monnier]

>> We decided a long time ago that it should be possible to build Emacs
>> from the VCS without autotools.
> Do you have a pointer to this discussion?

No.

> In any case, I hope you will reconsider this old decision, since the
> arguments for changing this have been well made in this thread, IMO.

I don't think we want to reconsider it for now.  But if people can
arrange Emacs's build so that it doesn't require a pre-build configure
and yet is still easy to install under something like Debian stable,
I could change my mind.  It might even be a good change if it can help
users figure out which packages need to be installed (autotools, header
files, ...).

>> While I don't like having `configure' and other auto-generated files
>> under the control of the VCS, we've learned to live with it and some
>> of those files are related to bootstrap rather than to autotools, so
>> even if we change the decision, we'll still be left with such files.
> I guess you mean ldefs-boot, cl-loaddefs etc.

Yes.


        Stefan

Re: Still unable to build trunk

[Eli Zaretskii]

> Date: Sun, 23 Jan 2011 13:23:39 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: Jim Meyering <jim@meyering.net>, cyd@stupidchicken.com, 
>  jan.h.d@swipnet.se, emacs-devel@gnu.org, bug-gnulib <bug-gnulib@gnu.org>
> 
> I dunno, I just started doing some Emacs development after
> about five years' absence, and it was a pretty steep learning
> curve for me.  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.

No one complained about this in the past, I think, otherwise it would
have been in INSTALL.BZR.  However, the issue seems to be more related
to bzr installation on GNU/Linux or maybe to the various maintainers
of the bzr packages on GNU/Linux, than to Emacs: the Bazaar download
page (http://wiki.bazaar.canonical.com/DistroDownloads) doesn't tell
the requirements wrt Python and the Installation FAQ
(http://wiki.bazaar.canonical.com/InstallationFaq) says only this:
"Python >= 2.4".  Perhaps it would make sense to report this on the
Bazaar mailing list (bazaar@lists.canonical.com).

Any other issues that make the curve steep?

> Anyway, the point is moot, no?  Right now the Emacs VCS
> builds out of the box with the same tools as before.
> Maintainers don't need to have automake installed
> unless they also want to do gnulib-related development,
> for which automake is required anyway.

Maybe I misunderstood, but 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 be enough?

Re: Still unable to build trunk

[Paul Eggert]

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 be enough?

Yes, it should be enough, unless the commit was busted (or unless
I'm missing something, which is quite plausible since I don't know bzr well).
Here I'm assuming that someone else (who had up-to-date autotools)
did a 'make sync-from-gnulib' and then committed the result.

When you resynchronize from the repository, you should get not only
the hand-maintained source files (such as 'configure.in'); you should
also get the automatically-generated files (such as 'configure'), and
their time stamps should be no earlier than those of the source files.

If you are using HP-UX 'make' you might have trouble, since it
violates POSIX and considers a destination to be out-of-date if
its time stamp is the same as the source.  But the workaround
is simple: use GNU 'make' if you're on HP-UX, which you should
be doing anyway for other reasons if you're a maintainer.


> Any other issues that make the curve steep?

Well, you asked.  :-)  Sure, another thing that makes it
hard for newbies is that there's no web site to browse the
sources and their histories.  There is
<http://git.savannah.gnu.org/cgit/emacs.git>, but it's
the history filtered through git, which is not the same
thing.  When I visit the latest version of the log for
the master, for example, I'm usually missing the last
few versions, and I often see two or more copies of a
particular change, due to the way that bzr is mirrored
into git.  It's pretty confusing.

Let me give you another example of something I did wrong.
I did my first checkin using 'git'.  (I didn't know bzr
was the only way to install changes.)  After a few hours
the checkin vanished.  There was no explanation or diagnostic.
OK, OK, so I did something stupid, but I was a *newbie*,
and it's a natural newbie mistake: the system should do
a better job of telling me what's going on.

Re: Still unable to build trunk

[Andreas Schwab]

> There is <http://git.savannah.gnu.org/cgit/emacs.git>, 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, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Still unable to build trunk

[Glenn Morris]

Paul Eggert wrote:

> Sure, another thing that makes it hard for newbies is that there's
> no web site to browse the sources and their histories.

We've been asking Savannah for this for over a year. There is no
visible progress.

http://savannah.gnu.org/support/?func=detailitem&item_id=107388
http://savannah.gnu.org/support/?func=detailitem&item_id=107142
https://lists.ubuntu.com/archives/bazaar/2010q4/070918.html
http://lists.gnu.org/archive/html/emacs-devel/2010-10/msg00721.html

etc.

There is a Launchpad mirror, obviously this is suboptimal too.
http://bazaar.launchpad.net/~vcs-imports/emacs/trunk/files

Re: Still unable to build trunk

[Richard Stallman]

    We've been asking Savannah for this for over a year. There is no
    visible progress.

Savannah is managed by volunteers.
Would one of you please volunteer to do this?

-- 
Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org

Re: Still unable to build trunk

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: eggert@cs.ucla.edu, eliz@gnu.org, jan.h.d@swipnet.se,
> 	emacs-devel@gnu.org, cyd@stupidchicken.com, jim@meyering.net
> Date: Tue, 25 Jan 2011 01:01:25 -0500
> 
>     We've been asking Savannah for this for over a year. There is no
>     visible progress.
> 
> Savannah is managed by volunteers.
> Would one of you please volunteer to do this?

There are no volunteers here that know enough about the related
software packages that need to be installed/configured for this to
work.  I think we should ask Bazaar maintainers or developers to
help.  (We've tried before; we should try again, IMO.)

Savannah loggerhead [was Re: Still unable to build trunk]

[Glenn Morris]

Eli Zaretskii wrote:

> There are no volunteers here that know enough about the related
> software packages that need to be installed/configured for this to
> work.  I think we should ask Bazaar maintainers or developers to
> help.  (We've tried before; we should try again, IMO.)

AFAICS, all the questions that were asked were answered:

https://lists.ubuntu.com/archives/bazaar/2010q4/070916.html 

If I were a Savannah administrator, I would just install loggerhead
0.18 and see if it Just Works with the now-sftp-based Bazaar service
running on Savannah. (I speak from total ignorance of both Savannah
and Loggerhead.)

Re: Still unable to build trunk

[Richard Stallman]

    There are no volunteers here that know enough about the related
    software packages that need to be installed/configured for this to
    work.

Someone could learn.

      I think we should ask Bazaar maintainers or developers to
    help.  (We've tried before; we should try again, IMO.)

How about posting on a Bazaar development discussion list?
That would reach a larger community.  Would you like to do it?


-- 
Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org

Re: Still unable to build trunk

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: rgm@gnu.org, eggert@cs.ucla.edu, jan.h.d@swipnet.se,
> 	emacs-devel@gnu.org, cyd@stupidchicken.com, jim@meyering.net
> Date: Tue, 25 Jan 2011 19:44:48 -0500
> 
>       I think we should ask Bazaar maintainers or developers to
>     help.  (We've tried before; we should try again, IMO.)
> 
> How about posting on a Bazaar development discussion list?
> That would reach a larger community.  Would you like to do it?

We did that before.  The response was that they think Savannah admins
should do this-and-that.  That was what Glenn mentioned in his message
in this thread.  Nothing else happened.

Re: Still unable to build trunk

[Lennart Borgman]

I just tried to build on w32 (with the tools I used before) and got
the error below. Is that expected at the moment?

gcc -I. -c -gdwarf-2 -g3  -DEMACSDEBUG   -Ic:/g/include
-fno-crossjumping -Demacs=1 -DHAVE_CONFIG_H -I../nt/inc -DHAVE_N
TGUI=1 -DUSE_CRT_DLL=1 -DPURESIZE=5000000 -o oo/i386/print.o print.c
print.c:53:21: ftoastr.h: No such file or directory
make[2]: *** [oo/i386/print.o] Error 1
make[2]: Leaving directory `C:/emacs-lp/bld/emacs/trunk/src'
make[1]: *** [bootstrap-temacs] Error 2
make[1]: Leaving directory `C:/emacs-lp/bld/emacs/trunk/src'
make: *** [bootstrap-gmake] Error 2

Re: Still unable to build trunk

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Wed, 26 Jan 2011 13:35:41 +0100
> Cc: Eli Zaretskii <eliz@gnu.org>, cyd@stupidchicken.com, jan.h.d@swipnet.se, 
> 	bug-gnulib@gnu.org, jim@meyering.net, emacs-devel@gnu.org
> 
> I just tried to build on w32 (with the tools I used before) and got
> the error below. Is that expected at the moment?

Yes. ftoastr is one of the few functions imported from gnulib lately.

Re: Still unable to build trunk

[Andy Moreton]

On Wed 26 Jan 2011, Lennart Borgman wrote:

> I just tried to build on w32 (with the tools I used before) and got
> the error below. Is that expected at the moment?
>
> gcc -I. -c -gdwarf-2 -g3  -DEMACSDEBUG   -Ic:/g/include
> -fno-crossjumping -Demacs=1 -DHAVE_CONFIG_H -I../nt/inc -DHAVE_N
> TGUI=1 -DUSE_CRT_DLL=1 -DPURESIZE=5000000 -o oo/i386/print.o print.c
> print.c:53:21: ftoastr.h: No such file or directory
> make[2]: *** [oo/i386/print.o] Error 1
> make[2]: Leaving directory `C:/emacs-lp/bld/emacs/trunk/src'
> make[1]: *** [bootstrap-temacs] Error 2
> make[1]: Leaving directory `C:/emacs-lp/bld/emacs/trunk/src'
> make: *** [bootstrap-gmake] Error 2

Yes. The build has been updated to use up to date files for upstream
gnulib (mostly in the new m4 and lib dirs). The change to the build
layout has broken the Win32 build scripts, and nobody has patched things
up yet.

    AndyM

Re: Still unable to build trunk

[Jim Meyering]

Lennart Borgman wrote:
> I just tried to build on w32 (with the tools I used before) and got
> the error below. Is that expected at the moment?
>
> gcc -I. -c -gdwarf-2 -g3  -DEMACSDEBUG   -Ic:/g/include
> -fno-crossjumping -Demacs=1 -DHAVE_CONFIG_H -I../nt/inc -DHAVE_N
> TGUI=1 -DUSE_CRT_DLL=1 -DPURESIZE=5000000 -o oo/i386/print.o print.c
> print.c:53:21: ftoastr.h: No such file or directory
> make[2]: *** [oo/i386/print.o] Error 1
> make[2]: Leaving directory `C:/emacs-lp/bld/emacs/trunk/src'
> make[1]: *** [bootstrap-temacs] Error 2
> make[1]: Leaving directory `C:/emacs-lp/bld/emacs/trunk/src'
> make: *** [bootstrap-gmake] Error 2

ftoastr.h should be in lib/, so the fix is to
do something like adding -I../lib to CFLAGS as used
when running make in src/

Re: Still unable to build trunk

[Jim Meyering]

Jim Meyering wrote:
> Lennart Borgman wrote:
>> I just tried to build on w32 (with the tools I used before) and got
>> the error below. Is that expected at the moment?
>>
>> gcc -I. -c -gdwarf-2 -g3  -DEMACSDEBUG   -Ic:/g/include
>> -fno-crossjumping -Demacs=1 -DHAVE_CONFIG_H -I../nt/inc -DHAVE_N
>> TGUI=1 -DUSE_CRT_DLL=1 -DPURESIZE=5000000 -o oo/i386/print.o print.c
>> print.c:53:21: ftoastr.h: No such file or directory
>> make[2]: *** [oo/i386/print.o] Error 1
>> make[2]: Leaving directory `C:/emacs-lp/bld/emacs/trunk/src'
>> make[1]: *** [bootstrap-temacs] Error 2
>> make[1]: Leaving directory `C:/emacs-lp/bld/emacs/trunk/src'
>> make: *** [bootstrap-gmake] Error 2
>
> ftoastr.h should be in lib/, so the fix is to
> do something like adding -I../lib to CFLAGS as used
> when running make in src/

Here's an untested patch to do that, assuming that srcdir==builddir.

From 15399c4cf788f89f82197c69884b2e5886c4f9b3 Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyering@redhat.com>
Date: Thu, 27 Jan 2011 10:36:57 +0100
Subject: [PATCH] fix w32 compilation failure

* makefile.w32-in (LOCAL_FLAGS): Add -I../lib, for gnulib-added
headers like ftoastr.h.  Reported by Lennart Borgman.
---
 src/ChangeLog       |    6 ++++++
 src/makefile.w32-in |    2 +-
 2 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/src/ChangeLog b/src/ChangeLog
index b864b92..b34d6b3 100644
--- a/src/ChangeLog
+++ b/src/ChangeLog
@@ -1,3 +1,9 @@
+2011-01-27  Jim Meyering  <meyering@redhat.com>
+
+	fix w32 compilation failure
+	* makefile.w32-in (LOCAL_FLAGS): Add -I../lib, for gnulib-added
+	headers like ftoastr.h.  Reported by Lennart Borgman.
+
 2011-01-26  Stefan Monnier  <monnier@iro.umontreal.ca>

 	Let the debugger continue to the normal handler (bug#7825).
diff --git a/src/makefile.w32-in b/src/makefile.w32-in
index 549acf8..8303999 100644
--- a/src/makefile.w32-in
+++ b/src/makefile.w32-in
@@ -28,7 +28,7 @@ EMACSLOADPATH=$(CURDIR)/../lisp
 # HAVE_CONFIG_H is required by some generic gnu sources stuck into
 # the emacs source tree.
 #
-LOCAL_FLAGS     = -Demacs=1 -DHAVE_CONFIG_H -I../nt/inc -DHAVE_NTGUI=1 $(EMACS_EXTRA_C_FLAGS)
+LOCAL_FLAGS     = -Demacs=1 -DHAVE_CONFIG_H -I../lib -I../nt/inc -DHAVE_NTGUI=1 $(EMACS_EXTRA_C_FLAGS)

 SRC             = .
 EMACS           = $(BLD)/emacs.exe
--
1.7.3.5.38.gb312b

Re: Still unable to build trunk

[Eli Zaretskii]

> From: Jim Meyering <jim@meyering.net>
> Cc: Paul Eggert <eggert@cs.ucla.edu>,  bug-gnulib@gnu.org,  cyd@stupidchicken.com,  emacs-devel@gnu.org,  Eli Zaretskii <eliz@gnu.org>,  jan.h.d@swipnet.se
> Date: Thu, 27 Jan 2011 10:38:27 +0100
> 
> > ftoastr.h should be in lib/, so the fix is to
> > do something like adding -I../lib to CFLAGS as used
> > when running make in src/
> 
> Here's an untested patch to do that, assuming that srcdir==builddir.

Thanks, but this is just the tip of the iceberg.  It will get print.c
to compile (maybe, I didn't try), but there are quite a few other
issues that need to be fixed before the w32 Emacs could be built.  For
starters, there will be unresolved externals, because ftoastr is not
linked in.  Then there's no lib-src/getopt_.h file anymore, so
programs in lib-src cannot be rebuilt.  Etc., etc.

People who build Emacs on Windows are best advised to wait until the
build is fixed, or fix it themselves (and push the changes to the
repo), than trying to fix errors one by one by hacking around them.

Re: Still unable to build trunk

[Lennart Borgman]

On Thu, Jan 27, 2011 at 12:16 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>
> People who build Emacs on Windows are best advised to wait until the
> build is fixed, or fix it themselves (and push the changes to the
> repo), than trying to fix errors one by one by hacking around them.

When was someone last able to build Emacs on w32? On other platforms?

Re: Still unable to build trunk

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Thu, 27 Jan 2011 12:20:37 +0100
> Cc: Jim Meyering <jim@meyering.net>, eggert@cs.ucla.edu, cyd@stupidchicken.com, 
> 	emacs-devel@gnu.org, jan.h.d@swipnet.se
> 
> On Thu, Jan 27, 2011 at 12:16 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > People who build Emacs on Windows are best advised to wait until the
> > build is fixed, or fix it themselves (and push the changes to the
> > repo), than trying to fix errors one by one by hacking around them.
> 
> When was someone last able to build Emacs on w32? On other platforms?

The gnulib merge happened on Jan 17 (revision 102878 on the trunk).
Since that moment, the w32 build is broken.

Re: Still unable to build trunk

[Paul Eggert]

On 01/27/11 03:31, Eli Zaretskii wrote:
>> When was someone last able to build Emacs on w32? On other platforms?
> The gnulib merge happened on Jan 17 (revision 102878 on the trunk).
> Since that moment, the w32 build is broken.

Non-Microsoft builds should all work now (or at least, if they fail, it shouldn't
be because of gnulib :-).  I don't know of any exceptions.

Re: Still unable to build trunk

[Darren Hoo]

On Fri, Jan 28, 2011 at 2:27 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:
>
> Non-Microsoft builds should all work now (or at least, if they fail, it shouldn't
> be because of gnulib :-).  I don't know of any exceptions.
>
>

Failing to configure

./configure: line 5995:
texinfo[^0-9]*([1-4][0-9]+|[5-9]|4\.[6-9]|4\.[1-5][0-9]+): command not
found
configure: error: You do not seem to have makeinfo >= 4.6, and your
source tree does not seem to have pre-built manuals in the `info' directory.
Either install a suitable version of makeinfo, or re-run configure
with the `--without-makeinfo' option to build without the manuals.

I have texinfo installed:

$ makeinfo --version
makeinfo (GNU texinfo) 4.13

Actually the cause of command not found in  line 5995:

 $MAKEINFO --version 2> /dev/null | $EGREP
'texinfo[^0-9]*([1-4][0-9]+|[5-9]|4\.[6-9]|4\.[1-5][0-9]+

is that EGREP here is not correctly set.  I can see that the value of
EGREP is empty.

Any clues?

Re: Still unable to build trunk

[Darren Hoo]

On Sat, Jan 29, 2011 at 7:49 PM, Darren Hoo <darren.hoo@gmail.com> wrote:
>
> Actually the cause of command not found in  line 5995:
>
>  $MAKEINFO --version 2> /dev/null | $EGREP
> 'texinfo[^0-9]*([1-4][0-9]+|[5-9]|4\.[6-9]|4\.[1-5][0-9]+
>
> is that EGREP here is not correctly set.  I can see that the value of
> EGREP is empty.
>
> Any clues?
>

autoreconf -I m4 solves  for me.

Sorry for the noise, I should really carefully check the full thread
before I post.

Re: Still unable to build trunk

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Wed, 26 Jan 2011 13:35:41 +0100
> Cc: Eli Zaretskii <eliz@gnu.org>, cyd@stupidchicken.com, jan.h.d@swipnet.se, 
> 	bug-gnulib@gnu.org, jim@meyering.net, emacs-devel@gnu.org
> 
> I just tried to build on w32 (with the tools I used before) and got
> the error below. Is that expected at the moment?
> 
> gcc -I. -c -gdwarf-2 -g3  -DEMACSDEBUG   -Ic:/g/include
> -fno-crossjumping -Demacs=1 -DHAVE_CONFIG_H -I../nt/inc -DHAVE_N
> TGUI=1 -DUSE_CRT_DLL=1 -DPURESIZE=5000000 -o oo/i386/print.o print.c
> print.c:53:21: ftoastr.h: No such file or directory
> make[2]: *** [oo/i386/print.o] Error 1
> make[2]: Leaving directory `C:/emacs-lp/bld/emacs/trunk/src'
> make[1]: *** [bootstrap-temacs] Error 2
> make[1]: Leaving directory `C:/emacs-lp/bld/emacs/trunk/src'
> make: *** [bootstrap-gmake] Error 2

Should be fixed now.

A better autogen.sh [was Re: Still unable to build trunk]

[Glenn Morris]

Stefan Monnier wrote:

> But if people can arrange Emacs's build so that it doesn't require a
> pre-build configure and yet is still easy to install under something
> like Debian stable, I could change my mind. It might even be a good
> change if it can help users figure out which packages need to be
> installed (autotools, header files, ...).

I'm not entirely sure what you want, but here is an attempt at a
hand-holding autogen.sh. Tested on RHEL4 and 5, Debian testing, and some
old version of Solaris. I would also update INSTALL.BZR.

The idea is, people would run autogen.sh the first time they checkout
from bzr. Subsequently, I assume the Makefiles are already correctly
set-up such that eg configure will be recreated if necessary. This might
require enable-maintainer-mode to be on by default in bzr checkouts, and
disabled in release tarfiles; I don't know.

Obviously there would be some teething problems in the transition period
when configure disappears from the repo.


#!/bin/sh
### autogen.sh - tool to help build Emacs from a bzr checkout

## Copyright (C) 2011  Free Software Foundation, Inc.

## This file is part of GNU Emacs.

## GNU Emacs is free software: you can redistribute it and/or modify
## it under the terms of the GNU General Public License as published by
## the Free Software Foundation, either version 3 of the License, or
## (at your option) any later version.

## GNU Emacs is distributed in the hope that it will be useful,
## but WITHOUT ANY WARRANTY; without even the implied warranty of
## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
## GNU General Public License for more details.

## You should have received a copy of the GNU General Public License
## along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.

### Commentary:

## The Emacs bzr repository does not include the configure script
## (and associated helpers).  The first time you fetch Emacs from bzr,
## run this script to generate the necessary files.
## For more details, see the file INSTALL.BZR.

### Code:

## Tools we need:
progs="autoconf automake"

## Minimum versions we need:
autoconf_min=`sed -n 's/^ *AC_PREREQ(\([0-9\.]*\)).*/\1/p' configure.in`

## FIXME how to determine this from the sources?
automake_min=1.11


## $1 = program, eg "autoconf".
## Echo the version string, eg "2.59".
## FIXME does not handle things like "1.4a", but AFAIK those are
## all old versions, so it is OK to fail there.
## Also note that we do not handle micro versions.
get_version ()
{
    $1 --version 2>&1 | sed -n '1 s/.* \([1-9][0-9\.]*\).*/\1/p'
}

## $1 = version string, eg "2.59"
## Echo the major version, eg "2".
major_version ()
{
    echo $1 | sed -e 's/\([0-9][0-9]*\)\..*/\1/'
}

## $1 = version string, eg "2.59"
## Echo the minor version, eg "59".
minor_version ()
{
    echo $1 | sed -e 's/[0-9][0-9]*\.\([0-9][0-9]*\).*/\1/'
}

## $1 = program
## $2 = minimum version.
## Return 0 if program is present with version >= minumum version.
## Return 1 if program is missing.
## Return 2 if program is present but too old.
## Return 3 for unexpected error (eg failed to parse version).
check_version ()
{
    have_version=`get_version $1`

    [ x"$have_version" = x ] && return 1

    have_maj=`major_version $have_version`
    need_maj=`major_version $2`

    [ x"$have_maj" != x ] && [ x"$need_maj" != x ] || return 3

    [ $have_maj -gt $need_maj ] && return 0
    [ $have_maj -lt $need_maj ] && return 2

    have_min=`minor_version $have_version`
    need_min=`minor_version $2`

    [ x"$have_min" != x ] && [ x"$need_min" != x ] || return 3

    [ $have_min -ge $need_min ] && return 0
    return 2
}


cat <<EOF
Checking whether you have the necessary tools...
(Read INSTALL.BZR for more details on building Emacs)

EOF

missing=

for prog in $progs; do

    eval min=\$${prog}_min

    echo "Checking for $prog (need at least version $min)..."

    check_version $prog $min

    retval=$?

    case $retval in
        0) stat="ok" ;;
        1) stat="missing" ;;
        2) stat="too old" ;;
        *) stat="unable to check" ;;
    esac

    echo $stat

    if [ $retval -ne 0 ]; then
        missing="$missing $prog"
        eval ${prog}_why=\""$stat"\"
    fi

done


if [ x"$missing" != x ]; then

    cat <<EOF

Building Emacs from Bzr requires the following specialized programs:
EOF

    for prog in $progs; do
        eval min=\$${prog}_min

        echo "$prog (minimum version $min)"
    done


    cat <<EOF

Your system seems to be missing the following tool(s):
EOF

    for prog in $missing; do
        eval why=\$${prog}_why

        echo "$prog ($why)"
    done

    cat <<EOF

If you think you have the required tools, please add them to your PATH
and re-run this script.

Otherwise, please try installing them.
On systems using rpm and yum, try: "yum install PACKAGE"
On systems using dpkg and apt, try: "apt-get install PACKAGE"
Then re-run this script.

If you do not have permission to do this, or if the version provided
by your system is too old, it is normally straightforward to build
these packages from source.  You can find the sources at:

ftp://ftp.gnu.org/gnu/PACKAGE/

Download the package (make sure you get at least the minimum version
listed above), extract it using tar, then run configure, make,
make install.  Add the installation directory to your PATH and re-run
this script.

If you know that the required versions are in your PATH, but this
script has made an error, then you can simply run

autoreconf -I m4

instead of this script.
Please report any errors so that we can improve this script.
EOF

    exit 1
fi

echo "Your system has the required tools, running autoreconf..."


## Let autoreconf figure out what, if anything, needs doing.
autoreconf -I m4 || exit $?

echo "You can now run \`configure'."

exit 0

### autogen.sh ends here

Re: A better autogen.sh [was Re: Still unable to build trunk]

[Stefan Monnier]

>> But if people can arrange Emacs's build so that it doesn't require a
>> pre-build configure and yet is still easy to install under something
>> like Debian stable, I could change my mind. It might even be a good
>> change if it can help users figure out which packages need to be
>> installed (autotools, header files, ...).
> I'm not entirely sure what you want,

I'm glad, because I don't either, so otherwise it would be creepy.

> but here is an attempt at a hand-holding autogen.sh.  Tested on RHEL4
> and 5, Debian testing, and some old version of Solaris.  I would also
> update INSTALL.BZR.

Looks like a good proposal, thanks.

> The idea is, people would run autogen.sh the first time they checkout
> from bzr. Subsequently, I assume the Makefiles are already correctly
> set-up such that eg configure will be recreated if necessary. This might
> require enable-maintainer-mode to be on by default in bzr checkouts, and
> disabled in release tarfiles; I don't know.

That'd be the idea, yes.
What do people think of it?


        Stefan

Re: A better autogen.sh [was Re: Still unable to build trunk]

[Thien-Thi Nguyen]

() Stefan Monnier <monnier@IRO.UMontreal.CA>
() Tue, 08 Mar 2011 14:51:23 -0500

   That'd be the idea, yes.
   What do people think of it?

The "please report any errors" message should include an
appropriate email address or URL.  Otherwise, pretty cool!

Re: A better autogen.sh

[Glenn Morris]

Stefan Monnier wrote:

> What do people think of it?

Not many responses. Should I go ahead with installing this and removing
configure?

Re: A better autogen.sh

[Paul Eggert]

On 03/15/2011 01:22 PM, Glenn Morris wrote:
> Should I go ahead with installing this and removing configure?

It's not just 'configure'; you can also remove
aclocal.m4, lib/Makefile.in, and src/config.in.

It looks good as far as it goes.  Perhaps at some
point we can add checks for other build prerequisites
(e.g., GNU m4 versions) but there's no pressing need
to do that.

Re: A better autogen.sh

[Glenn Morris]

Paul Eggert wrote:

> On 03/15/2011 01:22 PM, Glenn Morris wrote:
>> Should I go ahead with installing this and removing configure?
>
> It's not just 'configure'; you can also remove
> aclocal.m4, lib/Makefile.in, and src/config.in.

I know; except I cannot remove src/config.in because the MS Windows
build uses it IIRC.

Re: A better autogen.sh

[Glenn Morris]

Glenn Morris wrote (on Tue, 15 Mar 2011 at 18:09 -0400):

> I know; except I cannot remove src/config.in because the MS Windows
> build uses it IIRC.

Or maybe just MS DOS? Can't remember...

If we went ahead with this, I think it would also be possible to set
AC_PREREQ in configure.in back to 2.62, if desired. 2.62 had some
fixed bugs that were relevant to Emacs. But AFAIK, all bumps of
AC_PREREQ after that were only in an attempt to prevent the version
churn of configure in the Emacs repository.

Re: A better autogen.sh

[Paul Eggert]

On 03/15/2011 03:09 PM, Glenn Morris wrote:
> I cannot remove src/config.in because the MS Windows
> build uses it IIRC.

MS-DOS, I think.  But this should not be a problem, as we can move
src/config.in to msdos/config.in and the MS-DOS build can use
msdos/config.in instead.  msdos/config.in can start off being a copy
of the old src/config.in but can be maintained by hand, as needed.
This would lessen the need for tight coupling between the mainline and
the DOS version.

If we can't do something like this, then I don't see the point of
removing 'configure' from the repository.  'configure' and
src/config.in must be kept in sync, and it'd be asking for trouble if
one is in the repository and the other is not.

Re: A better autogen.sh

[Eli Zaretskii]

> Date: Tue, 15 Mar 2011 15:58:30 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> Cc: emacs-devel@gnu.org
> 
> On 03/15/2011 03:09 PM, Glenn Morris wrote:
> > I cannot remove src/config.in because the MS Windows
> > build uses it IIRC.
> 
> MS-DOS, I think.

Yes, the MS-DOS port edits config.in into config.h.

> But this should not be a problem, as we can move
> src/config.in to msdos/config.in and the MS-DOS build can use
> msdos/config.in instead.  msdos/config.in can start off being a copy
> of the old src/config.in but can be maintained by hand, as needed.

What would it take to maintain it by hand?

> This would lessen the need for tight coupling between the mainline and
> the DOS version.

What "tight coupling"?

> If we can't do something like this, then I don't see the point of
> removing 'configure' from the repository.  'configure' and
> src/config.in must be kept in sync, and it'd be asking for trouble if
> one is in the repository and the other is not.

autogen.sh could begin by removing config.in.

Re: A better autogen.sh

[Glenn Morris]

Eli Zaretskii wrote:

> What would it take to maintain it by hand?

mv src/config.in msdos/config.in, change config.bat to look in the new
place, you update the version of msdos/config.in in the repo whenever
you think it is needed, by simply copying your src/ version there.
(This seems to be how the MS Windows port works?)

> autogen.sh could begin by removing config.in.

That's a big ugly, I hope the previous solution is acceptable to you.

Re: A better autogen.sh

[Glenn Morris]

Glenn Morris wrote:

> That's a big ugly, I hope the previous solution is acceptable to you.

s/big/bit

Re: A better autogen.sh

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: Paul Eggert <eggert@cs.ucla.edu>,  emacs-devel@gnu.org
> Date: Wed, 16 Mar 2011 00:14:35 -0400
> 
> Eli Zaretskii wrote:
> 
> > What would it take to maintain it by hand?
> 
> mv src/config.in msdos/config.in, change config.bat to look in the new
> place, you update the version of msdos/config.in in the repo whenever
> you think it is needed, by simply copying your src/ version there.

I didn't mean the trivia.  I meant this part:

  you update the version of msdos/config.in in the repo whenever
  you think it is needed

How would I know that a change needed, and (more importantly) how
would I know what to update there?

And what do you mean by "your src/ version there"?  How will it help,
if it is just a result of editing config.in with Sed?  I have no other
src/ version.

> (This seems to be how the MS Windows port works?)

nt/config.nt is maintained by hand, allright, but that's done by
tracking changes in src/config.in.  If src/config.in is removed from
the repository, maintaining nt/config.nt will hit a snag, because
there will be no file to "bzr diff" against the previous version and
see what's changed, and how else would someone know how to update
config.nt?

> > autogen.sh could begin by removing config.in.
> 
> That's a bit ugly

Why ugly, move-if-change should be fine.  What am I missing?

> I hope the previous solution is acceptable to you. 

It will be, if there's a practical way to know how to update the
private config.in without having a Posix platform nearby.

Re: A better autogen.sh

[Paul Eggert]

On 03/15/2011 10:53 PM, Eli Zaretskii wrote:
> It will be, if there's a practical way to know how to update the
> private config.in without having a Posix platform nearby.

The same way you know now.  Somebody sends email.
Or, perhaps Emacs doesn't build on MS Windows, and
the diagnostics reveal the problem.

Other possibilities include running GNU/Linux under a virtual
machine on a Windows machine; or running Autoconf and Automake
under Windows, and then generating config.in directly
on the Windows machine.  Or one can grab a recent pretest
version.

This is not an exhaustive list.
There are other simple and practical ways to address
this problem, which don't require putting
automatically-generated output into the repository.

>> This would lessen the need for tight coupling between the mainline and
>> the DOS version.
> What "tight coupling"?

Currently, when I edit files under src/ and src-lib/,
I often have to worry about porting to MS Windows or MS-DOS.
There are many #ifdefs and similar constructs that complicate
the code, and are needed only because of the MS ports.
It would be better if this porting code were isolated
to the msdos/ and nt/ directories, so that developers
under GNU and GNUish systems did not have to look at it
or worry about it.

The src/config.in file is one example of these #ifdef-like
constructs.  The main reason we put src/config.in in the
repository, and keep track of it and commit it by hand,
is for the MS Windows port.  If we can think of another
way to handle this, it would save us work.

Moving src/config.in to msdos/config.in is one way to do that.
It may require a bit more work on the part of the Windows
developers, but it'll require less work from the rest of us,
and overall it will be a win.

Re: A better autogen.sh

[Glenn Morris]

Eli Zaretskii wrote:

> How would I know that a change needed, and (more importantly) how
> would I know what to update there?

I assume you at least have access to a POSIX platform, eg fencepost,
where you can run autoconf once in a while.

> And what do you mean by "your src/ version there"?  How will it help,
> if it is just a result of editing config.in with Sed?  I have no other
> src/ version.

The src/config.in version you get from running autoconf on a POSIX
platform.

> nt/config.nt is maintained by hand, allright, but that's done by
> tracking changes in src/config.in.  If src/config.in is removed from
> the repository, maintaining nt/config.nt will hit a snag, because
> there will be no file to "bzr diff" against the previous version and
> see what's changed, and how else would someone know how to update
> config.nt?

Whenever an AC_DEFINE is changed in configure.in, config.in might need
to be changed. Or, diff your generated src/config.in against the
msdos/config.in in the repository.

>> > autogen.sh could begin by removing config.in.
>> 
>> That's a bit ugly
>
> Why ugly, move-if-change should be fine.  What am I missing?

It's ugly because then everybody has a src/config.in file that appears
to be locally modified all the time. You're also relying on someone with
access to a POSIX platform to keep regenerating src/config.in and
committing it whenever it changes. Trying to avoid the need to do this
is part of the motivation for this proposal.

> It will be, if there's a practical way to know how to update the
> private config.in without having a Posix platform nearby.

I hope it's not unreasonable to assume the MS-DOS maintainer can access
a POSIX platform once in a while. Every Emacs developer can get a
fencepost account.

If it were me, I'd keep the same version of autoconf installed. I'd run
it periodically and diff the generated src/config.in against
msdos/config.in. If there was a difference, I'd copy the former to the
latter and commit it.


Personally I think it's still worth removing configure even if
config.in has to stay, because the latter changes a lot less often.
But I hope src/config.in doesn't have to be kept just for the sake of
MS.

Re: A better autogen.sh

[Eli Zaretskii]

> Date: Tue, 15 Mar 2011 23:39:59 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: Glenn Morris <rgm@gnu.org>, emacs-devel@gnu.org
> 
> On 03/15/2011 10:53 PM, Eli Zaretskii wrote:
> > It will be, if there's a practical way to know how to update the
> > private config.in without having a Posix platform nearby.
> 
> The same way you know now.  Somebody sends email.
> Or, perhaps Emacs doesn't build on MS Windows, and
> the diagnostics reveal the problem.

When that happens now, I can diff src/config.in against an older
version.

> Other possibilities include running GNU/Linux under a virtual
> machine on a Windows machine; or running Autoconf and Automake
> under Windows, and then generating config.in directly
> on the Windows machine.  Or one can grab a recent pretest
> version.
> 
> This is not an exhaustive list.
> There are other simple and practical ways to address
> this problem, which don't require putting
> automatically-generated output into the repository.

They are neither simple nor practical, sorry.  I hope autoconf experts
can come up with something that is simpler and more practical.
Unfortunately, I cannot myself suggest anything, as I don't know
enough about the machinery involved.

> >> This would lessen the need for tight coupling between the mainline and
> >> the DOS version.
> > What "tight coupling"?
> 
> Currently, when I edit files under src/ and src-lib/,
> I often have to worry about porting to MS Windows or MS-DOS.

And I need to worry about Posix platforms when I edit files in those
same directories.  So what?  C is C and Lisp is Lisp and
makefile.w32-in is just a Makefile.  There's no magic about that.

> There are many #ifdefs and similar constructs that complicate
> the code, and are needed only because of the MS ports.

There are ifdefs because of Solaris as well.  So what?  We try to keep
them to the absolute minimum, and when someone points out to one of
them that is used by DOS alone, I'm always happy to move it away in
any reasonably practical way.

> It would be better if this porting code were isolated
> to the msdos/ and nt/ directories, so that developers
> under GNU and GNUish systems did not have to look at it
> or worry about it.

It is already done, as much as is practical.

> The src/config.in file is one example of these #ifdef-like
> constructs.  The main reason we put src/config.in in the
> repository, and keep track of it and commit it by hand,
> is for the MS Windows port.

It was never because of MS-DOS.  This file was there from day one.
This is the first time removal of this file is considered.  Until now
it was used by every platform.

> If we can think of another way to handle this, it would save us
> work.

Fine with me, but please try to be less unkind to maintainers of
non-Posix platforms.  They are volunteers like yourself.

If there's a reasonable way of gleaning the information about the
added and removed #defines in src/config.in, I will be the first to
embrace it.  What you suggested until now is unreasonable.

> Moving src/config.in to msdos/config.in is one way to do that.
> It may require a bit more work on the part of the Windows
> developers, but it'll require less work from the rest of us,
> and overall it will be a win.

A shockingly egotistic position.  MS-Windows is my main development
platform for working on the bidirectional editing support.  Maybe you
will also claim that bidirectional editing is not needed by "the rest
of us", so my work on that is not important.

Re: A better autogen.sh

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: eggert@cs.ucla.edu,  emacs-devel@gnu.org
> Date: Wed, 16 Mar 2011 02:43:10 -0400
> 
> Eli Zaretskii wrote:
> 
> > How would I know that a change needed, and (more importantly) how
> > would I know what to update there?
> 
> I assume you at least have access to a POSIX platform, eg fencepost,
> where you can run autoconf once in a while.

What would you or other maintainers say if I suggested a change that
would require them to log in to a remote system each time they wanted
to build the latest trunk, generate some file there, then copy it to
their local machine?  How can a member of a team even suggest
something like that to another member?

> > nt/config.nt is maintained by hand, allright, but that's done by
> > tracking changes in src/config.in.  If src/config.in is removed from
> > the repository, maintaining nt/config.nt will hit a snag, because
> > there will be no file to "bzr diff" against the previous version and
> > see what's changed, and how else would someone know how to update
> > config.nt?
> 
> Whenever an AC_DEFINE is changed in configure.in, config.in might need
> to be changed.

I don't think this is enough.  Don't other m4/* files contribute to
config.in eventually?  If I'm mistaken and it's all in configure.in,
this could be an okay alternative.  Even if it's not only in
configure.in, but grepping for AC_DEFINE in *.m4 files is all that's
needed, that would be good enough to make this a reasonable way of
maintaining the Windows and DOS config.h files.  I hope some autoconf
expert could tell one way or the other.

> >> > autogen.sh could begin by removing config.in.
> >> 
> >> That's a bit ugly
> >
> > Why ugly, move-if-change should be fine.  What am I missing?
> 
> It's ugly because then everybody has a src/config.in file that appears
> to be locally modified all the time.

I don't see why it will appear modified, if its content is identical.
bzr is smart enough to not flag such files as modified.  Or am I
missing something?

> > It will be, if there's a practical way to know how to update the
> > private config.in without having a Posix platform nearby.
> 
> I hope it's not unreasonable to assume the MS-DOS maintainer can access
> a POSIX platform once in a while.

I rather hope this will not the way, because it _is_ unreasonable,
both in practical terms and in its underlying attitude, which frankly
is revolting.

> If it were me, I'd keep the same version of autoconf installed. I'd run
> it periodically and diff the generated src/config.in against
> msdos/config.in. If there was a difference, I'd copy the former to the
> latter and commit it.

The trouble is, we keep requiring newer versions of autoconf from time
to time, and later more frequently than in the past.  Experience shows
that upgrading autoconf on fencepost involves asking GNU sysadmins to
do that, which takes a non-trivial amount of time and sometimes
repeated pinging.  I would like to avoid that, because it will make my
life as Emacs developer miserable.  Likewise with other contributors
to the maintenance of the Windows port (I don't think they even have a
fencepost account, btw).

> But I hope src/config.in doesn't have to be kept just for the sake
> of MS.

Me too, but it will take someone with working knowledge of the
machinery involved and a friendly attitude to help resolve this in a
way that we all can live with.

Re: A better autogen.sh

[Paul Eggert]

On 03/16/2011 01:10 AM, Eli Zaretskii wrote:

>> > The src/config.in file is one example of these #ifdef-like
>> > constructs.  The main reason we put src/config.in in the
>> > repository, and keep track of it and commit it by hand,
>> > is for the MS Windows port.
> It was never because of MS-DOS.  This file was there from day one.
> This is the first time removal of this file is considered.

The idea has been considered before, I expect.  But it's not that
important whether the idea is new or old.  What's important
is whether it's a good idea.  Right now, the file is in the repository
only because of the MS-DOS port, and that suggests that the
repository copy should be moved to the msdos/ subdirectory.

Whenever maintainers feel it necessary, they could autogenerate a
new version, copy it into the msdos/ subdirectory by hand, and
commit the result.  That should be enough to address concerns
about the MS-DOS port.

> And I need to worry about Posix platforms when I edit files in those
> same directories.  So what?

Emacs is part of the GNU project, and the main goal
of the GNU project, as I'm sure you know, is to develop
a complete Unix-like operating system that is free software.
So, it's inherent to Emacs that its code needs to be working
on Unix-like platforms.

The MS Windows port is not inherent to Emacs in that way.
Where the MS Windows port can be done with minimal
disruption to Emacs development, then that's fine;
but where the MS Windows port presents an obstacle to
improving how Emacs is maintained, that's a problem.
In this discussion, we're trying to address one of these
problems.

> Maybe you will also claim that bidirectional editing is not needed by "the rest
> of us", so my work on that is not important.

I would not dream of making such a claim.  But that is a
separate issue, and I don't see why it is relevant.

Re: A better autogen.sh

[Paul Eggert]

On 03/16/2011 01:47 AM, Eli Zaretskii wrote:
> The trouble is, we keep requiring newer versions of autoconf from time
> to time, and later more frequently than in the past.  Experience shows
> that upgrading autoconf on fencepost involves asking GNU sysadmins to
> do that, which takes a non-trivial amount of time and sometimes
> repeated pinging.

That may have been a problem in the past, but it's not a problem now,
because fencepost's /usr/bin/autoconf is Autoconf 2.65, which
is good enough for Emacs.

In the long run I don't expect this to be a major issue,
but if I'm wrong, I can volunteer to keep
good-enough versions of automake and autoconf installed on
fencepost, under ~eggert/bin say, and that will be enough to
get it to work.

Re: A better autogen.sh

[Eli Zaretskii]

> Date: Wed, 16 Mar 2011 02:08:21 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: rgm@gnu.org, emacs-devel@gnu.org
> 
> On 03/16/2011 01:10 AM, Eli Zaretskii wrote:
> 
> >> > The src/config.in file is one example of these #ifdef-like
> >> > constructs.  The main reason we put src/config.in in the
> >> > repository, and keep track of it and commit it by hand,
> >> > is for the MS Windows port.
> > It was never because of MS-DOS.  This file was there from day one.
> > This is the first time removal of this file is considered.
> 
> The idea has been considered before, I expect.

I'm not getting younger, and my memory is not getting better, but I
cannot recall such a discussion in the past nor a decision to drop the
idea because of non-Posix platforms.

> Right now, the file is in the repository only because of the MS-DOS
> port, and that suggests that the repository copy should be moved to
> the msdos/ subdirectory.

No, right now the file is in the repository because it was always
there, and we are discussing whether to remove it.

> Whenever maintainers feel it necessary, they could autogenerate a
> new version, copy it into the msdos/ subdirectory by hand, and
> commit the result.  That should be enough to address concerns
> about the MS-DOS port.

It will be enough if someone takes upon themselves to perform this
duty as a matter of routine.  Are you volunteering for the job?

> > And I need to worry about Posix platforms when I edit files in those
> > same directories.  So what?
> 
> Emacs is part of the GNU project, and the main goal
> of the GNU project, as I'm sure you know, is to develop
> a complete Unix-like operating system that is free software.
> So, it's inherent to Emacs that its code needs to be working
> on Unix-like platforms.

Not on Unix-like platforms.  On GNU platforms.  That's not the same.

I could understand an argument that supporting Unix-like platforms is
easier.  (And even the "easier" argument is IMO minor, looking at all
the stuff in lib/ that is needed to support those Unix-like non-GNU
platforms.)  But the argument about being part of the GNU project is
bogus, because there's no difference between MS-Windows and Solaris in
that respect: they are both proprietary platforms.

> > Maybe you will also claim that bidirectional editing is not needed
> > by "the rest of us", so my work on that is not important.
> 
> I would not dream of making such a claim.  But that is a
> separate issue, and I don't see why it is relevant.

It is relevant because if I lose the ability to build Emacs with no
fuss on Windows, I will be unable to continue my work on bidi.

Re: A better autogen.sh

[Eli Zaretskii]

> Date: Wed, 16 Mar 2011 02:23:09 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: Glenn Morris <rgm@gnu.org>, emacs-devel@gnu.org
> 
> On 03/16/2011 01:47 AM, Eli Zaretskii wrote:
> > The trouble is, we keep requiring newer versions of autoconf from time
> > to time, and later more frequently than in the past.  Experience shows
> > that upgrading autoconf on fencepost involves asking GNU sysadmins to
> > do that, which takes a non-trivial amount of time and sometimes
> > repeated pinging.
> 
> That may have been a problem in the past, but it's not a problem now,
> because fencepost's /usr/bin/autoconf is Autoconf 2.65, which
> is good enough for Emacs.
> 
> In the long run I don't expect this to be a major issue,
> but if I'm wrong, I can volunteer to keep
> good-enough versions of automake and autoconf installed on
> fencepost, under ~eggert/bin say, and that will be enough to
> get it to work.

Thanks, but I don't think it is practical to make the maintenance of
non-Posix platform depend on people who are not interested in Emacs
running on those platforms.

Could you please instead tell if new and modified #define's in
config.in can be detected by grepping certain files for AC_DEFINE or
similar directives, and which files to grep?

If it is possible to specify which files to grep for what patterns,
that would open a way for a practical maintenance routine of config.in
outside the main directories of the Emacs tree, and we could then put
this issue to rest (until the next time, which will doubtlessly come).

Re: A better autogen.sh

[joakim]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Wed, 16 Mar 2011 02:08:21 -0700
>> From: Paul Eggert <eggert@cs.ucla.edu>
>> CC: rgm@gnu.org, emacs-devel@gnu.org
>> 
>> On 03/16/2011 01:10 AM, Eli Zaretskii wrote:
>> 
>> >> > The src/config.in file is one example of these #ifdef-like
>> >> > constructs.  The main reason we put src/config.in in the
>> >> > repository, and keep track of it and commit it by hand,
>> >> > is for the MS Windows port.
>> > It was never because of MS-DOS.  This file was there from day one.
>> > This is the first time removal of this file is considered.
>> 
>> The idea has been considered before, I expect.
>
> I'm not getting younger, and my memory is not getting better, but I
> cannot recall such a discussion in the past nor a decision to drop the
> idea because of non-Posix platforms.
>
>> Right now, the file is in the repository only because of the MS-DOS
>> port, and that suggests that the repository copy should be moved to
>> the msdos/ subdirectory.
>
> No, right now the file is in the repository because it was always
> there, and we are discussing whether to remove it.
>
>> Whenever maintainers feel it necessary, they could autogenerate a
>> new version, copy it into the msdos/ subdirectory by hand, and
>> commit the result.  That should be enough to address concerns
>> about the MS-DOS port.
>
> It will be enough if someone takes upon themselves to perform this
> duty as a matter of routine.  Are you volunteering for the job?

Would it be any help if anyone* set up a cron job to do this
automatically? That is, run autoconf and check in the results in the dos
dir?

* for instance a version of me from a parallell dimension with copious
  spare time.

>
>> > And I need to worry about Posix platforms when I edit files in those
>> > same directories.  So what?
>> 
>> Emacs is part of the GNU project, and the main goal
>> of the GNU project, as I'm sure you know, is to develop
>> a complete Unix-like operating system that is free software.
>> So, it's inherent to Emacs that its code needs to be working
>> on Unix-like platforms.
>
> Not on Unix-like platforms.  On GNU platforms.  That's not the same.
>
> I could understand an argument that supporting Unix-like platforms is
> easier.  (And even the "easier" argument is IMO minor, looking at all
> the stuff in lib/ that is needed to support those Unix-like non-GNU
> platforms.)  But the argument about being part of the GNU project is
> bogus, because there's no difference between MS-Windows and Solaris in
> that respect: they are both proprietary platforms.
>
>> > Maybe you will also claim that bidirectional editing is not needed
>> > by "the rest of us", so my work on that is not important.
>> 
>> I would not dream of making such a claim.  But that is a
>> separate issue, and I don't see why it is relevant.
>
> It is relevant because if I lose the ability to build Emacs with no
> fuss on Windows, I will be unable to continue my work on bidi.

-- 
Joakim Verona

Re: A better autogen.sh

[Juanma Barranquero]

I was going to answer to Paul, but I think these comments by Eli are
all that needs be said, so I'm repeating them:


> There are ifdefs because of Solaris as well.  So what?  We try to keep
> them to the absolute minimum, and when someone points out to one of
> them that is used by DOS alone, I'm always happy to move it away in
> any reasonably practical way.

[...]

> Fine with me, but please try to be less unkind to maintainers of
> non-Posix platforms.  They are volunteers like yourself.

[...]

> A shockingly egotistic position.  MS-Windows is my main development
> platform for working on the bidirectional editing support.  Maybe you
> will also claim that bidirectional editing is not needed by "the rest
> of us", so my work on that is not important.

Agreed at 100%.

    Juanma

Re: A better autogen.sh

[Juanma Barranquero]

On Wed, Mar 16, 2011 at 10:08, Paul Eggert <eggert@cs.ucla.edu> wrote:

> Emacs is part of the GNU project, and the main goal
> of the GNU project, as I'm sure you know, is to develop
> a complete Unix-like operating system that is free software.

Noooo. The main goal is to develop a complete Unix-like operating
system that it is free software, *and* to get people to use it.
Witness Hurd.

The very fact that the Windows port exists and was integrated into
mainline Emacs is, IIRC what I've read here and elsewhere, because
giving non-free users free alternatives is seen as a good way to teach
them about freedom. Hey, I'm a Windows user through and through, and
I'm here, collaborating (however sparsely) on a free project. That's a
consequence of having Emacs on Windows.

> The MS Windows port is not inherent to Emacs in that way.
> Where the MS Windows port can be done with minimal
> disruption to Emacs development, then that's fine;
> but where the MS Windows port presents an obstacle to
> improving how Emacs is maintained, that's a problem.
> In this discussion, we're trying to address one of these
> problems.

That would inspire much more confidence, were not for the fact that
lately it seems that *every* little nuance related to Windows (or
MS-DOS) is sen as an "obstacle to improving" Emacs. Apparently there
is people who would sleep more soundly if every trace of Windows were
removed from Emacs.

> I would not dream of making such a claim.  But that is a
> separate issue, and I don't see why it is relevant.

Because it would not even exists, were not for the Windows and MS-DOS
ports, which the bidi developer uses, maintains and enjoys. Battling
an uphill struggle, I would add, as relatively recent threads (less
than two months old) demonstrate quite clearly.


    Juanma

Re: A better autogen.sh

[Eli Zaretskii]

> From: joakim@verona.se
> Cc: Paul Eggert <eggert@cs.ucla.edu>,  emacs-devel@gnu.org
> Date: Wed, 16 Mar 2011 11:47:58 +0100
> 
> Would it be any help if anyone* set up a cron job to do this
> automatically? That is, run autoconf and check in the results in the dos
> dir?

Yes, that would be a good solution, thanks for bringing it up.  The
only concern would be: can we trust the machine on which this job runs
to exist and continue running it for as long as Emacs exists?  Doing
that on savannah (if possible) might solve this concern as well.

Re: A better autogen.sh

[joakim]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: joakim@verona.se
>> Cc: Paul Eggert <eggert@cs.ucla.edu>,  emacs-devel@gnu.org
>> Date: Wed, 16 Mar 2011 11:47:58 +0100
>> 
>> Would it be any help if anyone* set up a cron job to do this
>> automatically? That is, run autoconf and check in the results in the dos
>> dir?
>
> Yes, that would be a good solution, thanks for bringing it up.  The
> only concern would be: can we trust the machine on which this job runs
> to exist and continue running it for as long as Emacs exists?  Doing
> that on savannah (if possible) might solve this concern as well.

The non-existence of Gnu servers capable of hosting continuous
integration seems to be a big issue.

I'm trying to draw my straw to the stack but my servers are in my
cupboard. At least I have a decent UPS and decent bandwidth. My ISP
won't give me a fixed IP though.

As for longevity I seem to be destined to be an Emacs aficionado until I
acquire Alzheimer's.

-- 
Joakim Verona

Re: A better autogen.sh

[Eli Zaretskii]

> From: joakim@verona.se
> Cc: eggert@cs.ucla.edu,  emacs-devel@gnu.org
> Date: Wed, 16 Mar 2011 13:25:02 +0100
> 
> I'm trying to draw my straw to the stack but my servers are in my
> cupboard. At least I have a decent UPS and decent bandwidth. My ISP
> won't give me a fixed IP though.
> 
> As for longevity I seem to be destined to be an Emacs aficionado until I
> acquire Alzheimer's.

That's good enough for me, if others will agree.  And bandwidth
shouldn't be a problem, for such a small file.

Thanks.

Re: A better autogen.sh

[Stefan Monnier]

>> What do people think of it?
> Not many responses. Should I go ahead with installing this and removing
> configure?

I recommend we take a similar approach as what we did for loaddefs.el:
move the bzr-controlled file elsewhere rather than deleting it.
That's also what I do in my own local branch, because it avoid silly
conflicts "can't merge change to deleted file".

I.e. make a "boostrap-files" (or should it say "generated-files"?)
directory.  Move configure, aclocal.m4, src/config.in (and
lisp/ldefs-boot.el) to it, then install your change (tho change the
instructions to say "run ./configure" rather than "run configure" since
we should not encourage people to have . in their PATH).

We should try and keep the bootstrap-files more or less up to date
(e.g. so the MS-DOS port can use them) for now, so that people who
insist on not installing autoconf can still bootstrap.


        Stefan

Re: A better autogen.sh

[Glenn Morris]

Eli Zaretskii wrote:

> What would you or other maintainers say if I suggested a change that
> would require them to log in to a remote system each time they wanted
> to build the latest trunk, generate some file there, then copy it to
> their local machine?  How can a member of a team even suggest
> something like that to another member?

If I try to put myself in the position of someone maintaining an MS port
of GNU software, I honestly don't think I'd mind needing to access a GNU
host once in a while. That's why I suggested it, I was trying to help.

>> It's ugly because then everybody has a src/config.in file that appears
>> to be locally modified all the time.
>
> I don't see why it will appear modified, if its content is identical.
> bzr is smart enough to not flag such files as modified.  Or am I
> missing something?

It's only identical if everyone uses exactly the same version of
autoconf. On reflection, Paul is also right that src/config.in should be
generated with the same version of autoconf as configure, so removing
one but not the other is not a good idea.

> I rather hope this will not the way, because it _is_ unreasonable,
> both in practical terms and in its underlying attitude, which frankly
> is revolting.

Am I allowed to get annoyed at this point?

>> If it were me, I'd keep the same version of autoconf installed. I'd run
>> it periodically and diff the generated src/config.in against
>> msdos/config.in. If there was a difference, I'd copy the former to the
>> latter and commit it.

I also volunteer to set up a cron job that does this. (I actually had
that in there to start with, then I took it out.)

Re: A better autogen.sh

[Glenn Morris]

Glenn Morris wrote:

> I also volunteer to set up a cron job that does this.

And to make the necessary changes to the msdos build scripts.

Re: A better autogen.sh

[Paul Eggert]

On 03/16/2011 03:12 AM, Eli Zaretskii wrote:
>> Whenever maintainers feel it necessary, they could autogenerate a
>> >  new version, copy it into the msdos/ subdirectory by hand, and
>> >  commit the result.  That should be enough to address concerns
>> >  about the MS-DOS port.
> It will be enough if someone takes upon themselves to perform this
> duty as a matter of routine.  Are you volunteering for the job?

If nobody else does it, I can do it; but it sounds like Joakim
and Glenn volunteered first.  Whoever does it, that should be enough
to address this problem.

> I could understand an argument that supporting Unix-like platforms is
> easier.  (And even the "easier" argument is IMO minor, looking at all
> the stuff in lib/ that is needed to support those Unix-like non-GNU
> platforms.)

But that's exactly the point.  We cannot avoid the need to
have porting support.  But we can separate porting concerns
from mainline development concerns.  The stuff in lib/ is separate,
and people who aren't worried about porting to non-GNU platforms
don't need to worry about lib/.  The Microsoft ports should be
more like that: they should be separated from the mainline code,
and kept in their own msdos/ and nt/ subdirectories, and ordinary
Emacs development should not have to worry about them.

Of course this is just a goal and practical compromises must be
made in some cases.  Currently, though, there are too many instances
of material in the mainstream repository areas only because of Microsoft,
these instances make it harder to do mainstream development,
and we should therefore encourage attempts to move this material
into msdos/ and nt/.

Re: A better autogen.sh

[Glenn Morris]

Stefan Monnier wrote:

> I.e. make a "boostrap-files" (or should it say "generated-files"?)
> directory.  Move configure, aclocal.m4, src/config.in (and
> lisp/ldefs-boot.el) to it, then install your change
[...]
> We should try and keep the bootstrap-files more or less up to date
> (e.g. so the MS-DOS port can use them) for now, so that people who
> insist on not installing autoconf can still bootstrap.

OK. I will work on implementing that. And another script to copy the
generated/ files into place for those who want to use them. And a script
that can be run via cron to keep them up-to-date. And changing the
msdos/ build to look for config.in there.

Can I just call it generated/ or autogen/ though? :)

Re: A better autogen.sh

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Wed, 16 Mar 2011 11:34:42 -0400
> Cc: emacs-devel@gnu.org
> 
> I.e. make a "boostrap-files" (or should it say "generated-files"?)
> directory.  Move configure, aclocal.m4, src/config.in (and
> lisp/ldefs-boot.el) to it, then install your change (tho change the
> instructions to say "run ./configure" rather than "run configure" since
> we should not encourage people to have . in their PATH).

That would be fine.  I assume that directory will be under admin/ ?

Re: A better autogen.sh

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: eggert@cs.ucla.edu,  emacs-devel@gnu.org
> Date: Wed, 16 Mar 2011 13:17:19 -0400
> 
> Eli Zaretskii wrote:
> 
> > What would you or other maintainers say if I suggested a change that
> > would require them to log in to a remote system each time they wanted
> > to build the latest trunk, generate some file there, then copy it to
> > their local machine?  How can a member of a team even suggest
> > something like that to another member?
> 
> If I try to put myself in the position of someone maintaining an MS port
> of GNU software, I honestly don't think I'd mind needing to access a GNU
> host once in a while.

I do access a GNU host from time to time.  It's being forced to do
that as a necessary prerequisite to a build that's annoying and from
time to time, depending on the QoS of my ISP, even more than that.

> That's why I suggested it, I was trying to help.

Maybe it's me, but it didn't sound like that.  Or maybe I should have
counted to ten.  Sorry.

> > I rather hope this will not the way, because it _is_ unreasonable,
> > both in practical terms and in its underlying attitude, which frankly
> > is revolting.
> 
> Am I allowed to get annoyed at this point?

Yes.  Sorry.

> I also volunteer to set up a cron job that does this.

That would be great, thanks.

Re: A better autogen.sh

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: eggert@cs.ucla.edu,  emacs-devel@gnu.org
> Date: Wed, 16 Mar 2011 13:45:58 -0400
> 
> Glenn Morris wrote:
> 
> > I also volunteer to set up a cron job that does this.
> 
> And to make the necessary changes to the msdos build scripts.

That's the easy part, but thanks anyway.

Re: A better autogen.sh

[Glenn Morris]

Eli Zaretskii wrote:

>> And to make the necessary changes to the msdos build scripts.
>
> That's the easy part, but thanks anyway.

I know. :)

Anyway, I'm glad that we seem to have found a solution for this.

Re: A better autogen.sh

[Eli Zaretskii]

> Date: Wed, 16 Mar 2011 10:52:51 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: rgm@gnu.org, emacs-devel@gnu.org
> 
> > I could understand an argument that supporting Unix-like platforms is
> > easier.  (And even the "easier" argument is IMO minor, looking at all
> > the stuff in lib/ that is needed to support those Unix-like non-GNU
> > platforms.)
> 
> But that's exactly the point.  We cannot avoid the need to
> have porting support.  But we can separate porting concerns
> from mainline development concerns.  The stuff in lib/ is separate,
> and people who aren't worried about porting to non-GNU platforms
> don't need to worry about lib/.

Not true.  Anyone who makes changes to the build process or any files
that are related to the build process _must_ worry about lib/, because
without understanding how it works and how it affects the rest of the
code it is very easy to break something, especially if some obscure
use case is involved that will not pop up until much later.  Moreover,
even code reading requires awareness of the stuff in lib/.  For
example, without knowing that there are wrappers for system headers
there, it is impossible to understand how certain parts of Emacs code
work on any given platform.

IOW, the lib/ stuff is anything but transparent.  Much less
transparent, in fact, than the Windows-specific Makefile templates.

> The Microsoft ports should be more like that: they should be
> separated from the mainline code, and kept in their own msdos/ and
> nt/ subdirectories, and ordinary Emacs development should not have
> to worry about them.

"Separated" does not mean "segregated" or "ostracized".  People who
happen to use and build the Windows port are responsible for
non-trivial contributions to Emacs development that are certainly no
less than yours, see the logs.  They don't deserve this kind of
attitude, under which it is okay to make their life miserable and
every other day break the port they use, in the name of lopsided
ideological arguments.

I cannot begin to express how disappointed I am to get this kind of
attitude from one of the most veteran members of the GNU project.

> Of course this is just a goal and practical compromises must be
> made in some cases.  Currently, though, there are too many instances
> of material in the mainstream repository areas only because of Microsoft,
> these instances make it harder to do mainstream development,
> and we should therefore encourage attempts to move this material
> into msdos/ and nt/.

"Too many" is a wild exaggeration.  I doubt that you'd be able to
point out more than 1 or 2 that are not clearly marked either by their
names or parent directory.

Anyway, this is not about moving stuff, but about removing it (or not
updating it, which is effectively the same).

Re: A better autogen.sh

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Wed, 16 Mar 2011 14:09:54 -0400
> Cc: emacs-devel@gnu.org
> 
> Stefan Monnier wrote:
> 
> > I.e. make a "boostrap-files" (or should it say "generated-files"?)
> > directory.  Move configure, aclocal.m4, src/config.in (and
> > lisp/ldefs-boot.el) to it, then install your change
> [...]
> > We should try and keep the bootstrap-files more or less up to date
> > (e.g. so the MS-DOS port can use them) for now, so that people who
> > insist on not installing autoconf can still bootstrap.
> 
> OK. I will work on implementing that.

Thanks!

> And another script to copy the generated/ files into place for those
> who want to use them.

This is not needed, at least not for the MS-DOS build.  config.bat can
access the files wherever they are, assuming that these files will be
in the release tarball.

> And changing the msdos/ build to look for config.in there.

Thanks for the offer, but I can easily do this myself.  No need for
you to waste your time.  I doubt that anyone but myself builds the
MS-DOS port from the bzr repo these days anyway.

Re: A better autogen.sh

[Eli Zaretskii]

> Date: Wed, 16 Mar 2011 20:10:50 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> > From: Stefan Monnier <monnier@iro.umontreal.ca>
> > Date: Wed, 16 Mar 2011 11:34:42 -0400
> > Cc: emacs-devel@gnu.org
> > 
> > I.e. make a "boostrap-files" (or should it say "generated-files"?)
> > directory.  Move configure, aclocal.m4, src/config.in (and
> > lisp/ldefs-boot.el) to it, then install your change (tho change the
> > instructions to say "run ./configure" rather than "run configure" since
> > we should not encourage people to have . in their PATH).
> 
> That would be fine.  I assume that directory will be under admin/ ?

Ignore me.  They cannot be in admin/ because they need to be in the
release tarball.

Re: A better autogen.sh

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: eggert@cs.ucla.edu,  emacs-devel@gnu.org
> Date: Wed, 16 Mar 2011 14:20:48 -0400
> 
> Anyway, I'm glad that we seem to have found a solution for this.

Likewise.

Re: A better autogen.sh

[Stefan Monnier]

> Can I just call it generated/ or autogen/ though? :)

Yes, I like `autogen', thank you.


        Stefan

Re: A better autogen.sh

[Paul Eggert]

On 03/16/2011 11:54 AM, Eli Zaretskii wrote:
> Anyone who makes changes to the build process or any files
> that are related to the build process _must_ worry about lib/, because
> without understanding how it works and how it affects the rest of the
> code it is very easy to break something,

Yes, there are practical reasons why mainstream developers need to
worry about lib/ on occasion, just as they need to worry about their C
compiler, their 'make' implementation, etc.  But the overall goal of
lib/ is to make the current platform behave like a GNU platform, so
that the rest of Emacs can be written as if it were running in a GNU
environment.  Obviously lib/ not a perfect GNU emulation, but it does
help simplify the rest of Emacs.

> without knowing that there are wrappers for system headers
> there, it is impossible to understand how certain parts of Emacs code
> work on any given platform.

Yes, but that's fine.  If one wants to *understand* how the porting
works, one obviously must look into lib/; and if one wants to port to
a non-POSIXy platform, it'll be helpful to understand lib/, at least
to some extent, as that can provide useful info on how to port to a
non-POSIXy platform.

But if one merely wants to develop Emacs proper, one can ignore lib/
(most of the time, anyway), and write mainstream code for the GNU
platform, and have it "just work" on other Unix-like platforms.  The
MS-DOS and MS-Windows code should be similar: as much as possible it
should be invisible to mainstream developers, and mainstream code
should "just work".

A simple guideline to encourage this separation of concerns is: if a
file is needed only because of MS-DOS, it should be under msdos/; and
similarly for MS-Windows and nt/.  This needn't be an ironclad rule,
but it's a good guideline to follow when possible, so that mainstream
developers are not distracted by the porting code.

> "Separated" does not mean "segregated" or "ostracized".  People who
> happen to use and build the Windows port are responsible for
> non-trivial contributions to Emacs development that are certainly no
> less than yours... They don't deserve this kind of attitude, under
> which it is okay to make their life miserable and every other day
> break the port they use

This appears to be reading more into my email than what's there (as
well as exaggerate a bit :-).  In no way has my email suggested the
pejorative connotations of "segregrated" or "ostricized", nor have I
suggested that it's OK to make anybody's life "miserable".  Let's
focus on the technical problems rather than personalizing the
discussion.

Re: A better autogen.sh

[Paul Eggert]

On 03/16/2011 12:40 PM, Stefan Monnier wrote:
>> Can I just call it generated/ or autogen/ though? :)
>
> Yes, I like `autogen', thank you.

In gnulib-using projects such as coreutils, the standard
name for this directory is 'build-aux'.  Of course we
can use whatever name we like, but it might be better,
for the sake of communicating with other projects, to
call it 'build-aux' here too.

Once the directory is created (under whatever name), I
plan to move several gnulib-generated files into the
directory, so as to better separate porting concerns
from mainline concerns.  This has been on my list of
things to do for a month or so, and it's a nice coincidence
that the need is coming up for another reason.

Under this proposal the following top-level files
would be moved to build-aux:

arg-nonnull.h
c++defs.h
compile
config.guess
config.sub
depcomp
install-sh
missing
mkinstalldirs
move-if-change
warn-on-use.h

thus cutting the number of top-level regular files
from 26 to 15.

Re: A better autogen.sh

[Glenn Morris]

Paul Eggert wrote:

>> Yes, I like `autogen', thank you.
>
> In gnulib-using projects such as coreutils, the standard name for this
> directory is 'build-aux'.

I'm not massively fond of "build-aux" as a name, but I don't really care. 

Should the things you propose to move there be in release tarfiles?
Because the things I would move to "autogen/" should not (because
releases get "proper" configure etc pre-built), so that might be a
reason to have two separate directories; although of course make-dist
could handle it if both kinds of thing were in the same directory.

Re: A better autogen.sh

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Thu, 17 Mar 2011 16:36:08 -0400
> Cc: emacs-devel@gnu.org
> 
> Should the things you propose to move there be in release tarfiles?
> Because the things I would move to "autogen/" should not (because
> releases get "proper" configure etc pre-built)

The config.in intended to be edited by config.bat for the MS-DOS build
should be in the release tarballs.

Re: A better autogen.sh

[Glenn Morris]

Eli Zaretskii wrote:

> The config.in intended to be edited by config.bat for the MS-DOS build
> should be in the release tarballs.

I've been meaning to say: release tarfiles will continue to contain
src/config.in, exactly as they do now. So you don't actually need to
change anything msdos-related for releases. You will only need to make a
change for building the msdos build from bzr. config.bat should use
src/config.in if it exists, otherwise build-aux/config.in (or wherever
the file ends up living).

Re: A better autogen.sh

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: eggert@cs.ucla.edu,  emacs-devel@gnu.org
> Date: Thu, 17 Mar 2011 16:44:49 -0400
> 
> I've been meaning to say: release tarfiles will continue to contain
> src/config.in, exactly as they do now. So you don't actually need to
> change anything msdos-related for releases. You will only need to make a
> change for building the msdos build from bzr. config.bat should use
> src/config.in if it exists, otherwise build-aux/config.in (or wherever
> the file ends up living).

Got it.  Thanks.

Re: A better autogen.sh

[Paul Eggert]

On 03/17/2011 01:36 PM, Glenn Morris wrote:
> Should the things you propose to move there be in release tarfiles?

Yes, they're used during builds.

> Because the things I would move to "autogen/" should not (because
> releases get "proper" configure etc pre-built), so that might be a
> reason to have two separate directories; although of course make-dist
> could handle it if both kinds of thing were in the same directory.

Sorry, I guess I misunderstood what went into autogen/.  In that
case perhaps the two directories should be kept distinct.

Re: A better autogen.sh [was Re: Still unable to build trunk]

[chad]

Trying to update emacs today after an internet-access-poor road trip, I see:

	[...]
	renamed install-sh => autogen/install-sh
	[...]
	configure: error: cannot find install-sh, install.sh, or shtool in "." "./.." "./../.."

Similar errors came up for config.sub, config.guess, and depcomp. It's possible that my recent re-update of m4/autoconf/automake has left something out of place, but If I admit to some laziness and a poor understanding of the autotools, will someone help me out and tell me if this is my fault or a problem with emacs? Manually copying those files from autogen/ back into the root allowed me to build the current bzr head successfully.

Thanks,
*Chad

 

Re: A better autogen.sh

[Glenn Morris]

chad wrote:

> Trying to update emacs today after an internet-access-poor road trip, I see:
>
> 	[...]
> 	renamed install-sh => autogen/install-sh
> 	[...]
> 	configure: error: cannot find install-sh, install.sh, or shtool in "." "./.." "./../.."
>
> Similar errors came up for config.sub, config.guess, and depcomp

Run

./autogen.sh

as suggested by INSTALL.BZR.

Re: A better autogen.sh

[Chad Brown]

On Mar 28, 2011, at 1:58 PM, Glenn Morris wrote:

> 
> Run
> 
> ./autogen.sh
> 
> as suggested by INSTALL.BZR.

Huh; I swear that I had already done that once in that tree (and I should only need to do it once, yes?)

Regardless, thanks for your help.

*Chad

Re: A better autogen.sh

[Glenn Morris]

Chad Brown wrote:

> Huh; I swear that I had already done that once in that tree (and I
> should only need to do it once, yes?)

Due to a recent change you might need to do it once again.

Re: A better autogen.sh [was Re: Still unable to build trunk]

[Eli Zaretskii]

> From: chad <chadpbrown@gmail.com>
> Date: Mon, 28 Mar 2011 13:29:37 -0700
> 
> Trying to update emacs today after an internet-access-poor road trip, I see:
> 
> 	[...]
> 	renamed install-sh => autogen/install-sh
> 	[...]
> 	configure: error: cannot find install-sh, install.sh, or shtool in "." "./.." "./../.."
> 
> Similar errors came up for config.sub, config.guess, and depcomp.

Read INSTALL.BZR, it tells what to do.

Re: A better autogen.sh

[Stefan Monnier]

>> Trying to update emacs today after an internet-access-poor road trip, I see:
>> 
>> [...]
>> renamed install-sh => autogen/install-sh
>> [...]
>> configure: error: cannot find install-sh, install.sh, or shtool in "." "./.." "./../.."
>> 
>> Similar errors came up for config.sub, config.guess, and depcomp

> Run
> ./autogen.sh
> as suggested by INSTALL.BZR.

We should have added a Makefile rule to do the above.


        Stefan

Re: A better autogen.sh

[Glenn Morris]

Stefan Monnier wrote:

> We should have added a Makefile rule to do the above.

The only instance of `automake' in the Makefiles already has the
necessary switches. I don't know what else is needed.

Re: A better autogen.sh

[Stefan Monnier]

>> We should have added a Makefile rule to do the above.
> The only instance of `automake' in the Makefiles already has the
> necessary switches. I don't know what else is needed.

We're miscommunicating: the original report showed the error to be the
lack of install-sh and doesn't mention automake.  So the missing rule is
to call autogen.sh or autoreconf or something when install-sh
is missing.


        Stefan

Re: A better autogen.sh

[Glenn Morris]

Stefan Monnier wrote:

>> configure: error: cannot find install-sh, install.sh, or shtool in "." "./.." "./../.."

> We're miscommunicating: the original report showed the error to be the
> lack of install-sh and doesn't mention automake.  So the missing rule is
> to call autogen.sh or autoreconf or something when install-sh
> is missing.

(autogen.sh calls autoreconf which calls automake to add the files)

Well, there's nothing to be done about it now. Any new make rule would
only take effect after running configure, and anyone who can run
configure does not need such a rule. Anyone would ran autogen.sh between
~ Mar 20 and 25 should simply run it again if they have this issue.

Re: A better autogen.sh

[Jim Meyering]

Glenn Morris wrote:
> Stefan Monnier wrote:
>
>>> configure: error: cannot find install-sh, install.sh, or shtool in "." "./.." "./../.."
>
>> We're miscommunicating: the original report showed the error to be the
>> lack of install-sh and doesn't mention automake.  So the missing rule is
>> to call autogen.sh or autoreconf or something when install-sh
>> is missing.
>
> (autogen.sh calls autoreconf which calls automake to add the files)
>
> Well, there's nothing to be done about it now. Any new make rule would
> only take effect after running configure, and anyone who can run
> configure does not need such a rule. Anyone would ran autogen.sh between
> ~ Mar 20 and 25 should simply run it again if they have this issue.

Hi Glenn,

Actually, you *can* do something, assuming the victim has GNU make.
Put something like the following in GNUmakefile, and then "make" works
even before ./configure is run, even if it's just to instruct the user
to run ./configure.

[The following is part of gnulib's top/GNUmakefile, which is
included automatically when you use its "gnumakefile" module. ]

# Having a separate GNUmakefile lets me `include' the dynamically
# generated rules created via cfg.mk (package-local configuration)
# as well as maint.mk (generic maintainer rules).
# This makefile is used only if you run GNU Make.
# It is necessary if you want to build targets usually of interest
# only to the maintainer.

# Copyright (C) 2001, 2003, 2006-2011 Free Software Foundation, Inc.

# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.

# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.

# You should have received a copy of the GNU General Public License
# along with this program.  If not, see <http://www.gnu.org/licenses/>.

# Systems where /bin/sh is not the default shell need this.  The $(shell)
# command below won't work with e.g. stock DOS/Windows shells.
ifeq ($(wildcard /bin/s[h]),/bin/sh)
SHELL = /bin/sh
else
# will be used only with the next shell-test line, then overwritten
# by a configured-in value
SHELL = sh
endif

# If the user runs GNU make but has not yet run ./configure,
# give them a diagnostic.
_have-Makefile := $(shell test -f Makefile && echo yes)
ifeq ($(_have-Makefile),yes)

# Allow the user to add to this in the Makefile.
ALL_RECURSIVE_TARGETS =

include Makefile

.DEFAULT_GOAL := abort-due-to-no-makefile

# The package can override .DEFAULT_GOAL to run actions like autoreconf.
-include ./cfg.mk
include ./maint.mk

ifeq ($(.DEFAULT_GOAL),abort-due-to-no-makefile)
$(MAKECMDGOALS): abort-due-to-no-makefile
endif

abort-due-to-no-makefile:
        @echo There seems to be no Makefile in this directory.   1>&2
        @echo "You must run ./configure before running \`make'." 1>&2
        @exit 1

endif

Re: A better autogen.sh

[Andreas Schwab]

Jim Meyering <jim@meyering.net> writes:

> _have-Makefile := $(shell test -f Makefile && echo yes)
> ifeq ($(_have-Makefile),yes)

ifneq ($(wildcard Makefile),)

Of course, the whole thing only works when building in the source
directory.

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: A better autogen.sh

[Jim Meyering]

Andreas Schwab wrote:
> Jim Meyering <jim@meyering.net> writes:
>
>> _have-Makefile := $(shell test -f Makefile && echo yes)
>> ifeq ($(_have-Makefile),yes)
>
> ifneq ($(wildcard Makefile),)
>
> Of course, the whole thing only works when building in the source
> directory.

Sure, but that's fine.  This is only stopgap, for those who
don't read the build instructions.  Those users are unlikely
to be doing a non-srcdir build.

Re: A better autogen.sh

[Stephen J. Turnbull]

Jim Meyering writes:

 > Sure, but that's fine.  This is only stopgap, for those who
 > don't read the build instructions.  Those users are unlikely
 > to be doing a non-srcdir build.

Good luck with that attitude!

Seriously, it may be the best you can do, but if so, be a little bit
ashamed.  The users who don't read the build instructions are on
average not so dumb as you apparently think.

Beavis-to-Butthead-ly y'rs,

Re: A better autogen.sh

[Jim Meyering]

Stephen J. Turnbull wrote:
> Jim Meyering writes:
>
>  > Sure, but that's fine.  This is only stopgap, for those who
>  > don't read the build instructions.  Those users are unlikely
>  > to be doing a non-srcdir build.
>
> Good luck with that attitude!
>
> Seriously, it may be the best you can do, but if so, be a little bit
> ashamed.  The users who don't read the build instructions are on
> average not so dumb as you apparently think.

Wow.  I'm taken aback.
Attitude?  Where do you read "attitude" that I should be ashamed of?
I certainly don't think (and didn't even imply) that instruction-skippers
are dumb.  I'm one of them, sometimes.

The point is that most experienced users will manage
to solve the problem of a missing ./configure themselves,
and hence won't need to report a "bug" or ask for help.
In any case, they are far outnumbered by the less-experienced
users, the vast majority of whom will perform a srcdir build.
Hence my "unlikely".

Nothing I should be ashamed of, afaics.

Jim

Re: A better autogen.sh

[Stephen J. Turnbull]

Jim Meyering writes:

 > In any case, they are far outnumbered by the less-experienced
 > users, the vast majority of whom will perform a srcdir build.

Yah think?

Maybe it's just me, but one of the first things I learned was that
doing an out-of-$srcdir build sometimes saves you a lot of grief if
you don't know what you're doing and don't feel like learning.  It
quickly became a habit.  If there's a reason why it's hard to make
this stuff work in that context, that's one thing, but there are
probably enough users out there who would benefit from making it work
in non-$srcdir builds to make it worth doing if possible.

Re: A better autogen.sh

[chad]

[-- Attachment #1: Type: text/plain, Size: 926 bytes --]


On Mar 29, 2011, at 5:23 AM, Jim Meyering wrote:
> 
> Sure, but that's fine.  This is only stopgap, for those who
> don't read the build instructions.  Those users are unlikely
> to be doing a non-srcdir build.

If we're still talking about my case, I read the instructions, but they were (temporarily) incorrect -- they told me that I would only have to do something once when I actually needed to do it second time.  As I understand it, this was a small window of opportunity while the new system is being put into place. Had I not been on the road at the time, I would have caught the need via email.

For a more general ``doesn't read INSTALL.bzr'' situation, can we just include a default Makefile (overwritten by the autogen machinery) that either instructs the user to read INSTALL.bzr or runs the autogen machinery? That doesn't seem like something that should require gnu make extensions, even.

*Chad


[-- Attachment #2: Type: text/html, Size: 1269 bytes --]

Re: A better autogen.sh

[Jim Meyering]

chad wrote:
> On Mar 29, 2011, at 5:23 AM, Jim Meyering wrote:
>
>     Sure, but that's fine.  This is only stopgap, for those who
>     don't read the build instructions.  Those users are unlikely
>     to be doing a non-srcdir build.
>
> If we're still talking about my case, I read the instructions, but they were

I was talking about the general case.
Long ago, coreutils had no GNUmakefile.
For at least one user who was new to "build-from-source",
I heard that it did help.

> (temporarily) incorrect -- they told me that I would only have to do something
> once when I actually needed to do it second time.  As I understand it, this was
> a small window of opportunity while the new system is being put into place. Had
> I not been on the road at the time, I would have caught the need via email.
>
> For a more general ``doesn't read INSTALL.bzr'' situation, can we just include a
> default Makefile (overwritten by the autogen machinery) that either instructs
> the user to read INSTALL.bzr or runs the autogen machinery? That doesn't seem
> like something that should require gnu make extensions, even.

Not really.  Either "Makefile" is version-controlled or it isn't.
Currently it is not.
As far as I know, bzr does not have a way to deposit a
non-version-controlled file in a just checked-out directory.

Re: A better autogen.sh

[Eli Zaretskii]

> From: Jim Meyering <jim@meyering.net>
> Date: Wed, 30 Mar 2011 08:15:53 +0200
> Cc: emacs-devel@gnu.org
> 
> As far as I know, bzr does not have a way to deposit a
> non-version-controlled file in a just checked-out directory.

What do you mean by that?  What would you do with git in this
situation?

Re: A better autogen.sh

[Jim Meyering]

Eli Zaretskii wrote:
>> From: Jim Meyering <jim@meyering.net>
>> Date: Wed, 30 Mar 2011 08:15:53 +0200
>> Cc: emacs-devel@gnu.org
>>
>> As far as I know, bzr does not have a way to deposit a
>> non-version-controlled file in a just checked-out directory.
>
> What do you mean by that?

I see no ambiguity.
Please rephrase the question to explain
precisely what you don't understand.

> What would you do with git in this situation?

git cannot do that either.
Adding non-VC'd files is not the job of a version control system.
That's why there's a separate build script.

Re: A better autogen.sh

[Eli Zaretskii]

> From: Jim Meyering <jim@meyering.net>
> Cc: chadpbrown@gmail.com,  emacs-devel@gnu.org
> Date: Wed, 30 Mar 2011 14:03:54 +0200
> 
> Eli Zaretskii wrote:
> >> From: Jim Meyering <jim@meyering.net>
> >> Date: Wed, 30 Mar 2011 08:15:53 +0200
> >> Cc: emacs-devel@gnu.org
> >>
> >> As far as I know, bzr does not have a way to deposit a
> >> non-version-controlled file in a just checked-out directory.
> >
> > What do you mean by that?
> 
> I see no ambiguity.
> Please rephrase the question to explain
> precisely what you don't understand.

Sorry.  Let me see if I understand you: did you mean that whenever the
tree is updated from upstream, a file that does not exist in the
repository should be created in the working tree?

> > What would you do with git in this situation?
> 
> git cannot do that either.

I thought you were talking about a feature that exists elsewhere.

> Adding non-VC'd files is not the job of a version control system.

I was fooled by your reference to bzr and to checkout.  Sorry for my
misunderstanding.

Re: A better autogen.sh

[Jim Meyering]

Eli Zaretskii wrote:

>> From: Jim Meyering <jim@meyering.net>
>> Cc: chadpbrown@gmail.com,  emacs-devel@gnu.org
>> Date: Wed, 30 Mar 2011 14:03:54 +0200
>>
>> Eli Zaretskii wrote:
>> >> From: Jim Meyering <jim@meyering.net>
>> >> Date: Wed, 30 Mar 2011 08:15:53 +0200
>> >> Cc: emacs-devel@gnu.org
>> >>
>> >> As far as I know, bzr does not have a way to deposit a
>> >> non-version-controlled file in a just checked-out directory.
>> >
>> > What do you mean by that?
>>
>> I see no ambiguity.
>> Please rephrase the question to explain
>> precisely what you don't understand.
>
> Sorry.  Let me see if I understand you: did you mean that whenever the
> tree is updated from upstream, a file that does not exist in the
> repository should be created in the working tree?

In context you elided I mentioned a Makefile.
The request was to provide something like GNUmakefile that would
take effect also for non-GNU-make before anything like autogen.sh
or ./configure is run.  I mentioned that we don't VC Makefile.
Hence, the requestor would have to have some way of making a
bzr clone command create a non-VC'd Makefile in the directory
it creates.  AFAIK, that's not possible.

Re: A better autogen.sh

[Eli Zaretskii]

> From: Jim Meyering <jim@meyering.net>
> Cc: chadpbrown@gmail.com,  emacs-devel@gnu.org
> Date: Wed, 30 Mar 2011 21:26:01 +0200
> 
> Hence, the requestor would have to have some way of making a
> bzr clone command create a non-VC'd Makefile in the directory
> it creates.  AFAIK, that's not possible.

If this is important, we could provide a simple bzr plugin to do that,
since bzr has hooks that are called at strategic places.  See the
section "Using Hooks" in the Bazaar documentation.

Re: A better autogen.sh

[Glenn Morris]

Eli Zaretskii wrote:

> If this is important, we could provide a simple bzr plugin to do that,
> since bzr has hooks that are called at strategic places.  See the
> section "Using Hooks" in the Bazaar documentation.

It is not important at all.

The problem that started this was a transient one that affected a window
of a few days and is now in the past. Aside from that, I don't think
there are a significant number of people that fetch emacs from bzr and
immediately try to type `make' without doing anything else, so it's not
an issue I think is worth spending time on.

Re: A better autogen.sh

[Stefan Monnier]

> The problem that started this was a transient one that affected a window
> of a few days and is now in the past. Aside from that, I don't think
> there are a significant number of people that fetch emacs from bzr and
> immediately try to type `make' without doing anything else, so it's not
> an issue I think is worth spending time on.

I agree that we don't need to provide a default Makefile that runs
configure for the user.

OTOH, I think it's good to make our Makefile robust against odd states.
E.g. try:

   rm install-sh; make
or
   rm config.status; make

this last one is funny since the rule for config.status runs
config.status (obviously the rule only expects to need to update the
file, not to build it).
Admittedly, "rm config.status" is something a user is unlikely to do,
but I bumped into it recently, not sure exactly how I got there, but
I suspect that I interrupted make while it was running that rule, so it
"undid" the operation by removing the config.status file.


        Stefan

Re: A better autogen.sh

[Glenn Morris]

Stefan Monnier wrote:

> OTOH, I think it's good to make our Makefile robust against odd states.
> E.g. try:
>
>    rm install-sh; make

Nothing has changed in this regard. If you delete a versioned
install-sh, nothing restores it for you.

Re: A better autogen.sh

[Stefan Monnier]

>> OTOH, I think it's good to make our Makefile robust against odd states.
>> E.g. try:
>> 
>> rm install-sh; make

> Nothing has changed in this regard. If you delete a versioned
> install-sh, nothing restores it for you.

But install-sh is not versioned any more.


        Stefan