|Do you know where your variables are?|
Re: Ideas on more foolproof Makefile.PL and generated Makefileby bojinlund (Vicar)
|on Mar 22, 2012 at 14:33 UTC||Need Help??|
This is so far I have come.
Problems calling dmake from within Emacs
Emacs in Windows replaces at start up the environment variable SHELL to something like "C:/Program Files (x86)/GNU Emacs 23.4/bin/cmdproxy.exe". Processes started by Emacs will inherit this value.
Starting dmake from within emacs results in that dmake uses the cmdproxy.exe as shell. The logic in the start-up files of dmake (when SHELL is "C:/Program Files (x86)/GNU Emacs 23.4/bin/cmdproxy.exe") configure dmake for using a Kornshell compatible shell.
Cmdproxy.exe sometimes does not like all the arguments and issues messages like "warning: extra args ignored after '-e'". It also truncates the command. The results of using cmdproxy.exe as SHELL are unexpected and errors are difficult to find. Sometimes the Windows command shell is started in interactive mode and the action initiated by (compile "dmake" nil) is stuck.
I have filed a bug: http://lists.gnu.org/archive/html/bug-gnu-emacs/2012-03/msg00178.html. The bug report has been left without action.
Runtime check in generated Makefile
Have learnt that ExtUtils::MakeMaker has limited GNU Make support on Windows. See also: http://lists.gnu.org/archive/html/help-make/2012-03/msg00047.html
I have tried to find "portable" makefile idioms to:
Example of Makefile idiom to find which make program is used are:
To generate an error message and stop GNU Make is straight forward:
I have not found any better way to give a message and stop dmake than: