emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Building Emacs from a new MinGW environment


From: Eli Zaretskii
Subject: Re: Building Emacs from a new MinGW environment
Date: Mon, 16 Sep 2013 20:37:56 +0300

> Date: Mon, 16 Sep 2013 18:48:24 +0200
> From: Dani Moncayo <address@hidden>
> Cc: Emacs development discussions <address@hidden>
> 
> >>   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?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]