I have been using Console2 on an MS Windows box to compile and would like to use Emacs instead. My settings on Console2 are as follows:

shell="c:/mingw/bin/sh.exe --login -i -c 'cd /c/docume~1/admini~1/desktop/;export PATH=/c/mingw/bin:/c/progra~1/git/bin; exec /bin/sh'"


Q:  How can I configure Emacs to use the MinGW stuff from above so that I can run a command such as (compile "make") in Emacs on a Windows platform?

The following snippet renders an error when trying to compile Emacs from source: "cmdproxy.exe has encountered a problem and needs to close. We are sorry for the inconvenience."

(defun xp-compile ()
(let ((default-directory (w32-short-file-name
                          "c:/Documents and Settings/Administrator/Desktop/emacs"))
      (compilation-environment "PATH=/c/mingw/bin:/c/progra~1/git/bin"))
  (compile "make")))


  • You ensure ‘exec-path’ contains paths to all executables needed; that ‘process-environment’ contains all environment variables needed (via e.g. ‘setenv’); then set ‘compile-command’ as ‘cd <path> && make’ and call M-x compile. Is this what you were asking? – InHarmsWay Mar 13 '19 at 11:12
  • @InHarmsWay -- Thank you for reading and responding to this particular thread. I am familiar with setting the process-environment variable and generally like to do so on a let-bound basis when calling a custom version of start-process (which calls make-process ...). In the context of this particular question, I am unsure whether I need sh.exe --login -i -c to be able to compile using Emacs on a Windows platform and/or whether I also need exec /bin/sh somewhere in the setup; and, if I need those, then where/how to configure that ...? – lawlist Mar 13 '19 at 14:04
  • @InHarmsWay -- I have updated the question with a screenshot and sample function which generates the following error when trying to compile Emacs from source: "cmdproxy.exe has encountered a problem and needs to close. We are sorry for the inconvenience." – lawlist Mar 13 '19 at 14:34
  • PATH on windows uses ; as separator, for one thing. Other than that, have you tried simple commands as dummy compile-command’s, like pwd or echo %PATH%, as a means of sanity-checking the shell? – InHarmsWay Mar 13 '19 at 14:37

The following example sets the shell-file-name to the absolute path of the sh.exe executable. Without that setting, cmdproxy.exe will complain as depicted in the screenshot in the question above.

The default-directory is hard-coded for the sake of creating a minimal working example.

Inasmuch as MinGW uses Unix flavor PATH separators, this example uses colons instead of semicolons.

The process-environment (containing a custom PATH for MinGW and Git executables) is set on a temporary basis for the duration of the function, which is simply a personal preference.

The following approach is based upon the helpful comments of @npostavs below, which suggested a simplification of the alternative answer such that the existing value of PATH will be shadowed by a user-specified path.

(defun mingw-compile (command)
(let* ((shell-file-name "c:/mingw/bin/sh.exe")
       (default-directory (w32-short-file-name
         "c:/Documents and Settings/Administrator/Desktop/emacs/"))
       (mingw+git "/c/mingw/bin:/c/progra~1/git/bin")
       (process-environment (cons (concat "PATH=" mingw+git) process-environment)))
  (compile command)))

Alternative approach that does not shadow the existing PATH and instead replaces it entirely on a temporary basis:

(defun mingw-compile (command)
(let* ((shell-file-name "c:/mingw/bin/sh.exe")
       (default-directory (w32-short-file-name
         "c:/Documents and Settings/Administrator/Desktop/emacs/"))
       (mingw+git "/c/mingw/bin:/c/progra~1/git/bin")
       ;; (path (concat (getenv "PATH") ":" mingw+git))
       (temp (mapcar 'concat process-environment))
       (newenv (setenv-internal temp "PATH" mingw+git t))
       (process-environment newenv))
  (compile command)))
  • You can bind process-environment to (cons (concat "PATH=" mingw+git) process-environment) instead of the last 3 let-bindings. – npostavs Mar 14 '19 at 1:43
  • @npostavs -- When you have time, could please help me understand what happens if we use (cons (concat "PATH=" mingw+git) process-environment)? On a Windows box, I saw stuff in the default PATH that MinGW would not be interested in using; e.g., "C:\\Program Files\\Parallels\\Parallels Tools\\Applications;C:\\WINDOWS\\system32;C:\\WINDOWS;C:\\WINDOWS\\System32\\Wbem;C:\\WINDOWS\\WestLCFs". I wanted to eliminate those inapplicable paths from the MinGW build process. Does your suggested edit place the desired paths in front of the list such that the latter is effectively shadowed? – lawlist Mar 14 '19 at 3:20
  • Only the first "PATH=..." entry in process-environment gets used, so yes, my suggestion will shadow any existing value of PATH. – npostavs Mar 14 '19 at 10:24
  • @npostavs -- Thank you for the explanation of the suggested edit. I have edited the answer above to include your suggestion as the primary answer. – lawlist Mar 14 '19 at 16:07
  • Oh, I misunderstood what you meant by "shadowed". In fact, both alternatives have the same effect: to replace the value of PATH over the scope of the let body. My suggestion was just to shorten your code a bit. – npostavs Mar 14 '19 at 21:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.