http://qs321.pair.com?node_id=954865

Background

I am used to "live" in emacs. Adding the line  # (compile (concat "perl " (buffer-name)) nil) in a Perl scripts, makes it is easy to run the script in emacs. The script can be run by putting the cursor at the end of the line and typing C-x C-e (runs the emacs command eval-last-sexp).

I had some problems with Padre, the Perl IDE, by running 

(compile "perl Makefile.PL" nil)

(compile "make" nil)

[download]
Running make resulted in the error message: 
to undefined at C:/Dwimperl/perl/lib/ExtUtils/Install.pm line 1208
make: *** [pm_to_blib] Error 2

[download]

Understood after some work that the problem was "{{@ARGV}}" in the Makefile: 

pm_to_blib : $(FIRST_MAKEFILE) $(TO_INST_PM)
    $(NOECHO) $(ABSPERLRUN) -MExtUtils::Install -e "pm_to_blib({{@ARGV
+}}, '$(INST_LIB)\auto', q[$(PM_FILTER)], '$(PERM_DIR)')" -- \
      lib/Padre/Wx/Scintilla.pm blib\lib\Padre\Wx\Scintilla.pm \

[download]
Changed  {{@ARGV}} to  {@ARGV} and could run make without problems. Tried to find the real problem.

Realized after some days, when I saw  # dmake expands {{ to { and }} to }. in the file perl/lib/ExtUtils/MM_Win32.pm that I should have used dmake!!

However calling dmake from emacs hangs.

The end of the output from (compile "dmake -v -f Makefile" nil), followed by kill-compilation is: 

dmake:  Updating [config], (1 > 0)
C:\Dwimperl\perl\bin\perl.exe "-Iinc" -MExtUtils::Command -e mkpath --
+ "blib\lib\auto\share\dist\Padre\."
warning: extra args ignored after '-e'
Terminating on signal SIGINT(2)
C:\Dwimperl\perl\bin\perl.exe "-Iinc" -MExtUtils::Command -e chmod -- 
+755 "blib\lib\auto\share\dist\Padre\."
dmake:  C:\Dwimperl\c\bin\startup\config.mk:  line 1:  Warning: -- Mac
+ro `OS' redefined after use
dmake:  C:\Dwimperl\c\bin\startup\startup.mk:  line 142:  Warning: -- 
+More than one prerequisite
for %-target. Use :| ruleop or indirect prerequisites.
dmake:  C:\Dwimperl\c\bin\startup\startup.mk:  line 146:  Warning: -- 
+More than one prerequisite
for %-target. Use :| ruleop or indirect prerequisites.
dmake:  Makefile:  line 1201:  Warning: -- The .SUFFIXES target has no
+ special meaning and is deprecated.
Caught SIGINT. Trying to quit ...
dmake:  Warning: -- Internal Warning: finished pid 64 is not in pq!?
dmake:  Error code 130, while making 'config'

Compilation interrupt at Sun Feb 19 09:06:15

[download]
Any ideas why it sticks?

Proposal: Comment in generated Makefile

The generated Makefile should start with a comment indicating how it was created and the intended usage. 

# This Makefile is generated by the Makefile.PL. To use this file run:
# dmake (prepares the installation)
# dmake test (tests the prepared install)
# dmake install (performs the installation)

[download]

Proposal: Command line option --help for Makefile.PL

A Makefile.PL should at least support an option to get basic help. This help could include which other command line options are supported, what is generated by it and how to used the generated Makefile.

Proposal: Runtime check in generated Makefile

To avoid mistakes using wrong make program, runtime tests are included in the generated makefile.

This is a first draft how it could be implemented in a file for dmake: 


# Makefile intended for dmake

ifneq "{xxx}" "xxx"
# "{xxx}" and "xxx" is equal in dmake 
$(info  Warning: This is a makefile for dmake)
$(error Error: This is a makefile for dmake)
endif

all:
    @echo OK

[download]
and a file for (gnu)make: 

# Makefile intended for (gnu)make

all:
# "{xxx}" and "xxx" is equal in dmake 
ifeq "{xxx}" "xxx"
    @echo ERROR: This makefile is NOT for dmake
    I_DO_NOT_KNOW_HOW_TO_GENERTE_AN_ERROR
endif
    @echo 'OK'

[download]

Proposal: Debug support in Makefile.PL

It had been nice with some easy to activate debug support in the Makefile.PL.

Error messages often comes without context. A by command line option activated more verbose output could give indication of the source of an error message.

Replies are listed 'Best First'.
Re: Ideas on more foolproof Makefile.PL and generated Makefile
by JavaFan (Canon) on Feb 19, 2012 at 17:13 UTC
    You probably have more success in getting your wishes implemented, if you write patches which do the things you want, and send them to Schwern, the current maintainer of ExtUtils::MakeMaker.

    After all, your list of proposals are your itches that need scratching.

[reply]
Re: Ideas on more foolproof Makefile.PL and generated Makefile
by bojinlund (Monsignor) on Mar 22, 2012 at 14:33 UTC

    Hej!

    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:

    • Find which make program is used
    • Give an error message and stop the make program
    Portable means here they can be used by many make programs like GNU Make, dmake, nmake and more.

    Example of Makefile idiom to find which make program is used are: 

    ifeq "{xxx}" "xxx"
MAKE_USED = dmake
endif

ifneq "$(.VARIABLES)" ""
MAKE_USED = gnumake
endif

#if... How can nmake be identified?
#MAKE_USED = nmake
#endif

    [download]

    To generate an error message and stop GNU Make is straight forward: 

    NORL =@# No Output of Recipe Line
.PHONY: check_used_make_program

check_used_make_program:
ifeq "$(MAKE_USED)" "gnumake"
    $(NORL)$(error ERROR: Using $(MAKE_USED) for a Makefile intended f
+or ?make)
endif

    [download]
    I have not found any better way to give a message and stop dmake than: 
    ifeq "$(MAKE_USED)" "dmake"
#               The message is NOT sent to STDERR
    $(NORL)echo ERROR: Using $(MAKE_USED) for a Makefile intended for 
+?make
    $(assign ERR OR = ERROR) #Generates an error message
endif

    [download]

[reply]
[d/l]
[select]
Re: Ideas on more foolproof Makefile.PL and generated Makefile
by bulk88 (Priest) on Mar 22, 2012 at 18:39 UTC
    Turning on symbols/debugging no -O flags is very hard (but I am able to do it) on Perl XS libraries. A couple XS Libs use GetOpt for settings.
[reply]
Re: Ideas on more foolproof Makefile.PL and generated Makefile
by educated_foo (Vicar) on Feb 21, 2012 at 04:55 UTC
    Despite SawyerX's endless propaganda, if you already know Emacs, there's no reason to play with "P****, the P*** I**."
[reply]

      Despite SawyerX's endless propaganda, if you already know Emacs, there's no reason to play with "P****, the P*** I**."

      What does that even mean?

[reply]
[reply]

Back to Meditations