* Building Emacs on MSYS2 (was: Build failure for Emacs master)
@ 2016-04-14 19:56 Angelo Graziosi
2016-04-14 19:59 ` Eli Zaretskii
0 siblings, 1 reply; 4+ messages in thread
From: Angelo Graziosi @ 2016-04-14 19:56 UTC (permalink / raw
To: ofv, Emacs developers
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}
}
[...]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Build failure for Emacs master
@ 2016-02-23 22:11 Angelo Graziosi
2016-02-24 3:42 ` Eli Zaretskii
0 siblings, 1 reply; 4+ messages in thread
From: Angelo Graziosi @ 2016-02-23 22:11 UTC (permalink / raw
To: Emacs developers
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Build failure for Emacs master
2016-02-23 22:11 Build failure for Emacs master Angelo Graziosi
@ 2016-02-24 3:42 ` Eli Zaretskii
2016-02-24 9:36 ` Angelo Graziosi
0 siblings, 1 reply; 4+ messages in thread
From: Eli Zaretskii @ 2016-02-24 3:42 UTC (permalink / raw
To: Angelo Graziosi; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Build failure for Emacs master
2016-02-24 3:42 ` Eli Zaretskii
@ 2016-02-24 9:36 ` Angelo Graziosi
2016-02-24 10:20 ` Angelo Graziosi
0 siblings, 1 reply; 4+ messages in thread
From: Angelo Graziosi @ 2016-02-24 9:36 UTC (permalink / raw
To: Eli Zaretskii; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Build failure for Emacs master
2016-02-24 9:36 ` Angelo Graziosi
@ 2016-02-24 10:20 ` Angelo Graziosi
2016-02-24 17:37 ` Eli Zaretskii
0 siblings, 1 reply; 4+ messages in thread
From: Angelo Graziosi @ 2016-02-24 10:20 UTC (permalink / raw
To: Eli Zaretskii; +Cc: emacs-devel
Il 24/02/2016 10:36, Angelo Graziosi ha scritto:
>
> Let's see what happen with another try..
>
Indeed, just retrying builds OB..
>
> Angelo
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Build failure for Emacs master
2016-02-24 10:20 ` Angelo Graziosi
@ 2016-02-24 17:37 ` Eli Zaretskii
2016-02-24 22:20 ` Angelo Graziosi
0 siblings, 1 reply; 4+ messages in thread
From: Eli Zaretskii @ 2016-02-24 17:37 UTC (permalink / raw
To: Angelo Graziosi; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Build failure for Emacs master
2016-02-24 17:37 ` Eli Zaretskii
@ 2016-02-24 22:20 ` Angelo Graziosi
2016-02-25 16:43 ` Eli Zaretskii
0 siblings, 1 reply; 4+ messages in thread
From: Angelo Graziosi @ 2016-02-24 22:20 UTC (permalink / raw
To: Eli Zaretskii; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Build failure for Emacs master
2016-02-24 22:20 ` Angelo Graziosi
@ 2016-02-25 16:43 ` Eli Zaretskii
2016-03-04 21:50 ` Angelo Graziosi
0 siblings, 1 reply; 4+ messages in thread
From: Eli Zaretskii @ 2016-02-25 16:43 UTC (permalink / raw
To: Angelo Graziosi; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Build failure for Emacs master
2016-02-25 16:43 ` Eli Zaretskii
@ 2016-03-04 21:50 ` Angelo Graziosi
2016-03-05 7:25 ` Eli Zaretskii
0 siblings, 1 reply; 4+ messages in thread
From: Angelo Graziosi @ 2016-03-04 21:50 UTC (permalink / raw
To: Emacs developers
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.
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Build failure for Emacs master
2016-03-04 21:50 ` Angelo Graziosi
@ 2016-03-05 7:25 ` Eli Zaretskii
2016-04-12 0:36 ` Angelo Graziosi
0 siblings, 1 reply; 4+ messages in thread
From: Eli Zaretskii @ 2016-03-05 7:25 UTC (permalink / raw
To: Angelo Graziosi; +Cc: emacs-devel
> 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?
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Build failure for Emacs master
2016-03-05 7:25 ` Eli Zaretskii
@ 2016-04-12 0:36 ` Angelo Graziosi
2016-04-12 15:28 ` Eli Zaretskii
0 siblings, 1 reply; 4+ messages in thread
From: Angelo Graziosi @ 2016-04-12 0:36 UTC (permalink / raw
To: Eli Zaretskii; +Cc: emacs-devel
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?
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Build failure for Emacs master
2016-04-12 0:36 ` Angelo Graziosi
@ 2016-04-12 15:28 ` Eli Zaretskii
2016-04-13 20:12 ` Angelo Graziosi
0 siblings, 1 reply; 4+ messages in thread
From: Eli Zaretskii @ 2016-04-12 15:28 UTC (permalink / raw
To: Angelo Graziosi; +Cc: emacs-devel
> 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?
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Build failure for Emacs master
2016-04-12 15:28 ` Eli Zaretskii
@ 2016-04-13 20:12 ` Angelo Graziosi
2016-04-13 21:32 ` Paul Eggert
0 siblings, 1 reply; 4+ messages in thread
From: Angelo Graziosi @ 2016-04-13 20:12 UTC (permalink / raw
To: emacs-devel
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Build failure for Emacs master
2016-04-13 20:12 ` Angelo Graziosi
@ 2016-04-13 21:32 ` Paul Eggert
2016-04-13 22:00 ` Angelo Graziosi
0 siblings, 1 reply; 4+ messages in thread
From: Paul Eggert @ 2016-04-13 21:32 UTC (permalink / raw
To: Angelo Graziosi; +Cc: Emacs development discussions
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Build failure for Emacs master
2016-04-13 21:32 ` Paul Eggert
@ 2016-04-13 22:00 ` Angelo Graziosi
2016-04-14 1:31 ` Paul Eggert
0 siblings, 1 reply; 4+ messages in thread
From: Angelo Graziosi @ 2016-04-13 22:00 UTC (permalink / raw
To: Paul Eggert; +Cc: Emacs development discussions
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Build failure for Emacs master
2016-04-13 22:00 ` Angelo Graziosi
@ 2016-04-14 1:31 ` Paul Eggert
2016-04-14 8:03 ` Angelo Graziosi
0 siblings, 1 reply; 4+ messages in thread
From: Paul Eggert @ 2016-04-14 1:31 UTC (permalink / raw
To: Angelo Graziosi; +Cc: Emacs development discussions
[-- 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
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: Build failure for Emacs master
2016-04-14 1:31 ` Paul Eggert
@ 2016-04-14 8:03 ` Angelo Graziosi
2016-04-14 15:30 ` Eli Zaretskii
0 siblings, 1 reply; 4+ messages in thread
From: Angelo Graziosi @ 2016-04-14 8:03 UTC (permalink / raw
To: Paul Eggert; +Cc: Emacs development discussions
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..
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Build failure for Emacs master
2016-04-14 8:03 ` Angelo Graziosi
@ 2016-04-14 15:30 ` Eli Zaretskii
2016-04-14 15:58 ` Building Emacs on MSYS2 (was: Build failure for Emacs master) Óscar Fuentes
0 siblings, 1 reply; 4+ messages in thread
From: Eli Zaretskii @ 2016-04-14 15:30 UTC (permalink / raw
To: Angelo Graziosi; +Cc: eggert, emacs-devel
> 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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Building Emacs on MSYS2 (was: Build failure for Emacs master)
2016-04-14 15:30 ` Eli Zaretskii
@ 2016-04-14 15:58 ` Óscar Fuentes
2016-04-14 16:15 ` Eli Zaretskii
0 siblings, 1 reply; 4+ messages in thread
From: Óscar Fuentes @ 2016-04-14 15:58 UTC (permalink / raw
To: emacs-devel
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.)
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Building Emacs on MSYS2 (was: Build failure for Emacs master)
2016-04-14 15:58 ` Building Emacs on MSYS2 (was: Build failure for Emacs master) Óscar Fuentes
@ 2016-04-14 16:15 ` Eli Zaretskii
0 siblings, 0 replies; 4+ messages in thread
From: Eli Zaretskii @ 2016-04-14 16:15 UTC (permalink / raw
To: Óscar Fuentes; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2016-04-14 19:59 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-04-14 19:56 Building Emacs on MSYS2 (was: Build failure for Emacs master) Angelo Graziosi
2016-04-14 19:59 ` Eli Zaretskii
-- strict thread matches above, loose matches on Subject: below --
2016-02-23 22:11 Build failure for Emacs master Angelo Graziosi
2016-02-24 3:42 ` Eli Zaretskii
2016-02-24 9:36 ` Angelo Graziosi
2016-02-24 10:20 ` Angelo Graziosi
2016-02-24 17:37 ` Eli Zaretskii
2016-02-24 22:20 ` Angelo Graziosi
2016-02-25 16:43 ` Eli Zaretskii
2016-03-04 21:50 ` Angelo Graziosi
2016-03-05 7:25 ` Eli Zaretskii
2016-04-12 0:36 ` Angelo Graziosi
2016-04-12 15:28 ` Eli Zaretskii
2016-04-13 20:12 ` Angelo Graziosi
2016-04-13 21:32 ` Paul Eggert
2016-04-13 22:00 ` Angelo Graziosi
2016-04-14 1:31 ` Paul Eggert
2016-04-14 8:03 ` Angelo Graziosi
2016-04-14 15:30 ` Eli Zaretskii
2016-04-14 15:58 ` Building Emacs on MSYS2 (was: Build failure for Emacs master) Óscar Fuentes
2016-04-14 16:15 ` 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.