Building Emacs on MSYS2 (was: Build failure for Emacs master)

Building Emacs on MSYS2 (was: Build failure for Emacs master)

[Angelo Graziosi]

Ciao Óscar,

Óscar Fuentes wrote:
> AFAIK Angelo and others that build Emacs on MSYS2 are not using
> the PKGBUILD, but following the recipe on the Emacs' docs (possibly with
> their own personal modifications.)

really, I DO build Emacs on MSYS2 with that _PKGBUILD_ [*]. It is on 
GNU/Linux and on OSX which I use some other recipe (my build scripts..)

Regarding the image.c.diff and lread.c.diff patches...

If I remember correctly, when the mingw*imagemagick port is installed, 
'configure' tries to "build" using the imagemagick support and the build 
fails if those patches are not applied.. Maybe the patches fix the build 
with imagemagick support. But is it a real support or only a workaround 
so that the build is completed, apparently adding the support for 
imagemagick?

I have this doubt..


Ciao,
  Angelo.

---
[*] Oops.. with my modification:

$ cat mingw-w64-emacs-git/PKGBUILD
[...]

## USAGE EXAMPLES:
##
##  MAKE_OPT='-j3' MINGW_INSTALLS=mingw64 makepkg-mingw -sLf
##

: ${MAKE_OPT=}

[...]

prepare() {
   cd "${_realname}"
   patch --binary --forward -p0 < "${srcdir}/image.c.diff"
   patch --binary --forward -p0 < "${srcdir}/lread.c.diff"
   ./autogen.sh all
}

build() {
   [[ -d "${srcdir}/build-${MINGW_CHOST}" ]] && rm -rf 
"${srcdir}/build-${MINGW_CHOST}"
   mkdir -p "${srcdir}/build-${MINGW_CHOST}"
   cd "build-${MINGW_CHOST}"

   local with_wide_int='no'

   if test "${CARCH}" == 'x86_64'; then
     with_wide_int='yes'
   fi

   CPPFLAGS="-DNDEBUG -isystem ${MINGW_PREFIX}/include"
   CFLAGS="-pipe -O3 -fomit-frame-pointer -funroll-loops"
   LDFLAGS="-s -Wl,-s"
   "${srcdir}/${_realname}/configure" \
     --prefix="${MINGW_PREFIX}" \
     --build="${MINGW_CHOST}" \
     --enable-gcc-warnings=no \
     --with-wide-int="${with_wide_int}" \
     --with-sound="yes" \
     --with-file-notification="yes" \
     --without-gpm \
     --without-gconf \
     --without-gsettings \
     --without-selinux

   echo
   echo "Using MAKE_OPT = ${MAKE_OPT}"
   echo

   make ${MAKE_OPT}
}

[...]

Re: Building Emacs on MSYS2 (was: Build failure for Emacs master)

[Eli Zaretskii]

> From: Angelo Graziosi <angelo.graziosi@alice.it>
> Date: Thu, 14 Apr 2016 21:56:11 +0200
> 
> If I remember correctly, when the mingw*imagemagick port is installed, 
> 'configure' tries to "build" using the imagemagick support and the build 
> fails if those patches are not applied..

Then you should give the --without-imagemagick switch to configure.

Build failure for Emacs master

[Angelo Graziosi]

Just for the record, master fail to build on MSYS2/MinGW64:
[...]
Loading faces...
Loading button...
Loading loaddefs.el (source)...
End of file during parsing: 
c:/msys64/tmp/mingw-w64-emacs-git/src/emacs/lisp/loaddefs.el
Makefile:540: set di istruzioni per l'obiettivo "emacs.exe" non riuscito
make[1]: *** [emacs.exe] Errore 127
make[1]: uscita dalla directory 
"/tmp/mingw-w64-emacs-git/src/build-x86_64-w64-mingw32/src"
Makefile:398: set di istruzioni per l'obiettivo "src" non riuscito
make: *** [src] Errore 2

I did a successful build after last merge (commit Merge from 
origin/emacs-25 81ef756e6aea369ec78f19b3609f01ceddc5851f), maybe some 
recent change should be still tuned..

   Angelo

Re: Build failure for Emacs master

[Eli Zaretskii]

> From: Angelo Graziosi <angelo.graziosi@alice.it>
> Date: Tue, 23 Feb 2016 23:11:42 +0100
> 
> Just for the record, master fail to build on MSYS2/MinGW64:

It doesn't fail for me.

> Loading faces...
> Loading button...
> Loading loaddefs.el (source)...
> End of file during parsing: 
> c:/msys64/tmp/mingw-w64-emacs-git/src/emacs/lisp/loaddefs.el

Please look at your loaddefs.el, and tell if you see something strange
there, like null bytes.

Re: Build failure for Emacs master

[Angelo Graziosi]

Il 24/02/2016 04:42, Eli Zaretskii ha scritto:
>> From: Angelo Graziosi <angelo.graziosi@alice.it>
>> Date: Tue, 23 Feb 2016 23:11:42 +0100
>>
>> Just for the record, master fail to build on MSYS2/MinGW64:
>
> It doesn't fail for me.
>
>> Loading faces...
>> Loading button...
>> Loading loaddefs.el (source)...
>> End of file during parsing:
>> c:/msys64/tmp/mingw-w64-emacs-git/src/emacs/lisp/loaddefs.el
>
> Please look at your loaddefs.el, and tell if you see something strange
> there, like null bytes.
>

Hmm.. I removed the Emacs tree and recreated from scratch, then retried 
the build.. Now it fails on another loaddefs, org-loaddefs.el. I have 
seen the same failure a week ago or so and just retrying worked...

I wonder if this could be related to the "make -j3" (two core) or some 
other thing in MSYS2..

Let's see what happen with another try..


   Angelo

Re: Build failure for Emacs master

[Angelo Graziosi]

Il 24/02/2016 10:36, Angelo Graziosi ha scritto:
>
> Let's see what happen with another try..
>

Indeed, just retrying builds OB..

>
>    Angelo

Re: Build failure for Emacs master

[Eli Zaretskii]

> From: Angelo Graziosi <angelo.graziosi@alice.it>
> Date: Wed, 24 Feb 2016 11:20:56 +0100
> Cc: emacs-devel@gnu.org
> 
> Il 24/02/2016 10:36, Angelo Graziosi ha scritto:
> >
> > Let's see what happen with another try..
> >
> 
> Indeed, just retrying builds OB..

Alas, this tells us nothing about the reason for the original problem.

Re: Build failure for Emacs master

[Angelo Graziosi]

Il 24/02/2016 18:37, Eli Zaretskii ha scritto:
>> From: Angelo Graziosi <angelo.graziosi@alice.it>
>> Date: Wed, 24 Feb 2016 11:20:56 +0100
>> Cc: emacs-devel@gnu.org
>>
>> Il 24/02/2016 10:36, Angelo Graziosi ha scritto:
>>>
>>> Let's see what happen with another try..
>>>
>>
>> Indeed, just retrying builds OB..
>
> Alas, this tells us nothing about the reason for the original problem.
>

Another try, another failure:
[...]
Loading loaddefs.el (source)...
End of file during parsing: 
c:/msys64/tmp/mingw-w64-emacs-git/src/emacs/lisp/loaddefs.el
Makefile:540: set di istruzioni per l'obiettivo "emacs.exe" non riuscito
make[1]: *** [emacs.exe] Errore 127
make[1]: uscita dalla directory 
"/tmp/mingw-w64-emacs-git/src/build-x86_64-w64-mingw32/src"
Makefile:398: set di istruzioni per l'obiettivo "src" non riuscito
make: *** [src] Errore 2

with master-ce6a03cb00fb95b3e32440c1388d5f40375aadb2 (Fix problem in 
tramp.texi).

Really c:/msys64/tmp/mingw-w64-emacs-git/src/emacs/lisp/loaddefs.el 
seems broken

cat /tmp/mingw-w64-emacs-git/src/emacs/lisp/loaddefs.el
[...]
(autoload 'woman "woman" "\
Browse UN*X man page for TOPIC (Without using external Man program).
The major browsing mode used is essentially the standard Man mode.
Choose the filename for the man page using completion, based on the
topic selected from the directories specified in `woman-manpath' and
`woman-path'.  The directory expa

   A LOT OF "APPARENTLY" EMPTY SPACE


but when I visit it with Emacs, 'A LOT OF "APPARENTLY" EMPTY SPACE' is a 
lot of "^@" characters.

BTW, insisting to visit it, Emacs hangs (I have to kill it with task 
manager...)

If you want I can sent it to someone of you, off list (xz compressed is 
about 250K).


   Angelo

Re: Build failure for Emacs master

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Angelo Graziosi <angelo.graziosi@alice.it>
> Date: Wed, 24 Feb 2016 23:20:23 +0100
> 
> cat /tmp/mingw-w64-emacs-git/src/emacs/lisp/loaddefs.el
> [...]
> (autoload 'woman "woman" "\
> Browse UN*X man page for TOPIC (Without using external Man program).
> The major browsing mode used is essentially the standard Man mode.
> Choose the filename for the man page using completion, based on the
> topic selected from the directories specified in `woman-manpath' and
> `woman-path'.  The directory expa
> 
>    A LOT OF "APPARENTLY" EMPTY SPACE
> 
> 
> but when I visit it with Emacs, 'A LOT OF "APPARENTLY" EMPTY SPACE' is a 
> lot of "^@" characters.

Yes, that's what happens in these cases.  So the problem is still
present, sigh.  Unfortunately, it stopped happening on my system, so I
cannot debug it.

To solve this simply copy ldefs-boot.el over loaddefs.el, and rebuild.

Re: Build failure for Emacs master

[Angelo Graziosi]

Just for the record..

Now the build of current master (ac9a931...) fails with:

[...]
Loading button...
Loading loaddefs.el (source)...
Wrong number of arguments: autoload, 1325
Makefile:540: set di istruzioni per l'obiettivo "emacs.exe" non riuscito
make[1]: *** [emacs.exe] Errore 127
make[1]: uscita dalla directory 
"/tmp/mingw-w64-emacs-git/src/build-x86_64-w64-mingw32/src"
Makefile:398: set di istruzioni per l'obiettivo "src" non riuscito
make: *** [src] Errore 2


All the loaddefs.el files are:

$ find . -name "loaddefs*"
./src/emacs/lisp/cedet/ede/loaddefs.el
./src/emacs/lisp/cedet/ede/loaddefs.el~
./src/emacs/lisp/cedet/semantic/loaddefs.el
./src/emacs/lisp/cedet/semantic/loaddefs.el~
./src/emacs/lisp/cedet/srecode/loaddefs.el
./src/emacs/lisp/cedet/srecode/loaddefs.el~
./src/emacs/lisp/loaddefs.el
./src/emacs/lisp/loaddefs.el~

and

$ cat ./src/emacs/lisp/loaddefs.el
[...]
(autoload 'xref-collect-matches "xref" "\
Collect matches for REGEXP inside FILES in DIR.
FILES is a string with glob patterns separated by spaces.
IGNORES is a list of glob patterns.

\(fn REGEXP FILES DIR IGNORES)" nil nil)

;;;***


while for the others

$ cat ./src/emacs/lisp/.../loaddefs.el
[...]
;;;***


(provide 'loaddefs)
;; Local Variables:
;; version-control: never
;; no-byte-compile: t
;; no-update-autoloads: t
;; coding: utf-8
;; End:
;;; loaddefs.el ends here


Maybe just retrying builds..

In any cases this kind of failures are rather recent. I have built 
master on MSYS2 for months without any failure and since, say, first 
decade of February they occur..


   Angelo


Il 25/02/2016 17:43, Eli Zaretskii ha scritto:
>> Cc: emacs-devel@gnu.org
>> From: Angelo Graziosi <angelo.graziosi@alice.it>
>> Date: Wed, 24 Feb 2016 23:20:23 +0100
>>
>> cat /tmp/mingw-w64-emacs-git/src/emacs/lisp/loaddefs.el
>> [...]
>> (autoload 'woman "woman" "\
>> Browse UN*X man page for TOPIC (Without using external Man program).
>> The major browsing mode used is essentially the standard Man mode.
>> Choose the filename for the man page using completion, based on the
>> topic selected from the directories specified in `woman-manpath' and
>> `woman-path'.  The directory expa
>>
>>     A LOT OF "APPARENTLY" EMPTY SPACE
>>
>>
>> but when I visit it with Emacs, 'A LOT OF "APPARENTLY" EMPTY SPACE' is a
>> lot of "^@" characters.
>
> Yes, that's what happens in these cases.  So the problem is still
> present, sigh.  Unfortunately, it stopped happening on my system, so I
> cannot debug it.
>
> To solve this simply copy ldefs-boot.el over loaddefs.el, and rebuild.
>

Re: Build failure for Emacs master

[Eli Zaretskii]

> From: Angelo Graziosi <angelo.graziosi@alice.it>
> Date: Fri, 4 Mar 2016 22:50:31 +0100
> 
> $ cat ./src/emacs/lisp/loaddefs.el
> [...]
> (autoload 'xref-collect-matches "xref" "\
> Collect matches for REGEXP inside FILES in DIR.
> FILES is a string with glob patterns separated by spaces.
> IGNORES is a list of glob patterns.
> 
> \(fn REGEXP FILES DIR IGNORES)" nil nil)
> 
> ;;;***
> 
> 
> while for the others
> 
> $ cat ./src/emacs/lisp/.../loaddefs.el
> [...]
> ;;;***
> 
> 
> (provide 'loaddefs)
> ;; Local Variables:
> ;; version-control: never
> ;; no-byte-compile: t
> ;; no-update-autoloads: t
> ;; coding: utf-8
> ;; End:
> ;;; loaddefs.el ends here
> 
> 
> Maybe just retrying builds..

Yes, this looks like the same problem.

The challenge is to catch the instance when such a faulty loaddefs.el
is produced, and see what happens there.  Ideas for how to do that are
welcome.

> In any cases this kind of failures are rather recent. I have built 
> master on MSYS2 for months without any failure and since, say, first 
> decade of February they occur..

I've seen this first in last November.  Not sure if it's the same
problem, but the symptoms are very similar.

Are all of your builds full bootstraps in a fresh directory using a
freshly cloned repository?

Re: Build failure for Emacs master

[Angelo Graziosi]

Just for the record...

After about a month, the issue has reappeared.

Now it fails with this message:

[...]
Loading button...
Loading loaddefs.el (source)...
Wrong number of arguments: autoload, 1325
Makefile:540: set di istruzioni per l'obiettivo "emacs.exe" non riuscito
make[1]: *** [emacs.exe] Errore 127
make[1]: uscita dalla directory "/tmp/work/emacs-master/src"
Makefile:398: set di istruzioni per l'obiettivo "src" non riuscito
make: *** [src] Errore 2

but the lisp/loaddefs.el seems to have the same defects..

Ciao,
  Angelo.

Il 05/03/2016 08:25, Eli Zaretskii ha scritto:
>> From: Angelo Graziosi <angelo.graziosi@alice.it>
>> Date: Fri, 4 Mar 2016 22:50:31 +0100
>>
>> $ cat ./src/emacs/lisp/loaddefs.el
>> [...]
>> (autoload 'xref-collect-matches "xref" "\
>> Collect matches for REGEXP inside FILES in DIR.
>> FILES is a string with glob patterns separated by spaces.
>> IGNORES is a list of glob patterns.
>>
>> \(fn REGEXP FILES DIR IGNORES)" nil nil)
>>
>> ;;;***
>>
>>
>> while for the others
>>
>> $ cat ./src/emacs/lisp/.../loaddefs.el
>> [...]
>> ;;;***
>>
>>
>> (provide 'loaddefs)
>> ;; Local Variables:
>> ;; version-control: never
>> ;; no-byte-compile: t
>> ;; no-update-autoloads: t
>> ;; coding: utf-8
>> ;; End:
>> ;;; loaddefs.el ends here
>>
>>
>> Maybe just retrying builds..
>
> Yes, this looks like the same problem.
>
> The challenge is to catch the instance when such a faulty loaddefs.el
> is produced, and see what happens there.  Ideas for how to do that are
> welcome.
>
>> In any cases this kind of failures are rather recent. I have built
>> master on MSYS2 for months without any failure and since, say, first
>> decade of February they occur..
>
> I've seen this first in last November.  Not sure if it's the same
> problem, but the symptoms are very similar.
>
> Are all of your builds full bootstraps in a fresh directory using a
> freshly cloned repository?
>

Re: Build failure for Emacs master

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Angelo Graziosi <angelo.graziosi@alice.it>
> Date: Tue, 12 Apr 2016 02:36:23 +0200
> 
> Just for the record...
> 
> After about a month, the issue has reappeared.
> 
> Now it fails with this message:
> 
> [...]
> Loading button...
> Loading loaddefs.el (source)...
> Wrong number of arguments: autoload, 1325
> Makefile:540: set di istruzioni per l'obiettivo "emacs.exe" non riuscito
> make[1]: *** [emacs.exe] Errore 127
> make[1]: uscita dalla directory "/tmp/work/emacs-master/src"
> Makefile:398: set di istruzioni per l'obiettivo "src" non riuscito
> make: *** [src] Errore 2
> 
> but the lisp/loaddefs.el seems to have the same defects..

And if you delete loaddefs.el, does the following build succeed?

Re: Build failure for Emacs master

[Angelo Graziosi]

Surely this has nothing to do with the issue described here but why now


./autogen.sh
Checking whether you have the necessary tools...
(Read INSTALL.REPO for more details on building Emacs)
Checking for autoconf (need at least version 2.65)...
ok
Checking for automake (need at least version 1.11)...
ok
Your system has the required tools.
Running 'autoreconf -fi -I m4' ...
configure.ac:796: installing 'build-aux/ar-lib'
configure.ac:139: installing 'build-aux/config.guess'
configure.ac:139: installing 'build-aux/config.sub'
configure.ac:136: installing 'build-aux/install-sh'
configure.ac:136: installing 'build-aux/missing'
lib/Makefile.am: installing 'build-aux/depcomp'
You can now run './autogen.sh git'.


Really we need to run './autogen.sh git'?

Maybe I am wrong but INSTALL.REPO, which should contain the "more 
details on building Emacs", does not document this nor the "git" option 
for autogen.sh nor the other "all" option..

Maybe I am only adopting the wrong procedure to build Emacs and.. hem.. 
hem.. I see this build failure.. hem.. hem...

  Angelo

>> From: Angelo Graziosi
>> Date: Tue, 12 Apr 2016 02:36:23 +0200
>>
>> Just for the record...
>>
>> After about a month, the issue has reappeared.
>>
>> Now it fails with this message:
>>
>> [...]
>> Loading button...
>> Loading loaddefs.el (source)...
>> Wrong number of arguments: autoload, 1325
>> Makefile:540: set di istruzioni per l'obiettivo "emacs.exe" non riuscito
>> make[1]: *** [emacs.exe] Errore 127
>> make[1]: uscita dalla directory "/tmp/work/emacs-master/src"
>> Makefile:398: set di istruzioni per l'obiettivo "src" non riuscito
>> make: *** [src] Errore 2

Re: Build failure for Emacs master

[Paul Eggert]

On 04/13/2016 01:12 PM, Angelo Graziosi wrote:
> why now
>
> ./autogen.sh
> ...
> You can now run './autogen.sh git'.
>
> Really we need to run './autogen.sh git'?

Yes you need to, and yes it is silly.  This extra step was put in as a 
result of the email thread starting here:

http://lists.gnu.org/archive/html/emacs-devel/2016-02/msg00012.html

I preferred a simpler system where ./autogen.sh just works, without any 
extra steps, but I was outvoted.

> Maybe I am wrong but INSTALL.REPO, which should contain the "more 
> details on building Emacs", does not document this nor the "git" 
> option for autogen.sh nor the other "all" option.

Although INSTALL.REPO contains "more details", it shouldn't contain 
*all* details (as there are too many). It's not clear that this 
particular detail is worth recording in INSTALL.REPO.

> Maybe I am only adopting the wrong procedure to build Emacs

Yes, as you used a procedure that is not recommended in INSTALL.REPO. 
You would have avoided the './install.sh git' glitch if you had run 
plain 'make', or had run './autogen.sh all', which are the two methods 
that INSTALL.REPO suggests.

Re: Build failure for Emacs master

[Angelo Graziosi]

Il 13/04/2016 23:32, Paul Eggert ha scritto:
> On 04/13/2016 01:12 PM, Angelo Graziosi wrote:
>> why now
>>
>> ./autogen.sh
>> ...
>> You can now run './autogen.sh git'.
>>
>> Really we need to run './autogen.sh git'?
>
> Yes you need to, and yes it is silly.  This extra step was put in as a
> result of the email thread starting here:
>
> http://lists.gnu.org/archive/html/emacs-devel/2016-02/msg00012.html
>
> I preferred a simpler system where ./autogen.sh just works, without any
> extra steps, but I was outvoted.
>
>> Maybe I am wrong but INSTALL.REPO, which should contain the "more
>> details on building Emacs", does not document this nor the "git"
>> option for autogen.sh nor the other "all" option.
>
> Although INSTALL.REPO contains "more details", it shouldn't contain
> *all* details (as there are too many). It's not clear that this
> particular detail is worth recording in INSTALL.REPO.
>
>> Maybe I am only adopting the wrong procedure to build Emacs
>
> Yes, as you used a procedure that is not recommended in INSTALL.REPO.
> You would have avoided the './install.sh git' glitch if you had run
> plain 'make', or had run './autogen.sh all', which are the two methods
> that INSTALL.REPO suggests.


Hmmm... './autogen.sh all' does not work using 
http://git.savannah.gnu.org/cgit/emacs.git/snapshot/emacs-master.tar.gz 
as source:


./autogen.sh all
Checking whether you have the necessary tools...
(Read INSTALL.REPO for more details on building Emacs)
Checking for autoconf (need at least version 2.65)...
ok
Checking for automake (need at least version 1.11)...
ok
Your system has the required tools.
Running 'autoreconf -fi -I m4' ...
configure.ac:796: installing 'build-aux/ar-lib'
configure.ac:139: installing 'build-aux/config.guess'
configure.ac:139: installing 'build-aux/config.sub'
configure.ac:136: installing 'build-aux/install-sh'
configure.ac:136: installing 'build-aux/missing'
lib/Makefile.am: installing 'build-aux/depcomp'
Configuring local git repository...
cp: impossibile eseguire stat di '.git/config': No such file or directory

or one is "constrained" to use a clone of git repo? Only an ill mind 
could think that..

  Angelo

Re: Build failure for Emacs master

[Paul Eggert]

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

On 04/13/2016 03:00 PM, Angelo Graziosi wrote:
>
> './autogen.sh all' does not work using 
> http://git.savannah.gnu.org/cgit/emacs.git/snapshot/emacs-master.tar.gz as 
> source: 

That's a different approach from what's in INSTALL.REPO. INSTALL.REPO 
assumes you're building from a Git clone; among other things, that's why 
INSTALL.REPO requires that you have Git installed. Since you're using a 
strategy that does not involve Git, a different procedure is called for.

'./autogen.sh all' can be adjusted to work for your use case. I 
installed the attached patch, which attempts to do that. Please give it 
a try.

[-- Attachment #2: 0001-Port-.-autogen.sh-git-to-non-clones.txt --]
[-- Type: text/plain, Size: 3020 bytes --]

From 1aa7a86397a750cf93a6377e413cfb4ea4db2735 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Wed, 13 Apr 2016 18:19:04 -0700
Subject: [PATCH] =?UTF-8?q?Port=20=E2=80=98./autogen.sh=20git=E2=80=99=20t?=
 =?UTF-8?q?o=20non-clones?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Problem reported by Angelo Graziosi in:
http://lists.gnu.org/archive/html/emacs-devel/2016-04/msg00341.html
* autogen.sh (do_git): Default to false when the arg is ‘all’ but
there is no ‘.git’.
(git_common_dir, hooks): New vars.
(git_config, tailored_hooks, sample_hooks): Use them.
---
 autogen.sh | 26 +++++++++++++++++---------
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/autogen.sh b/autogen.sh
index 2e10a77..cd0accd 100755
--- a/autogen.sh
+++ b/autogen.sh
@@ -112,7 +112,8 @@ do_git=
       --help)
 	exec echo "$0: usage: $0 [all|autoconf|git]";;
       all)
-	do_autoconf=true do_git=true;;
+	do_autoconf=true
+	test -e .git && do_git=true;;
       autoconf)
 	do_autoconf=true;;
       git)
@@ -260,7 +261,8 @@ git_config ()
 		echo 'Configuring local git repository...'
 		case $cp_options in
 		  --backup=*)
-		    cp $cp_options --force .git/config .git/config || exit;;
+		    config=$git_common_dir/config
+		    cp $cp_options --force -- "$config" "$config" || exit;;
 		esac
 	    fi
 	    echo "git config $name '$value'"
@@ -272,6 +274,13 @@ git_config ()
 
 ## Configure Git, if requested.
 
+# Get location of Git's common configuration directory.  For older Git
+# versions this is just '.git'.  Newer Git versions support worktrees.
+
+test -e .git && git_common_dir=`git rev-parse --git-common-dir 2>/dev/null` ||
+  git_common_dir=.git
+hooks=$git_common_dir/hooks
+
 # Check hashes when transferring objects among repositories.
 
 git_config transfer.fsckObjects true
@@ -296,12 +305,11 @@ tailored_hooks=
 sample_hooks=
 
 for hook in commit-msg pre-commit; do
-    cmp build-aux/git-hooks/$hook .git/hooks/$hook >/dev/null 2>&1 ||
+    cmp -- build-aux/git-hooks/$hook "$hooks/$hook" >/dev/null 2>&1 ||
 	tailored_hooks="$tailored_hooks $hook"
 done
 for hook in applypatch-msg pre-applypatch; do
-    src=.git/hooks/$hook.sample
-    cmp "$src" .git/hooks/$hook >/dev/null 2>&1 ||
+    cmp -- "$hooks/$hook.sample" "$hooks/$hook" >/dev/null 2>&1 ||
 	sample_hooks="$sample_hooks $hook"
 done
 
@@ -311,15 +319,15 @@ sample_hooks=
 
 	if test -n "$tailored_hooks"; then
 	    for hook in $tailored_hooks; do
-		dst=.git/hooks/$hook
-		cp $cp_options build-aux/git-hooks/$hook "$dst" || exit
-		chmod a-w "$dst" || exit
+		dst=$hooks/$hook
+		cp $cp_options -- build-aux/git-hooks/$hook "$dst" || exit
+		chmod -- a-w "$dst" || exit
 	    done
 	fi
 
 	if test -n "$sample_hooks"; then
 	    for hook in $sample_hooks; do
-		cp $cp_options .git/hooks/$hook.sample .git/hooks/$hook || exit
+		cp $cp_options -- "$hooks/$hook.sample" "$hooks/$hook" || exit
 		chmod a-w .git/hooks/$hook || exit
 	    done
 	fi
-- 
2.5.5

Re: Build failure for Emacs master

[Angelo Graziosi]

Il 14/04/2016 03:31, Paul Eggert ha scritto:
> On 04/13/2016 03:00 PM, Angelo Graziosi wrote:
>>
>> './autogen.sh all' does not work using
>> http://git.savannah.gnu.org/cgit/emacs.git/snapshot/emacs-master.tar.gz as
>> source:
>
> That's a different approach from what's in INSTALL.REPO. INSTALL.REPO

In MSYS2 and other OS there are *-git packages just to have the last 
development source not because that people aims to develop and maintain 
the applications of those packages..

So even when Emacs source comes from git you should not need other 
option for autogen.sh...

> assumes you're building from a Git clone; among other things, that's why
> INSTALL.REPO requires that you have Git installed. Since you're using a
> strategy that does not involve Git, a different procedure is called for.
>
> './autogen.sh all' can be adjusted to work for your use case. I
> installed the attached patch, which attempts to do that. Please give it
> a try.

Maybe when I have some time..

Re: Build failure for Emacs master

[Eli Zaretskii]

> From: Angelo Graziosi <angelo.graziosi@alice.it>
> Date: Thu, 14 Apr 2016 10:03:19 +0200
> Cc: Emacs development discussions <emacs-devel@gnu.org>
> 
> Il 14/04/2016 03:31, Paul Eggert ha scritto:
> > On 04/13/2016 03:00 PM, Angelo Graziosi wrote:
> >>
> >> './autogen.sh all' does not work using
> >> http://git.savannah.gnu.org/cgit/emacs.git/snapshot/emacs-master.tar.gz as
> >> source:
> >
> > That's a different approach from what's in INSTALL.REPO. INSTALL.REPO
> 
> In MSYS2 and other OS there are *-git packages just to have the last 
> development source not because that people aims to develop and maintain 
> the applications of those packages..

I'd urge all those who are tracking development sources to please use
the official established build procedure.  Using 3rd-party packages
whose procedures deviate from the project instructions is susceptible
to bumping into problems that stem from using those deviant
procedures, which is an added maintenance burden I think we'd like to
avoid.  Also, doing so means less testing for the official build
procedures.

If you can convince the MSYS2 maintainers to adopt the official build
procedure, it would be even better.  Failing that, please consider
switching back to what the project recommends, what is documented in
the relevant INSTALL documents.

TIA

Building Emacs on MSYS2 (was: Build failure for Emacs master)

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> In MSYS2 and other OS there are *-git packages just to have the last 
>> development source not because that people aims to develop and maintain 
>> the applications of those packages..
>
> I'd urge all those who are tracking development sources to please use
> the official established build procedure.  Using 3rd-party packages
> whose procedures deviate from the project instructions is susceptible
> to bumping into problems that stem from using those deviant
> procedures, which is an added maintenance burden I think we'd like to
> avoid.  Also, doing so means less testing for the official build
> procedures.

Currently this is the code for configuring the build of emacs-git on
MSYS2 MinGW-packages:

build() {
  [[ -d "${srcdir}/build-${MINGW_CHOST}" ]] && rm -rf "${srcdir}/build-${MINGW_CHOST}"
  mkdir -p "${srcdir}/build-${MINGW_CHOST}"
  cd "build-${MINGW_CHOST}"

  local with_wide_int='no'

  if test "${CARCH}" == 'x86_64'; then
    with_wide_int='yes'
  fi

  CPPFLAGS="-DNDEBUG -isystem ${MINGW_PREFIX}/include"
  CFLAGS="-pipe -O3 -fomit-frame-pointer -funroll-loops"
  LDFLAGS="-s -Wl,-s"
  "${srcdir}/${_realname}/configure" \
    --prefix="${MINGW_PREFIX}" \
    --build="${MINGW_CHOST}" \
    --with-wide-int="${with_wide_int}" \
    --with-sound="yes" \
    --with-file-notification="yes" \
    --without-gpm \
    --without-gconf \
    --without-gsettings \
    --without-selinux

  make
}

Apart from setting with_wide_int and adding some (unnecessary, IMHO)
optimization options, it looks like a fairly standard configuration.

The package contains two patches too. This one that looks like trying to
avoid a link problem:


--- src/image.c.orig	2014-10-15 14:18:29.088716000 +0200
+++ src/image.c	2014-10-15 15:54:12.407522800 +0200
@@ -7862,7 +7862,7 @@
   };
 
 #if defined HAVE_NTGUI && defined WINDOWSNT
-static bool init_imagemagick_functions (void);
+#define init_imagemagick_functions NULL
 #else
 #define init_imagemagick_functions NULL
 #endif



and this one that seems related to locating the source directory:

--- src/lread.c.orig	2014-11-04 20:29:22.129549000 +0100
+++ src/lread.c	2014-11-04 22:33:07.346414100 +0100
@@ -4351,6 +4351,12 @@
             } /* Vinstallation_directory != Vsource_directory */
 
         } /* if Vinstallation_directory */
+      else
+        {
+          Vsource_directory
+            = Fexpand_file_name (build_string ("../"),
+                                 Fcar (decode_env_path (0, PATH_DATA, 0)));
+        }
     }
   else                          /* !initialized */
     {


> If you can convince the MSYS2 maintainers to adopt the official build
> procedure, it would be even better.

I can change the emacs-git package for not adding those optimization
options and not setting with-wide-int. Do you think that's enough?

> Failing that, please consider
> switching back to what the project recommends, what is documented in
> the relevant INSTALL documents.

Because MSYS2 does not distribute binaries for emacs-git, I guess that
the number of people who currently uses the PKGBUILD shown above is very
small. AFAIK Angelo and others that build Emacs on MSYS2 are not using
the PKGBUILD, but following the recipe on the Emacs' docs (possibly with
their own personal modifications.)

Re: Building Emacs on MSYS2 (was: Build failure for Emacs master)

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Thu, 14 Apr 2016 17:58:09 +0200
> 
> Currently this is the code for configuring the build of emacs-git on
> MSYS2 MinGW-packages:
> 
> build() {
>   [[ -d "${srcdir}/build-${MINGW_CHOST}" ]] && rm -rf "${srcdir}/build-${MINGW_CHOST}"
>   mkdir -p "${srcdir}/build-${MINGW_CHOST}"
>   cd "build-${MINGW_CHOST}"
> 
>   local with_wide_int='no'
> 
>   if test "${CARCH}" == 'x86_64'; then
>     with_wide_int='yes'
>   fi
> 
>   CPPFLAGS="-DNDEBUG -isystem ${MINGW_PREFIX}/include"
>   CFLAGS="-pipe -O3 -fomit-frame-pointer -funroll-loops"
>   LDFLAGS="-s -Wl,-s"
>   "${srcdir}/${_realname}/configure" \
>     --prefix="${MINGW_PREFIX}" \
>     --build="${MINGW_CHOST}" \
>     --with-wide-int="${with_wide_int}" \
>     --with-sound="yes" \
>     --with-file-notification="yes" \
>     --without-gpm \
>     --without-gconf \
>     --without-gsettings \
>     --without-selinux
> 
>   make
> }
> 
> Apart from setting with_wide_int and adding some (unnecessary, IMHO)
> optimization options, it looks like a fairly standard configuration.

Actually, I see nothing standard at all here.  I see no reason for
_any_ of the options, neither in CPPFLAGS nor in CFLAGS.  They are all
potential source of trouble for the uninitiated.  (If there are real
reasons for them, they must be bugs that should be reported and fixed
upstream.)  And why "-s" in LDFLAGS? that's just hostile to
developers, since no user can possibly provide any details about any
bugs.  (Of course, this is in line with -fomit-frame-pointer, which is
also a killer for any attempts to debug.)  And all the switches to
'configure', with the single exception of --prefix (assuming that it
has the correct /d/foo/bar form and points to the MinGW directory, not
to MSYS2 directory) are simply clutter, they are no-ops at best and
potential trouble at worst.

Bottom line, I really don't like this script.

> The package contains two patches too. This one that looks like trying to
> avoid a link problem:
> 
> 
> --- src/image.c.orig	2014-10-15 14:18:29.088716000 +0200
> +++ src/image.c	2014-10-15 15:54:12.407522800 +0200
> @@ -7862,7 +7862,7 @@
>    };
>  
>  #if defined HAVE_NTGUI && defined WINDOWSNT
> -static bool init_imagemagick_functions (void);
> +#define init_imagemagick_functions NULL
>  #else
>  #define init_imagemagick_functions NULL
>  #endif

What link problem is that?  Why those who use the official procedure
never have or report it?

> and this one that seems related to locating the source directory:
> 
> --- src/lread.c.orig	2014-11-04 20:29:22.129549000 +0100
> +++ src/lread.c	2014-11-04 22:33:07.346414100 +0100
> @@ -4351,6 +4351,12 @@
>              } /* Vinstallation_directory != Vsource_directory */
>  
>          } /* if Vinstallation_directory */
> +      else
> +        {
> +          Vsource_directory
> +            = Fexpand_file_name (build_string ("../"),
> +                                 Fcar (decode_env_path (0, PATH_DATA, 0)));
> +        }
>      }
>    else                          /* !initialized */
>      {

What problem does this try to fix, and why?

> I can change the emacs-git package for not adding those optimization
> options and not setting with-wide-int. Do you think that's enough?

I think this should simply invoke the commands shown in
nt/INSTALL.W64, and that's it.  IOW, it should run the official
procedure, and if there are reasons to change that, those reasons
should be reported and discussed.

> > Failing that, please consider
> > switching back to what the project recommends, what is documented in
> > the relevant INSTALL documents.
> 
> Because MSYS2 does not distribute binaries for emacs-git, I guess that
> the number of people who currently uses the PKGBUILD shown above is very
> small.

I have similar issues with the MSYS2 procedure for building official
releases.

Thanks.