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 from a new MinGW environment Date: Mon, 16 Sep 2013 20:37:56 +0300 Message-ID: <83txhkpszv.fsf@gnu.org> References: <83sixwfdjk.fsf@gnu.org> <834n9nhhp6.fsf@gnu.org> <83ppsbfoe7.fsf@gnu.org> <83mwnffkom.fsf@gnu.org> <83k3ijfhk0.fsf@gnu.org> <83hadnf7gs.fsf@gnu.org> <83hadmqvql.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1379353094 9409 80.91.229.3 (16 Sep 2013 17:38:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 16 Sep 2013 17:38:14 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dani Moncayo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 16 19:38:17 2013 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 1VLckb-0007V6-0Z for ged-emacs-devel@m.gmane.org; Mon, 16 Sep 2013 19:38:17 +0200 Original-Received: from localhost ([::1]:36529 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VLcka-0004EU-Ku for ged-emacs-devel@m.gmane.org; Mon, 16 Sep 2013 13:38:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45766) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VLckS-0004ED-0X for emacs-devel@gnu.org; Mon, 16 Sep 2013 13:38:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VLckM-0002cE-40 for emacs-devel@gnu.org; Mon, 16 Sep 2013 13:38:07 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:47448) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VLckL-0002c9-SL for emacs-devel@gnu.org; Mon, 16 Sep 2013 13:38:02 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MT800000B5SLH00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Mon, 16 Sep 2013 20:38:00 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MT800015BNBIJ60@a-mtaout22.012.net.il>; Mon, 16 Sep 2013 20:38:00 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.172 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:163371 Archived-At: > Date: Mon, 16 Sep 2013 18:48:24 +0200 > From: Dani Moncayo > Cc: Emacs development discussions > > >> Configured for `i686-pc-mingw32'. > >> > >> Where should the build process find the source code? /home/dani/emacs/emacs.git > > > > No, this is already wrong: the source directory should be something > > like /c/msys/home/dani/emacs/emacs.git, i.e. the full Windows file > > name in MSYS format. Something is still not working correctly. > > Mmm, but I don't see what wrong with a path like > "/home/dani/whatever". It is a perfectly legitimate MSYS path (like > "/c/msys/home/dani/whatever" or "c:/msys/home/dani/whatever"), isn't > it? It is, as long as it is used by MSYS programs. But it is not legitimate when it is passed to MinGW Emacs, because Emacs will not find this directory. Which is exactly what happens in your case. > Why that should be the culprit of the lack of expansion of "%emacs_dir%"? Expansion of %emacs_dir% is not the issue here, contrary to what I originally thought and wrote. The issue is that temacs does not find the etc directory where it should, because temacs is a MinGW program, and doesn't know about the MSYS '/' magic. That is why MSYS file names such as /home/dani/whatever should never end up in src/epaths.h. > > The configure script computes the source directory in a fragment that > > starts with this comment: > > > > # Find the source files, if location was not specified. > > > > Perhaps add 'echo' there in strategical places to see what is not > > working, and why. > > At the end of that fragment (which begins with "# Find the source > files, if location was not specified."), srcdir holds "../emacs.git". > And looking at the configure script, I think that the fragment > responsible for making that path absolute is a bit later in the file. > It is a fairly simple and short fragment which begins with "#### Make > srcdir absolute, if it isn't already.". I've seen that, after that > second fragment, "srcdir" holds its definitive value: > "/home/dani/emacs/emacs.git". > > If you look at that code, you'll see that the "srcdir" variable can be > updated with either (a) the output of the "pwd" or (b) the contents of > the PWD variable. But if I try those options in my MSYS bash, both > give me the same MSYS path "/home/dani/emacs/emacs.git". In my case, pwd gives an absolute /d/foo/bar file name. It does that even if I chdir to a directory below the MSYS root, _provided_ that I use an absolute file name when I chdir (/usr is mounted on D:/usr/MSYS in my case): $ cd /d/usr/MSYS && pwd /d/usr/MSYS $ cd /usr && pwd /usr > Perhaps the key factor here is the fact that, in my case, the > directory holding the source code is inside the MSYS tree (under my > MSYS "home" directory). Are you saying that the previous builds, which worked, were not under the MSYS home directory? If they were, then why the builds started failing? > I guess that in your case that directory is outside the MSYS tree, > so that its absolute path in MSYS has necessarily the form > "/X/some/dir" (where X is the letter of some windows drive). Yes, I build outside of the MSYS hierarchy. But does this explain why your builds stopped working after whatever happened to your MinGW installation?