* Still unable to build trunk @ 2011-01-20 18:47 Chong Yidong 2011-01-20 19:39 ` Jan Djärv 0 siblings, 1 reply; 113+ messages in thread From: Chong Yidong @ 2011-01-20 18:47 UTC (permalink / raw) To: Paul Eggert; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: Still unable to build trunk 2011-01-20 18:47 Still unable to build trunk Chong Yidong @ 2011-01-20 19:39 ` Jan Djärv 2011-01-20 22:16 ` Chong Yidong 0 siblings, 1 reply; 113+ messages in thread From: Jan Djärv @ 2011-01-20 19:39 UTC (permalink / raw) To: Chong Yidong; +Cc: Paul Eggert, emacs-devel 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: Still unable to build trunk 2011-01-20 19:39 ` Jan Djärv @ 2011-01-20 22:16 ` Chong Yidong 2011-01-21 20:42 ` Paul Eggert 0 siblings, 1 reply; 113+ messages in thread From: Chong Yidong @ 2011-01-20 22:16 UTC (permalink / raw) To: Jan Djärv; +Cc: Paul Eggert, emacs-devel 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: Still unable to build trunk 2011-01-20 22:16 ` Chong Yidong @ 2011-01-21 20:42 ` Paul Eggert 2011-01-22 1:29 ` Chong Yidong 0 siblings, 1 reply; 113+ messages in thread From: Paul Eggert @ 2011-01-21 20:42 UTC (permalink / raw) To: Chong Yidong; +Cc: Jan Djärv, emacs-devel 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: Still unable to build trunk 2011-01-21 20:42 ` Paul Eggert @ 2011-01-22 1:29 ` Chong Yidong 2011-01-22 7:25 ` Paul Eggert 0 siblings, 1 reply; 113+ messages in thread From: Chong Yidong @ 2011-01-22 1:29 UTC (permalink / raw) To: Paul Eggert; +Cc: Jan Djärv, emacs-devel 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: Still unable to build trunk 2011-01-22 1:29 ` Chong Yidong @ 2011-01-22 7:25 ` Paul Eggert 2011-01-22 15:03 ` Eli Zaretskii 0 siblings, 1 reply; 113+ messages in thread From: Paul Eggert @ 2011-01-22 7:25 UTC (permalink / raw) To: Chong Yidong; +Cc: Jan Djärv, emacs-devel 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...] ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: Still unable to build trunk 2011-01-22 7:25 ` Paul Eggert @ 2011-01-22 15:03 ` Eli Zaretskii 2011-01-23 15:33 ` Jim Meyering 0 siblings, 1 reply; 113+ messages in thread From: Eli Zaretskii @ 2011-01-22 15:03 UTC (permalink / raw) To: Paul Eggert; +Cc: cyd, jan.h.d, emacs-devel > 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: Still unable to build trunk 2011-01-22 15:03 ` Eli Zaretskii @ 2011-01-23 15:33 ` Jim Meyering 2011-01-23 17:00 ` Eli Zaretskii 0 siblings, 1 reply; 113+ messages in thread From: Jim Meyering @ 2011-01-23 15:33 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cyd, Paul Eggert, jan.h.d, emacs-devel 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: Still unable to build trunk 2011-01-23 15:33 ` Jim Meyering @ 2011-01-23 17:00 ` Eli Zaretskii 2011-01-23 17:35 ` Jim Meyering 2011-01-23 21:23 ` Paul Eggert 0 siblings, 2 replies; 113+ messages in thread From: Eli Zaretskii @ 2011-01-23 17:00 UTC (permalink / raw) To: Jim Meyering; +Cc: cyd, eggert, jan.h.d, emacs-devel > 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: Still unable to build trunk 2011-01-23 17:00 ` Eli Zaretskii @ 2011-01-23 17:35 ` Jim Meyering 2011-01-23 18:14 ` Eli Zaretskii 2011-01-23 21:23 ` Paul Eggert 1 sibling, 1 reply; 113+ messages in thread From: Jim Meyering @ 2011-01-23 17:35 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cyd, eggert, jan.h.d, emacs-devel 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 ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: Still unable to build trunk 2011-01-23 17:35 ` Jim Meyering @ 2011-01-23 18:14 ` Eli Zaretskii 2011-01-23 18:47 ` Jim Meyering 0 siblings, 1 reply; 113+ messages in thread From: Eli Zaretskii @ 2011-01-23 18:14 UTC (permalink / raw) To: Jim Meyering; +Cc: cyd, eggert, jan.h.d, emacs-devel > 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: Still unable to build trunk 2011-01-23 18:14 ` Eli Zaretskii @ 2011-01-23 18:47 ` Jim Meyering 2011-01-23 19:06 ` Eli Zaretskii 0 siblings, 1 reply; 113+ messages in thread From: Jim Meyering @ 2011-01-23 18:47 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cyd, eggert, jan.h.d, emacs-devel 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: Still unable to build trunk 2011-01-23 18:47 ` Jim Meyering @ 2011-01-23 19:06 ` Eli Zaretskii 2011-01-23 20:08 ` Jim Meyering 0 siblings, 1 reply; 113+ messages in thread From: Eli Zaretskii @ 2011-01-23 19:06 UTC (permalink / raw) To: Jim Meyering; +Cc: cyd, eggert, jan.h.d, emacs-devel > 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: Still unable to build trunk 2011-01-23 19:06 ` Eli Zaretskii @ 2011-01-23 20:08 ` Jim Meyering 0 siblings, 0 replies; 113+ messages in thread From: Jim Meyering @ 2011-01-23 20:08 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cyd, eggert, jan.h.d, emacs-devel 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 ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: Still unable to build trunk 2011-01-23 17:00 ` Eli Zaretskii 2011-01-23 17:35 ` Jim Meyering @ 2011-01-23 21:23 ` Paul Eggert 2011-01-24 1:01 ` Stefan Monnier 2011-01-24 18:14 ` Still unable to build trunk Eli Zaretskii 1 sibling, 2 replies; 113+ messages in thread From: Paul Eggert @ 2011-01-23 21:23 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cyd, jan.h.d, bug-gnulib, Jim Meyering, emacs-devel 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: Still unable to build trunk 2011-01-23 21:23 ` Paul Eggert @ 2011-01-24 1:01 ` Stefan Monnier 2011-01-24 1:22 ` Miles Bader 2011-01-24 8:48 ` Glenn Morris 2011-01-24 18:14 ` Still unable to build trunk Eli Zaretskii 1 sibling, 2 replies; 113+ messages in thread From: Stefan Monnier @ 2011-01-24 1:01 UTC (permalink / raw) To: Paul Eggert Cc: bug-gnulib, cyd, Jim Meyering, emacs-devel, Eli Zaretskii, jan.h.d >> 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 ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: Still unable to build trunk 2011-01-24 1:01 ` Stefan Monnier @ 2011-01-24 1:22 ` Miles Bader 2011-01-24 8:48 ` Glenn Morris 1 sibling, 0 replies; 113+ messages in thread From: Miles Bader @ 2011-01-24 1:22 UTC (permalink / raw) To: Stefan Monnier Cc: Paul Eggert, bug-gnulib, cyd, Jim Meyering, emacs-devel, Eli Zaretskii, jan.h.d 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: Still unable to build trunk 2011-01-24 1:01 ` Stefan Monnier 2011-01-24 1:22 ` Miles Bader @ 2011-01-24 8:48 ` Glenn Morris 2011-01-24 16:26 ` Stefan Monnier 1 sibling, 1 reply; 113+ messages in thread From: Glenn Morris @ 2011-01-24 8:48 UTC (permalink / raw) To: Stefan Monnier Cc: Paul Eggert, cyd, Jim Meyering, emacs-devel, Eli Zaretskii, jan.h.d [ 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.) ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: Still unable to build trunk 2011-01-24 8:48 ` Glenn Morris @ 2011-01-24 16:26 ` Stefan Monnier 2011-03-08 4:22 ` A better autogen.sh [was Re: Still unable to build trunk] Glenn Morris 0 siblings, 1 reply; 113+ messages in thread From: Stefan Monnier @ 2011-01-24 16:26 UTC (permalink / raw) To: Glenn Morris Cc: Paul Eggert, cyd, Jim Meyering, emacs-devel, Eli Zaretskii, jan.h.d >> 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 ^ permalink raw reply [flat|nested] 113+ messages in thread
* A better autogen.sh [was Re: Still unable to build trunk] 2011-01-24 16:26 ` Stefan Monnier @ 2011-03-08 4:22 ` Glenn Morris 2011-03-08 19:51 ` Stefan Monnier 2011-03-28 20:29 ` A better autogen.sh [was Re: Still unable to build trunk] chad 0 siblings, 2 replies; 113+ messages in thread From: Glenn Morris @ 2011-03-08 4:22 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh [was Re: Still unable to build trunk] 2011-03-08 4:22 ` A better autogen.sh [was Re: Still unable to build trunk] Glenn Morris @ 2011-03-08 19:51 ` Stefan Monnier 2011-03-10 16:10 ` Thien-Thi Nguyen 2011-03-15 20:22 ` A better autogen.sh Glenn Morris 2011-03-28 20:29 ` A better autogen.sh [was Re: Still unable to build trunk] chad 1 sibling, 2 replies; 113+ messages in thread From: Stefan Monnier @ 2011-03-08 19:51 UTC (permalink / raw) To: Glenn Morris; +Cc: emacs-devel >> 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 ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh [was Re: Still unable to build trunk] 2011-03-08 19:51 ` Stefan Monnier @ 2011-03-10 16:10 ` Thien-Thi Nguyen 2011-03-15 20:22 ` A better autogen.sh Glenn Morris 1 sibling, 0 replies; 113+ messages in thread From: Thien-Thi Nguyen @ 2011-03-10 16:10 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel () 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! ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-08 19:51 ` Stefan Monnier 2011-03-10 16:10 ` Thien-Thi Nguyen @ 2011-03-15 20:22 ` Glenn Morris 2011-03-15 21:52 ` Paul Eggert 2011-03-16 15:34 ` Stefan Monnier 1 sibling, 2 replies; 113+ messages in thread From: Glenn Morris @ 2011-03-15 20:22 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel Stefan Monnier wrote: > What do people think of it? Not many responses. Should I go ahead with installing this and removing configure? ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-15 20:22 ` A better autogen.sh Glenn Morris @ 2011-03-15 21:52 ` Paul Eggert 2011-03-15 22:09 ` Glenn Morris 2011-03-16 15:34 ` Stefan Monnier 1 sibling, 1 reply; 113+ messages in thread From: Paul Eggert @ 2011-03-15 21:52 UTC (permalink / raw) To: Glenn Morris; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-15 21:52 ` Paul Eggert @ 2011-03-15 22:09 ` Glenn Morris 2011-03-15 22:37 ` Glenn Morris 2011-03-15 22:58 ` Paul Eggert 0 siblings, 2 replies; 113+ messages in thread From: Glenn Morris @ 2011-03-15 22:09 UTC (permalink / raw) To: Paul Eggert; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-15 22:09 ` Glenn Morris @ 2011-03-15 22:37 ` Glenn Morris 2011-03-15 22:58 ` Paul Eggert 1 sibling, 0 replies; 113+ messages in thread From: Glenn Morris @ 2011-03-15 22:37 UTC (permalink / raw) To: Paul Eggert, Emacs developers 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-15 22:09 ` Glenn Morris 2011-03-15 22:37 ` Glenn Morris @ 2011-03-15 22:58 ` Paul Eggert 2011-03-16 4:05 ` Eli Zaretskii 1 sibling, 1 reply; 113+ messages in thread From: Paul Eggert @ 2011-03-15 22:58 UTC (permalink / raw) To: Glenn Morris; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-15 22:58 ` Paul Eggert @ 2011-03-16 4:05 ` Eli Zaretskii 2011-03-16 4:14 ` Glenn Morris 0 siblings, 1 reply; 113+ messages in thread From: Eli Zaretskii @ 2011-03-16 4:05 UTC (permalink / raw) To: Paul Eggert; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-16 4:05 ` Eli Zaretskii @ 2011-03-16 4:14 ` Glenn Morris 2011-03-16 4:17 ` Glenn Morris 2011-03-16 5:53 ` Eli Zaretskii 0 siblings, 2 replies; 113+ messages in thread From: Glenn Morris @ 2011-03-16 4:14 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Paul Eggert, emacs-devel 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-16 4:14 ` Glenn Morris @ 2011-03-16 4:17 ` Glenn Morris 2011-03-16 5:53 ` Eli Zaretskii 1 sibling, 0 replies; 113+ messages in thread From: Glenn Morris @ 2011-03-16 4:17 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Paul Eggert, emacs-devel Glenn Morris wrote: > That's a big ugly, I hope the previous solution is acceptable to you. s/big/bit ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-16 4:14 ` Glenn Morris 2011-03-16 4:17 ` Glenn Morris @ 2011-03-16 5:53 ` Eli Zaretskii 2011-03-16 6:39 ` Paul Eggert 2011-03-16 6:43 ` Glenn Morris 1 sibling, 2 replies; 113+ messages in thread From: Eli Zaretskii @ 2011-03-16 5:53 UTC (permalink / raw) To: Glenn Morris; +Cc: eggert, emacs-devel > 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-16 5:53 ` Eli Zaretskii @ 2011-03-16 6:39 ` Paul Eggert 2011-03-16 8:10 ` Eli Zaretskii 2011-03-16 6:43 ` Glenn Morris 1 sibling, 1 reply; 113+ messages in thread From: Paul Eggert @ 2011-03-16 6:39 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-16 6:39 ` Paul Eggert @ 2011-03-16 8:10 ` Eli Zaretskii 2011-03-16 9:08 ` Paul Eggert 2011-03-16 11:21 ` Juanma Barranquero 0 siblings, 2 replies; 113+ messages in thread From: Eli Zaretskii @ 2011-03-16 8:10 UTC (permalink / raw) To: Paul Eggert; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-16 8:10 ` Eli Zaretskii @ 2011-03-16 9:08 ` Paul Eggert 2011-03-16 10:12 ` Eli Zaretskii 2011-03-16 11:33 ` Juanma Barranquero 2011-03-16 11:21 ` Juanma Barranquero 1 sibling, 2 replies; 113+ messages in thread From: Paul Eggert @ 2011-03-16 9:08 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-16 9:08 ` Paul Eggert @ 2011-03-16 10:12 ` Eli Zaretskii 2011-03-16 10:47 ` joakim 2011-03-16 17:52 ` Paul Eggert 2011-03-16 11:33 ` Juanma Barranquero 1 sibling, 2 replies; 113+ messages in thread From: Eli Zaretskii @ 2011-03-16 10:12 UTC (permalink / raw) To: Paul Eggert; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-16 10:12 ` Eli Zaretskii @ 2011-03-16 10:47 ` joakim 2011-03-16 11:53 ` Eli Zaretskii 2011-03-16 17:52 ` Paul Eggert 1 sibling, 1 reply; 113+ messages in thread From: joakim @ 2011-03-16 10:47 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Paul Eggert, emacs-devel 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 ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-16 10:47 ` joakim @ 2011-03-16 11:53 ` Eli Zaretskii 2011-03-16 12:25 ` joakim 0 siblings, 1 reply; 113+ messages in thread From: Eli Zaretskii @ 2011-03-16 11:53 UTC (permalink / raw) To: joakim; +Cc: eggert, emacs-devel > 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-16 11:53 ` Eli Zaretskii @ 2011-03-16 12:25 ` joakim 2011-03-16 12:42 ` Eli Zaretskii 0 siblings, 1 reply; 113+ messages in thread From: joakim @ 2011-03-16 12:25 UTC (permalink / raw) To: Eli Zaretskii; +Cc: eggert, emacs-devel 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 ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-16 12:25 ` joakim @ 2011-03-16 12:42 ` Eli Zaretskii 0 siblings, 0 replies; 113+ messages in thread From: Eli Zaretskii @ 2011-03-16 12:42 UTC (permalink / raw) To: joakim; +Cc: eggert, emacs-devel > 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-16 10:12 ` Eli Zaretskii 2011-03-16 10:47 ` joakim @ 2011-03-16 17:52 ` Paul Eggert 2011-03-16 18:54 ` Eli Zaretskii 1 sibling, 1 reply; 113+ messages in thread From: Paul Eggert @ 2011-03-16 17:52 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel 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/. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-16 17:52 ` Paul Eggert @ 2011-03-16 18:54 ` Eli Zaretskii 2011-03-16 20:40 ` Paul Eggert 0 siblings, 1 reply; 113+ messages in thread From: Eli Zaretskii @ 2011-03-16 18:54 UTC (permalink / raw) To: Paul Eggert; +Cc: emacs-devel > 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). ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-16 18:54 ` Eli Zaretskii @ 2011-03-16 20:40 ` Paul Eggert 0 siblings, 0 replies; 113+ messages in thread From: Paul Eggert @ 2011-03-16 20:40 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-16 9:08 ` Paul Eggert 2011-03-16 10:12 ` Eli Zaretskii @ 2011-03-16 11:33 ` Juanma Barranquero 1 sibling, 0 replies; 113+ messages in thread From: Juanma Barranquero @ 2011-03-16 11:33 UTC (permalink / raw) To: Paul Eggert; +Cc: Eli Zaretskii, emacs-devel 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 ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-16 8:10 ` Eli Zaretskii 2011-03-16 9:08 ` Paul Eggert @ 2011-03-16 11:21 ` Juanma Barranquero 1 sibling, 0 replies; 113+ messages in thread From: Juanma Barranquero @ 2011-03-16 11:21 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Paul Eggert, emacs-devel 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 ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-16 5:53 ` Eli Zaretskii 2011-03-16 6:39 ` Paul Eggert @ 2011-03-16 6:43 ` Glenn Morris 2011-03-16 8:47 ` Eli Zaretskii 1 sibling, 1 reply; 113+ messages in thread From: Glenn Morris @ 2011-03-16 6:43 UTC (permalink / raw) To: Eli Zaretskii; +Cc: eggert, emacs-devel 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-16 6:43 ` Glenn Morris @ 2011-03-16 8:47 ` Eli Zaretskii 2011-03-16 9:23 ` Paul Eggert 2011-03-16 17:17 ` Glenn Morris 0 siblings, 2 replies; 113+ messages in thread From: Eli Zaretskii @ 2011-03-16 8:47 UTC (permalink / raw) To: Glenn Morris; +Cc: eggert, emacs-devel > 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-16 8:47 ` Eli Zaretskii @ 2011-03-16 9:23 ` Paul Eggert 2011-03-16 10:37 ` Eli Zaretskii 2011-03-16 17:17 ` Glenn Morris 1 sibling, 1 reply; 113+ messages in thread From: Paul Eggert @ 2011-03-16 9:23 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-16 9:23 ` Paul Eggert @ 2011-03-16 10:37 ` Eli Zaretskii 0 siblings, 0 replies; 113+ messages in thread From: Eli Zaretskii @ 2011-03-16 10:37 UTC (permalink / raw) To: Paul Eggert; +Cc: emacs-devel > 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). ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-16 8:47 ` Eli Zaretskii 2011-03-16 9:23 ` Paul Eggert @ 2011-03-16 17:17 ` Glenn Morris 2011-03-16 17:45 ` Glenn Morris 2011-03-16 18:15 ` Eli Zaretskii 1 sibling, 2 replies; 113+ messages in thread From: Glenn Morris @ 2011-03-16 17:17 UTC (permalink / raw) To: Eli Zaretskii; +Cc: eggert, emacs-devel 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.) ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-16 17:17 ` Glenn Morris @ 2011-03-16 17:45 ` Glenn Morris 2011-03-16 18:16 ` Eli Zaretskii 2011-03-16 18:15 ` Eli Zaretskii 1 sibling, 1 reply; 113+ messages in thread From: Glenn Morris @ 2011-03-16 17:45 UTC (permalink / raw) To: Eli Zaretskii; +Cc: eggert, emacs-devel 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-16 17:45 ` Glenn Morris @ 2011-03-16 18:16 ` Eli Zaretskii 2011-03-16 18:20 ` Glenn Morris 0 siblings, 1 reply; 113+ messages in thread From: Eli Zaretskii @ 2011-03-16 18:16 UTC (permalink / raw) To: Glenn Morris; +Cc: eggert, emacs-devel > 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-16 18:16 ` Eli Zaretskii @ 2011-03-16 18:20 ` Glenn Morris 2011-03-16 19:13 ` Eli Zaretskii 0 siblings, 1 reply; 113+ messages in thread From: Glenn Morris @ 2011-03-16 18:20 UTC (permalink / raw) To: Eli Zaretskii; +Cc: eggert, emacs-devel 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-16 18:20 ` Glenn Morris @ 2011-03-16 19:13 ` Eli Zaretskii 0 siblings, 0 replies; 113+ messages in thread From: Eli Zaretskii @ 2011-03-16 19:13 UTC (permalink / raw) To: Glenn Morris; +Cc: eggert, emacs-devel > 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-16 17:17 ` Glenn Morris 2011-03-16 17:45 ` Glenn Morris @ 2011-03-16 18:15 ` Eli Zaretskii 1 sibling, 0 replies; 113+ messages in thread From: Eli Zaretskii @ 2011-03-16 18:15 UTC (permalink / raw) To: Glenn Morris; +Cc: eggert, emacs-devel > 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-15 20:22 ` A better autogen.sh Glenn Morris 2011-03-15 21:52 ` Paul Eggert @ 2011-03-16 15:34 ` Stefan Monnier 2011-03-16 18:09 ` Glenn Morris 2011-03-16 18:10 ` Eli Zaretskii 1 sibling, 2 replies; 113+ messages in thread From: Stefan Monnier @ 2011-03-16 15:34 UTC (permalink / raw) To: Glenn Morris; +Cc: emacs-devel >> 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 ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-16 15:34 ` Stefan Monnier @ 2011-03-16 18:09 ` Glenn Morris 2011-03-16 19:12 ` Eli Zaretskii 2011-03-16 19:40 ` Stefan Monnier 2011-03-16 18:10 ` Eli Zaretskii 1 sibling, 2 replies; 113+ messages in thread From: Glenn Morris @ 2011-03-16 18:09 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel 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? :) ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-16 18:09 ` Glenn Morris @ 2011-03-16 19:12 ` Eli Zaretskii 2011-03-16 19:40 ` Stefan Monnier 1 sibling, 0 replies; 113+ messages in thread From: Eli Zaretskii @ 2011-03-16 19:12 UTC (permalink / raw) To: Glenn Morris; +Cc: monnier, emacs-devel > 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-16 18:09 ` Glenn Morris 2011-03-16 19:12 ` Eli Zaretskii @ 2011-03-16 19:40 ` Stefan Monnier 2011-03-16 20:56 ` Paul Eggert 1 sibling, 1 reply; 113+ messages in thread From: Stefan Monnier @ 2011-03-16 19:40 UTC (permalink / raw) To: Glenn Morris; +Cc: emacs-devel > Can I just call it generated/ or autogen/ though? :) Yes, I like `autogen', thank you. Stefan ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-16 19:40 ` Stefan Monnier @ 2011-03-16 20:56 ` Paul Eggert 2011-03-17 20:36 ` Glenn Morris 0 siblings, 1 reply; 113+ messages in thread From: Paul Eggert @ 2011-03-16 20:56 UTC (permalink / raw) To: emacs-devel 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-16 20:56 ` Paul Eggert @ 2011-03-17 20:36 ` Glenn Morris 2011-03-17 20:40 ` Eli Zaretskii 2011-03-18 2:02 ` Paul Eggert 0 siblings, 2 replies; 113+ messages in thread From: Glenn Morris @ 2011-03-17 20:36 UTC (permalink / raw) To: Paul Eggert; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-17 20:36 ` Glenn Morris @ 2011-03-17 20:40 ` Eli Zaretskii 2011-03-17 20:44 ` Glenn Morris 2011-03-18 2:02 ` Paul Eggert 1 sibling, 1 reply; 113+ messages in thread From: Eli Zaretskii @ 2011-03-17 20:40 UTC (permalink / raw) To: Glenn Morris; +Cc: eggert, emacs-devel > 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-17 20:40 ` Eli Zaretskii @ 2011-03-17 20:44 ` Glenn Morris 2011-03-17 20:51 ` Eli Zaretskii 0 siblings, 1 reply; 113+ messages in thread From: Glenn Morris @ 2011-03-17 20:44 UTC (permalink / raw) To: Eli Zaretskii; +Cc: eggert, emacs-devel 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). ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-17 20:44 ` Glenn Morris @ 2011-03-17 20:51 ` Eli Zaretskii 0 siblings, 0 replies; 113+ messages in thread From: Eli Zaretskii @ 2011-03-17 20:51 UTC (permalink / raw) To: Glenn Morris; +Cc: eggert, emacs-devel > 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-17 20:36 ` Glenn Morris 2011-03-17 20:40 ` Eli Zaretskii @ 2011-03-18 2:02 ` Paul Eggert 1 sibling, 0 replies; 113+ messages in thread From: Paul Eggert @ 2011-03-18 2:02 UTC (permalink / raw) To: Glenn Morris; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-16 15:34 ` Stefan Monnier 2011-03-16 18:09 ` Glenn Morris @ 2011-03-16 18:10 ` Eli Zaretskii 2011-03-16 19:13 ` Eli Zaretskii 1 sibling, 1 reply; 113+ messages in thread From: Eli Zaretskii @ 2011-03-16 18:10 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel > 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/ ? ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-16 18:10 ` Eli Zaretskii @ 2011-03-16 19:13 ` Eli Zaretskii 0 siblings, 0 replies; 113+ messages in thread From: Eli Zaretskii @ 2011-03-16 19:13 UTC (permalink / raw) To: monnier, emacs-devel > 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh [was Re: Still unable to build trunk] 2011-03-08 4:22 ` A better autogen.sh [was Re: Still unable to build trunk] Glenn Morris 2011-03-08 19:51 ` Stefan Monnier @ 2011-03-28 20:29 ` chad 2011-03-28 20:58 ` A better autogen.sh Glenn Morris 2011-03-28 21:57 ` A better autogen.sh [was Re: Still unable to build trunk] Eli Zaretskii 1 sibling, 2 replies; 113+ messages in thread From: chad @ 2011-03-28 20:29 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-28 20:29 ` A better autogen.sh [was Re: Still unable to build trunk] chad @ 2011-03-28 20:58 ` Glenn Morris 2011-03-28 21:45 ` Chad Brown 2011-03-29 1:17 ` Stefan Monnier 2011-03-28 21:57 ` A better autogen.sh [was Re: Still unable to build trunk] Eli Zaretskii 1 sibling, 2 replies; 113+ messages in thread From: Glenn Morris @ 2011-03-28 20:58 UTC (permalink / raw) To: chad; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-28 20:58 ` A better autogen.sh Glenn Morris @ 2011-03-28 21:45 ` Chad Brown 2011-03-28 21:51 ` Glenn Morris 2011-03-29 1:17 ` Stefan Monnier 1 sibling, 1 reply; 113+ messages in thread From: Chad Brown @ 2011-03-28 21:45 UTC (permalink / raw) To: Glenn Morris; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-28 21:45 ` Chad Brown @ 2011-03-28 21:51 ` Glenn Morris 0 siblings, 0 replies; 113+ messages in thread From: Glenn Morris @ 2011-03-28 21:51 UTC (permalink / raw) To: Chad Brown; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-28 20:58 ` A better autogen.sh Glenn Morris 2011-03-28 21:45 ` Chad Brown @ 2011-03-29 1:17 ` Stefan Monnier 2011-03-29 2:21 ` Glenn Morris 1 sibling, 1 reply; 113+ messages in thread From: Stefan Monnier @ 2011-03-29 1:17 UTC (permalink / raw) To: Glenn Morris; +Cc: chad, emacs-devel >> 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 ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-29 1:17 ` Stefan Monnier @ 2011-03-29 2:21 ` Glenn Morris 2011-03-29 3:36 ` Stefan Monnier 0 siblings, 1 reply; 113+ messages in thread From: Glenn Morris @ 2011-03-29 2:21 UTC (permalink / raw) To: Stefan Monnier; +Cc: chad, emacs-devel 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-29 2:21 ` Glenn Morris @ 2011-03-29 3:36 ` Stefan Monnier 2011-03-29 6:39 ` Glenn Morris 0 siblings, 1 reply; 113+ messages in thread From: Stefan Monnier @ 2011-03-29 3:36 UTC (permalink / raw) To: Glenn Morris; +Cc: chad, emacs-devel >> 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 ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-29 3:36 ` Stefan Monnier @ 2011-03-29 6:39 ` Glenn Morris 2011-03-29 12:09 ` Jim Meyering 0 siblings, 1 reply; 113+ messages in thread From: Glenn Morris @ 2011-03-29 6:39 UTC (permalink / raw) To: Stefan Monnier; +Cc: chad, emacs-devel 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-29 6:39 ` Glenn Morris @ 2011-03-29 12:09 ` Jim Meyering 2011-03-29 12:19 ` Andreas Schwab 0 siblings, 1 reply; 113+ messages in thread From: Jim Meyering @ 2011-03-29 12:09 UTC (permalink / raw) To: Glenn Morris; +Cc: emacs-devel, Stefan Monnier, chad 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 ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-29 12:09 ` Jim Meyering @ 2011-03-29 12:19 ` Andreas Schwab 2011-03-29 12:23 ` Jim Meyering 0 siblings, 1 reply; 113+ messages in thread From: Andreas Schwab @ 2011-03-29 12:19 UTC (permalink / raw) To: Jim Meyering; +Cc: chad, Stefan Monnier, emacs-devel 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." ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-29 12:19 ` Andreas Schwab @ 2011-03-29 12:23 ` Jim Meyering 2011-03-29 14:13 ` Stephen J. Turnbull 2011-03-29 18:46 ` chad 0 siblings, 2 replies; 113+ messages in thread From: Jim Meyering @ 2011-03-29 12:23 UTC (permalink / raw) To: Andreas Schwab; +Cc: chad, Stefan Monnier, emacs-devel 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-29 12:23 ` Jim Meyering @ 2011-03-29 14:13 ` Stephen J. Turnbull 2011-03-29 15:25 ` Jim Meyering 2011-03-29 18:46 ` chad 1 sibling, 1 reply; 113+ messages in thread From: Stephen J. Turnbull @ 2011-03-29 14:13 UTC (permalink / raw) To: Jim Meyering; +Cc: emacs-devel, Andreas Schwab, chad, Stefan Monnier 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, ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-29 14:13 ` Stephen J. Turnbull @ 2011-03-29 15:25 ` Jim Meyering 2011-03-29 16:38 ` Stephen J. Turnbull 0 siblings, 1 reply; 113+ messages in thread From: Jim Meyering @ 2011-03-29 15:25 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: Andreas Schwab, chad, Stefan Monnier, emacs-devel 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 ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-29 15:25 ` Jim Meyering @ 2011-03-29 16:38 ` Stephen J. Turnbull 0 siblings, 0 replies; 113+ messages in thread From: Stephen J. Turnbull @ 2011-03-29 16:38 UTC (permalink / raw) To: Jim Meyering; +Cc: emacs-devel, Andreas Schwab, chad, Stefan Monnier 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-29 12:23 ` Jim Meyering 2011-03-29 14:13 ` Stephen J. Turnbull @ 2011-03-29 18:46 ` chad 2011-03-30 6:15 ` Jim Meyering 1 sibling, 1 reply; 113+ messages in thread From: chad @ 2011-03-29 18:46 UTC (permalink / raw) To: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-29 18:46 ` chad @ 2011-03-30 6:15 ` Jim Meyering 2011-03-30 11:27 ` Eli Zaretskii 0 siblings, 1 reply; 113+ messages in thread From: Jim Meyering @ 2011-03-30 6:15 UTC (permalink / raw) To: chad; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-30 6:15 ` Jim Meyering @ 2011-03-30 11:27 ` Eli Zaretskii 2011-03-30 12:03 ` Jim Meyering 0 siblings, 1 reply; 113+ messages in thread From: Eli Zaretskii @ 2011-03-30 11:27 UTC (permalink / raw) To: Jim Meyering; +Cc: chadpbrown, emacs-devel > 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? ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-30 11:27 ` Eli Zaretskii @ 2011-03-30 12:03 ` Jim Meyering 2011-03-30 17:48 ` Eli Zaretskii 0 siblings, 1 reply; 113+ messages in thread From: Jim Meyering @ 2011-03-30 12:03 UTC (permalink / raw) To: Eli Zaretskii; +Cc: chadpbrown, emacs-devel 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-30 12:03 ` Jim Meyering @ 2011-03-30 17:48 ` Eli Zaretskii 2011-03-30 19:26 ` Jim Meyering 0 siblings, 1 reply; 113+ messages in thread From: Eli Zaretskii @ 2011-03-30 17:48 UTC (permalink / raw) To: Jim Meyering; +Cc: chadpbrown, emacs-devel > 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-30 17:48 ` Eli Zaretskii @ 2011-03-30 19:26 ` Jim Meyering 2011-03-30 20:02 ` Eli Zaretskii 0 siblings, 1 reply; 113+ messages in thread From: Jim Meyering @ 2011-03-30 19:26 UTC (permalink / raw) To: Eli Zaretskii; +Cc: chadpbrown, emacs-devel 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-30 19:26 ` Jim Meyering @ 2011-03-30 20:02 ` Eli Zaretskii 2011-03-30 20:14 ` Glenn Morris 0 siblings, 1 reply; 113+ messages in thread From: Eli Zaretskii @ 2011-03-30 20:02 UTC (permalink / raw) To: Jim Meyering; +Cc: chadpbrown, emacs-devel > 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-30 20:02 ` Eli Zaretskii @ 2011-03-30 20:14 ` Glenn Morris 2011-03-30 21:36 ` Stefan Monnier 0 siblings, 1 reply; 113+ messages in thread From: Glenn Morris @ 2011-03-30 20:14 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel, Jim Meyering, chadpbrown 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-30 20:14 ` Glenn Morris @ 2011-03-30 21:36 ` Stefan Monnier 2011-03-30 21:41 ` Glenn Morris 0 siblings, 1 reply; 113+ messages in thread From: Stefan Monnier @ 2011-03-30 21:36 UTC (permalink / raw) To: Glenn Morris; +Cc: chadpbrown, Eli Zaretskii, Jim Meyering, emacs-devel > 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 ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-30 21:36 ` Stefan Monnier @ 2011-03-30 21:41 ` Glenn Morris 2011-03-31 14:36 ` Stefan Monnier 0 siblings, 1 reply; 113+ messages in thread From: Glenn Morris @ 2011-03-30 21:41 UTC (permalink / raw) To: Stefan Monnier; +Cc: chadpbrown, Eli Zaretskii, Jim Meyering, emacs-devel 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh 2011-03-30 21:41 ` Glenn Morris @ 2011-03-31 14:36 ` Stefan Monnier 0 siblings, 0 replies; 113+ messages in thread From: Stefan Monnier @ 2011-03-31 14:36 UTC (permalink / raw) To: Glenn Morris; +Cc: chadpbrown, Eli Zaretskii, Jim Meyering, emacs-devel >> 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 ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: A better autogen.sh [was Re: Still unable to build trunk] 2011-03-28 20:29 ` A better autogen.sh [was Re: Still unable to build trunk] chad 2011-03-28 20:58 ` A better autogen.sh Glenn Morris @ 2011-03-28 21:57 ` Eli Zaretskii 1 sibling, 0 replies; 113+ messages in thread From: Eli Zaretskii @ 2011-03-28 21:57 UTC (permalink / raw) To: chad; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: Still unable to build trunk 2011-01-23 21:23 ` Paul Eggert 2011-01-24 1:01 ` Stefan Monnier @ 2011-01-24 18:14 ` Eli Zaretskii 2011-01-24 20:58 ` Paul Eggert 1 sibling, 1 reply; 113+ messages in thread From: Eli Zaretskii @ 2011-01-24 18:14 UTC (permalink / raw) To: Paul Eggert; +Cc: cyd, jan.h.d, bug-gnulib, jim, emacs-devel > 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? ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: Still unable to build trunk 2011-01-24 18:14 ` Still unable to build trunk Eli Zaretskii @ 2011-01-24 20:58 ` Paul Eggert 2011-01-24 21:07 ` Andreas Schwab ` (2 more replies) 0 siblings, 3 replies; 113+ messages in thread From: Paul Eggert @ 2011-01-24 20:58 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cyd, jan.h.d, bug-gnulib, jim, emacs-devel 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: Still unable to build trunk 2011-01-24 20:58 ` Paul Eggert @ 2011-01-24 21:07 ` Andreas Schwab 2011-01-24 22:47 ` Glenn Morris 2011-01-26 12:35 ` Lennart Borgman 2 siblings, 0 replies; 113+ messages in thread From: Andreas Schwab @ 2011-01-24 21:07 UTC (permalink / raw) To: Paul Eggert; +Cc: bug-gnulib, cyd, jim, emacs-devel, Eli Zaretskii, jan.h.d > 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." ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: Still unable to build trunk 2011-01-24 20:58 ` Paul Eggert 2011-01-24 21:07 ` Andreas Schwab @ 2011-01-24 22:47 ` Glenn Morris 2011-01-25 6:01 ` Richard Stallman 2011-01-26 12:35 ` Lennart Borgman 2 siblings, 1 reply; 113+ messages in thread From: Glenn Morris @ 2011-01-24 22:47 UTC (permalink / raw) To: Paul Eggert; +Cc: Eli Zaretskii, jan.h.d, emacs-devel, cyd, jim 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 ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: Still unable to build trunk 2011-01-24 22:47 ` Glenn Morris @ 2011-01-25 6:01 ` Richard Stallman 2011-01-25 19:58 ` Eli Zaretskii 0 siblings, 1 reply; 113+ messages in thread From: Richard Stallman @ 2011-01-25 6:01 UTC (permalink / raw) To: Glenn Morris; +Cc: eggert, cyd, jim, emacs-devel, eliz, jan.h.d 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 ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: Still unable to build trunk 2011-01-25 6:01 ` Richard Stallman @ 2011-01-25 19:58 ` Eli Zaretskii 2011-01-25 20:14 ` Savannah loggerhead [was Re: Still unable to build trunk] Glenn Morris 2011-01-26 0:44 ` Still unable to build trunk Richard Stallman 0 siblings, 2 replies; 113+ messages in thread From: Eli Zaretskii @ 2011-01-25 19:58 UTC (permalink / raw) To: rms; +Cc: eggert, cyd, jim, emacs-devel, jan.h.d > 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.) ^ permalink raw reply [flat|nested] 113+ messages in thread
* Savannah loggerhead [was Re: Still unable to build trunk] 2011-01-25 19:58 ` Eli Zaretskii @ 2011-01-25 20:14 ` Glenn Morris 2011-01-26 0:44 ` Still unable to build trunk Richard Stallman 1 sibling, 0 replies; 113+ messages in thread From: Glenn Morris @ 2011-01-25 20:14 UTC (permalink / raw) To: Eli Zaretskii; +Cc: eggert, rms, cyd, jim, emacs-devel, jan.h.d 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.) ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: Still unable to build trunk 2011-01-25 19:58 ` Eli Zaretskii 2011-01-25 20:14 ` Savannah loggerhead [was Re: Still unable to build trunk] Glenn Morris @ 2011-01-26 0:44 ` Richard Stallman 2011-01-26 3:56 ` Eli Zaretskii 1 sibling, 1 reply; 113+ messages in thread From: Richard Stallman @ 2011-01-26 0:44 UTC (permalink / raw) To: Eli Zaretskii; +Cc: eggert, cyd, jim, emacs-devel, jan.h.d 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 ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: Still unable to build trunk 2011-01-26 0:44 ` Still unable to build trunk Richard Stallman @ 2011-01-26 3:56 ` Eli Zaretskii 0 siblings, 0 replies; 113+ messages in thread From: Eli Zaretskii @ 2011-01-26 3:56 UTC (permalink / raw) To: rms; +Cc: eggert, cyd, jim, emacs-devel, jan.h.d > 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: Still unable to build trunk 2011-01-24 20:58 ` Paul Eggert 2011-01-24 21:07 ` Andreas Schwab 2011-01-24 22:47 ` Glenn Morris @ 2011-01-26 12:35 ` Lennart Borgman 2011-01-26 13:18 ` Eli Zaretskii ` (3 more replies) 2 siblings, 4 replies; 113+ messages in thread From: Lennart Borgman @ 2011-01-26 12:35 UTC (permalink / raw) To: Paul Eggert; +Cc: bug-gnulib, cyd, jim, emacs-devel, Eli Zaretskii, jan.h.d 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 ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: Still unable to build trunk 2011-01-26 12:35 ` Lennart Borgman @ 2011-01-26 13:18 ` Eli Zaretskii 2011-01-26 13:35 ` Andy Moreton ` (2 subsequent siblings) 3 siblings, 0 replies; 113+ messages in thread From: Eli Zaretskii @ 2011-01-26 13:18 UTC (permalink / raw) To: Lennart Borgman; +Cc: eggert, bug-gnulib, cyd, jim, emacs-devel, jan.h.d > 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: Still unable to build trunk 2011-01-26 12:35 ` Lennart Borgman 2011-01-26 13:18 ` Eli Zaretskii @ 2011-01-26 13:35 ` Andy Moreton 2011-01-26 13:42 ` Jim Meyering 2011-01-29 13:04 ` Eli Zaretskii 3 siblings, 0 replies; 113+ messages in thread From: Andy Moreton @ 2011-01-26 13:35 UTC (permalink / raw) To: emacs-devel; +Cc: bug-gnulib 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 ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: Still unable to build trunk 2011-01-26 12:35 ` Lennart Borgman 2011-01-26 13:18 ` Eli Zaretskii 2011-01-26 13:35 ` Andy Moreton @ 2011-01-26 13:42 ` Jim Meyering 2011-01-27 9:38 ` Jim Meyering 2011-01-29 13:04 ` Eli Zaretskii 3 siblings, 1 reply; 113+ messages in thread From: Jim Meyering @ 2011-01-26 13:42 UTC (permalink / raw) To: Lennart Borgman Cc: Paul Eggert, bug-gnulib, cyd, emacs-devel, Eli Zaretskii, jan.h.d 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/ ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: Still unable to build trunk 2011-01-26 13:42 ` Jim Meyering @ 2011-01-27 9:38 ` Jim Meyering 2011-01-27 11:16 ` Eli Zaretskii 0 siblings, 1 reply; 113+ messages in thread From: Jim Meyering @ 2011-01-27 9:38 UTC (permalink / raw) To: Lennart Borgman Cc: Paul Eggert, bug-gnulib, cyd, emacs-devel, Eli Zaretskii, jan.h.d 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 ^ permalink raw reply related [flat|nested] 113+ messages in thread
* Re: Still unable to build trunk 2011-01-27 9:38 ` Jim Meyering @ 2011-01-27 11:16 ` Eli Zaretskii 2011-01-27 11:20 ` Lennart Borgman 0 siblings, 1 reply; 113+ messages in thread From: Eli Zaretskii @ 2011-01-27 11:16 UTC (permalink / raw) To: Jim Meyering; +Cc: cyd, eggert, lennart.borgman, jan.h.d, emacs-devel > 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: Still unable to build trunk 2011-01-27 11:16 ` Eli Zaretskii @ 2011-01-27 11:20 ` Lennart Borgman 2011-01-27 11:31 ` Eli Zaretskii 0 siblings, 1 reply; 113+ messages in thread From: Lennart Borgman @ 2011-01-27 11:20 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cyd, eggert, Jim Meyering, jan.h.d, emacs-devel 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? ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: Still unable to build trunk 2011-01-27 11:20 ` Lennart Borgman @ 2011-01-27 11:31 ` Eli Zaretskii 2011-01-27 18:27 ` Paul Eggert 0 siblings, 1 reply; 113+ messages in thread From: Eli Zaretskii @ 2011-01-27 11:31 UTC (permalink / raw) To: Lennart Borgman; +Cc: cyd, eggert, jim, jan.h.d, emacs-devel > 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: Still unable to build trunk 2011-01-27 11:31 ` Eli Zaretskii @ 2011-01-27 18:27 ` Paul Eggert 2011-01-29 11:49 ` Darren Hoo 0 siblings, 1 reply; 113+ messages in thread From: Paul Eggert @ 2011-01-27 18:27 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cyd, jan.h.d, Lennart Borgman, jim, emacs-devel 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: Still unable to build trunk 2011-01-27 18:27 ` Paul Eggert @ 2011-01-29 11:49 ` Darren Hoo 2011-01-29 12:19 ` Darren Hoo 0 siblings, 1 reply; 113+ messages in thread From: Darren Hoo @ 2011-01-29 11:49 UTC (permalink / raw) To: emacs-devel 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? ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: Still unable to build trunk 2011-01-29 11:49 ` Darren Hoo @ 2011-01-29 12:19 ` Darren Hoo 0 siblings, 0 replies; 113+ messages in thread From: Darren Hoo @ 2011-01-29 12:19 UTC (permalink / raw) To: emacs-devel 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
* Re: Still unable to build trunk 2011-01-26 12:35 ` Lennart Borgman ` (2 preceding siblings ...) 2011-01-26 13:42 ` Jim Meyering @ 2011-01-29 13:04 ` Eli Zaretskii 3 siblings, 0 replies; 113+ messages in thread From: Eli Zaretskii @ 2011-01-29 13:04 UTC (permalink / raw) To: Lennart Borgman; +Cc: eggert, bug-gnulib, cyd, jim, emacs-devel, jan.h.d > 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. ^ permalink raw reply [flat|nested] 113+ messages in thread
end of thread, other threads:[~2011-03-31 14:36 UTC | newest] Thread overview: 113+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-01-20 18:47 Still unable to build trunk Chong Yidong 2011-01-20 19:39 ` Jan Djärv 2011-01-20 22:16 ` Chong Yidong 2011-01-21 20:42 ` Paul Eggert 2011-01-22 1:29 ` Chong Yidong 2011-01-22 7:25 ` Paul Eggert 2011-01-22 15:03 ` Eli Zaretskii 2011-01-23 15:33 ` Jim Meyering 2011-01-23 17:00 ` Eli Zaretskii 2011-01-23 17:35 ` Jim Meyering 2011-01-23 18:14 ` Eli Zaretskii 2011-01-23 18:47 ` Jim Meyering 2011-01-23 19:06 ` Eli Zaretskii 2011-01-23 20:08 ` Jim Meyering 2011-01-23 21:23 ` Paul Eggert 2011-01-24 1:01 ` Stefan Monnier 2011-01-24 1:22 ` Miles Bader 2011-01-24 8:48 ` Glenn Morris 2011-01-24 16:26 ` Stefan Monnier 2011-03-08 4:22 ` A better autogen.sh [was Re: Still unable to build trunk] Glenn Morris 2011-03-08 19:51 ` Stefan Monnier 2011-03-10 16:10 ` Thien-Thi Nguyen 2011-03-15 20:22 ` A better autogen.sh Glenn Morris 2011-03-15 21:52 ` Paul Eggert 2011-03-15 22:09 ` Glenn Morris 2011-03-15 22:37 ` Glenn Morris 2011-03-15 22:58 ` Paul Eggert 2011-03-16 4:05 ` Eli Zaretskii 2011-03-16 4:14 ` Glenn Morris 2011-03-16 4:17 ` Glenn Morris 2011-03-16 5:53 ` Eli Zaretskii 2011-03-16 6:39 ` Paul Eggert 2011-03-16 8:10 ` Eli Zaretskii 2011-03-16 9:08 ` Paul Eggert 2011-03-16 10:12 ` Eli Zaretskii 2011-03-16 10:47 ` joakim 2011-03-16 11:53 ` Eli Zaretskii 2011-03-16 12:25 ` joakim 2011-03-16 12:42 ` Eli Zaretskii 2011-03-16 17:52 ` Paul Eggert 2011-03-16 18:54 ` Eli Zaretskii 2011-03-16 20:40 ` Paul Eggert 2011-03-16 11:33 ` Juanma Barranquero 2011-03-16 11:21 ` Juanma Barranquero 2011-03-16 6:43 ` Glenn Morris 2011-03-16 8:47 ` Eli Zaretskii 2011-03-16 9:23 ` Paul Eggert 2011-03-16 10:37 ` Eli Zaretskii 2011-03-16 17:17 ` Glenn Morris 2011-03-16 17:45 ` Glenn Morris 2011-03-16 18:16 ` Eli Zaretskii 2011-03-16 18:20 ` Glenn Morris 2011-03-16 19:13 ` Eli Zaretskii 2011-03-16 18:15 ` Eli Zaretskii 2011-03-16 15:34 ` Stefan Monnier 2011-03-16 18:09 ` Glenn Morris 2011-03-16 19:12 ` Eli Zaretskii 2011-03-16 19:40 ` Stefan Monnier 2011-03-16 20:56 ` Paul Eggert 2011-03-17 20:36 ` Glenn Morris 2011-03-17 20:40 ` Eli Zaretskii 2011-03-17 20:44 ` Glenn Morris 2011-03-17 20:51 ` Eli Zaretskii 2011-03-18 2:02 ` Paul Eggert 2011-03-16 18:10 ` Eli Zaretskii 2011-03-16 19:13 ` Eli Zaretskii 2011-03-28 20:29 ` A better autogen.sh [was Re: Still unable to build trunk] chad 2011-03-28 20:58 ` A better autogen.sh Glenn Morris 2011-03-28 21:45 ` Chad Brown 2011-03-28 21:51 ` Glenn Morris 2011-03-29 1:17 ` Stefan Monnier 2011-03-29 2:21 ` Glenn Morris 2011-03-29 3:36 ` Stefan Monnier 2011-03-29 6:39 ` Glenn Morris 2011-03-29 12:09 ` Jim Meyering 2011-03-29 12:19 ` Andreas Schwab 2011-03-29 12:23 ` Jim Meyering 2011-03-29 14:13 ` Stephen J. Turnbull 2011-03-29 15:25 ` Jim Meyering 2011-03-29 16:38 ` Stephen J. Turnbull 2011-03-29 18:46 ` chad 2011-03-30 6:15 ` Jim Meyering 2011-03-30 11:27 ` Eli Zaretskii 2011-03-30 12:03 ` Jim Meyering 2011-03-30 17:48 ` Eli Zaretskii 2011-03-30 19:26 ` Jim Meyering 2011-03-30 20:02 ` Eli Zaretskii 2011-03-30 20:14 ` Glenn Morris 2011-03-30 21:36 ` Stefan Monnier 2011-03-30 21:41 ` Glenn Morris 2011-03-31 14:36 ` Stefan Monnier 2011-03-28 21:57 ` A better autogen.sh [was Re: Still unable to build trunk] Eli Zaretskii 2011-01-24 18:14 ` Still unable to build trunk Eli Zaretskii 2011-01-24 20:58 ` Paul Eggert 2011-01-24 21:07 ` Andreas Schwab 2011-01-24 22:47 ` Glenn Morris 2011-01-25 6:01 ` Richard Stallman 2011-01-25 19:58 ` Eli Zaretskii 2011-01-25 20:14 ` Savannah loggerhead [was Re: Still unable to build trunk] Glenn Morris 2011-01-26 0:44 ` Still unable to build trunk Richard Stallman 2011-01-26 3:56 ` Eli Zaretskii 2011-01-26 12:35 ` Lennart Borgman 2011-01-26 13:18 ` Eli Zaretskii 2011-01-26 13:35 ` Andy Moreton 2011-01-26 13:42 ` Jim Meyering 2011-01-27 9:38 ` Jim Meyering 2011-01-27 11:16 ` Eli Zaretskii 2011-01-27 11:20 ` Lennart Borgman 2011-01-27 11:31 ` Eli Zaretskii 2011-01-27 18:27 ` Paul Eggert 2011-01-29 11:49 ` Darren Hoo 2011-01-29 12:19 ` Darren Hoo 2011-01-29 13:04 ` Eli Zaretskii
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.