From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: Building Emacs on MSYS2 Date: Thu, 14 Apr 2016 18:43:08 +0200 Message-ID: <87ziswxhsz.fsf@wanadoo.es> References: <56CCD91E.6070507@alice.it> <83egc2ixji.fsf@gnu.org> <56CD798D.7060102@alice.it> <56CD8408.1000701@alice.it> <83wppuggb4.fsf@gnu.org> <56CE2CA7.5050906@alice.it> <83io1cg2pt.fsf@gnu.org> <56DA0327.2030009@alice.it> <83oaatxu72.fsf@gnu.org> <570C4307.6050907@alice.it> <83k2k2g82s.fsf@gnu.org> <570EA823.1010404@alice.it> <570EBADD.2060604@cs.ucla.edu> <570EC198.5090407@alice.it> <570EF300.3050104@cs.ucla.edu> <570F4EC7.3060403@alice.it> <83twj4dx7q.fsf@gnu.org> <878u0gyyge.fsf_-_@wanadoo.es> <83shyodv56.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1460652224 24905 80.91.229.3 (14 Apr 2016 16:43:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 14 Apr 2016 16:43:44 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 14 18:43:35 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aqkMh-0002NO-5b for ged-emacs-devel@m.gmane.org; Thu, 14 Apr 2016 18:43:35 +0200 Original-Received: from localhost ([::1]:42943 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqkMg-0004Oz-MH for ged-emacs-devel@m.gmane.org; Thu, 14 Apr 2016 12:43:34 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56382) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqkMS-0004ML-J4 for emacs-devel@gnu.org; Thu, 14 Apr 2016 12:43:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aqkMP-0003JO-Ba for emacs-devel@gnu.org; Thu, 14 Apr 2016 12:43:20 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:60677) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqkMP-0003J0-26 for emacs-devel@gnu.org; Thu, 14 Apr 2016 12:43:17 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1aqkMN-0002C2-AU for emacs-devel@gnu.org; Thu, 14 Apr 2016 18:43:15 +0200 Original-Received: from 120.red-88-22-75.staticip.rima-tde.net ([88.22.75.120]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 14 Apr 2016 18:43:15 +0200 Original-Received: from ofv by 120.red-88-22-75.staticip.rima-tde.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 14 Apr 2016 18:43:15 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 113 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 120.red-88-22-75.staticip.rima-tde.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.92 (gnu/linux) Cancel-Lock: sha1:TS/jAs606kbvYSXacgEJz/uPvHk= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:202920 Archived-At: Eli Zaretskii writes: >> 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.) The MSYS2 packages (as well as the Arch Linux packages which serves as models) are intended for use on production, not for debugging. OTOH, PKGBUILDs are supposed to have code for choosing debug builds if the user passes certain flags to the build tool. This specific PKGBUILD lacks that code. Adding it is not difficult. > 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) Of course, the MinGW hierarchy is used. > are simply clutter, they are no-ops at best and > potential trouble at worst. I guess those came from the Arch Linux package that served as model. OTOH is a good practice to explicitly state "I have this feature so use it". The MSYS2 build procedure already makes sure that the dependencies are installed, so if something is not properly detected by the configure script, it is a good thing to error out. Most of the listed options on that PKGBUILD are not related to this, though. > 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? I have no idea. Probably imagemagick, as built and distributed by MSYS2, does not have or need that feature. >> 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? Just guessing: the post-build install directory is not the same as the directory used for running Emacs (after running `make install', the resulting files are packaged, stored and distributed by the project; then users unpackage in their own installs; it's like doing `make install' and the moving the install directory elsewhere.) >> 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. Some modifications may be unavoidable due to how MSYS2 works (see above) but I agree with the sentiment. >> > 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. The idea is to put emacs-git on good shape and, when emacs 25 is released, port the modifications to the stable MSYS emacs PKGBUILD.