From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Building Emacs on MSYS2 Date: Thu, 14 Apr 2016 20:35:56 +0300 Message-ID: <83lh4gdrer.fsf@gnu.org> 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> <87ziswxhsz.fsf@wanadoo.es> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1460655409 14478 80.91.229.3 (14 Apr 2016 17:36:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 14 Apr 2016 17:36:49 +0000 (UTC) Cc: emacs-devel@gnu.org To: =?iso-8859-1?Q?=D3scar?= Fuentes Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 14 19:36:44 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 1aqlC6-000676-9B for ged-emacs-devel@m.gmane.org; Thu, 14 Apr 2016 19:36:42 +0200 Original-Received: from localhost ([::1]:43715 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqlC5-0001Ca-OI for ged-emacs-devel@m.gmane.org; Thu, 14 Apr 2016 13:36:41 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45504) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqlBp-00019i-VX for emacs-devel@gnu.org; Thu, 14 Apr 2016 13:36:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aqlBl-0005U9-4I for emacs-devel@gnu.org; Thu, 14 Apr 2016 13:36:25 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53486) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqlBl-0005U0-1P; Thu, 14 Apr 2016 13:36:21 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1219 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aqlBk-0007kq-8N; Thu, 14 Apr 2016 13:36:20 -0400 In-reply-to: <87ziswxhsz.fsf@wanadoo.es> (message from =?iso-8859-1?Q?=D3s?= =?iso-8859-1?Q?car?= Fuentes on Thu, 14 Apr 2016 18:43:08 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:202926 Archived-At: > From: Óscar Fuentes > Date: Thu, 14 Apr 2016 18:43:08 +0200 > > 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. We are talking about building the development snapshots. It is IMO silly to build those without debugging info. > 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. Development snapshots are best compiled with debugging info (and with "--enable-checking" as well, btw). > > 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. I wonder why someone might think that copying configure-time option from a totally different OS could be a good idea. Why not ask here instead? > OTOH is a good practice to explicitly state "I have this feature so use > it". Emacs can do that without these switches, see system-configuration-features. > 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. None of them are related to this, actually. > >> --- 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.) This kind of problem (if it indeed is it) should be fixed in site-init.el files, not by patching sources. > >> > 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. That's not what I meant, I meant the argument about the small number of people who use this script. I don't think it's small, because the same problems are in building the official releases.