in reply to let Makefile.PL to do the Readme file for me -- new target?

MY::postamble is a fixed name? Both the class MY and the postamble name are fixed? I tried different names and it always complains: dmake: Error: -- Don't know how to make `customname' Cannot the creation of the Readme integrated inside make dist or other similar steps?

MY::postamble is a fixed name. But the target name inside that postamble is not fixed, and there can actually be more than one.

sub MY::postamble { return <<'MAKE_README'; postamble :: $(PERLRUN) -MPod::Text \ -e "Pod::Text->new (sentence => 1, width => 78)->parse_from_file( +qw( $(TO_INST_PM) Readme) );" another_target :: $(PERLRUN) -MPod::Text \ -e "Pod::Text->new (sentence => 1, width => 78)->parse_from_file( +qw( $(TO_INST_PM) Readme) );" third :: $(PERLRUN) -MPod::Text \ -e "Pod::Text->new (sentence => 1, width => 78)->parse_from_file( +qw( $(TO_INST_PM) Readme) );" MAKE_README }

... will create three new targets, all of which do the same thing (as written), with dmake postamble, dmake another_target, and dmake third.

See Win32::Mechanize::NotepadPlusPlus::Makefile.PL for an example of a bunch of extra targets, including ones to extract the README and LICENSE automagically from the POD.

edit: finished the last sentence; thanks hippo :/edit

edit2: replaced leading spaces with tabs to make it more portable; the actual commands listed were just copy/pasted from OP, and I didn't test/confirm; for known-working examples, see the linked Makefile.PL :/edit2

edit3: fixed per Re^2: let Makefile.PL to do the Readme file for me -- new target?; left original in spoiler for context :/edit3

Replies are listed 'Best First'.
Re^2: let Makefile.PL to do the Readme file for me -- new target?
by stevieb (Canon) on Jan 19, 2021 at 17:16 UTC

    Don't quote me on this, but years and years ago, I almost seem to recall adding stuff to the built-in targets:

    install:: shell command \ do things dist:: ....

    Update: In fact, something like this:

    install:: cgi conf graphics docs libs templates retest clean:: clean_sourcedirs clean_test cgi: install -m 0500 -o www -g www src/cgi-bin/accounting.cgi ${CGIDIR} clean_sourcedirs: rm -f doc/*.html rm -f doc/*.conf clean_test: rm -f t/test.db rm -f t/test.conf-dist ... and other things called by the main directives, such as conf, grap +hics for install...
      quoting stevieb on this, in direct violation of his wishes ;-)
      Don't quote me on this, but years and years ago, I almost seem to recall adding stuff to the built-in targets:

      yes. My linked Makefile.PL shows a realclean:: section, which adds new tasks to an existing target of that same name. It adds it after any existing actions for the target.

Re^2: let Makefile.PL to do the Readme file for me -- new target?
by LanX (Cardinal) on Jan 21, 2021 at 01:07 UTC
    >
    sub MY::postamble { return <<'MAKE_README'; ... MAKE_README ... MAKE_README ... MAKE_README }

    You have a C&P error here.

    I think you wanted to return the whole block not only the first rule, right?

    Delete MAKE_README #2 and #3 :)

    Cheers Rolf
    (addicted to the Perl Programming Language :)
    Wikisyntax for the Monastery

      whoops. Fixed my node. Sorry about that. :-)
Re^2: let Makefile.PL to do the Readme file for me -- new target?
by LanX (Cardinal) on Jan 20, 2021 at 17:09 UTC
    > See Win32::Mechanize::NotepadPlusPlus::Makefile.PL for an example of a bunch of extra targets

    With the help of https://makefiletutorial.com/ I was able to decipher, well at least get an idea of what is happening.

    We use a

    Perlmodule to build a makefile with embedded rules in here-docs snippets

    And those makefile rules embed

    • a macro syntax
    • a variable syntax
    • plus bash code

    So to be runnable on other plattforms we need

    • a make program
    • a bash emulation

    Doesn't sound like a very efficient way to have a file-timestamp-dependency system in Perl.

    Cheers Rolf
    (addicted to the Perl Programming Language :)
    Wikisyntax for the Monastery

      Rolf, no offense meant, but you seem to want this to be difficult; it's really not.

      For example, did you notice the name of that module: it starts with "Win32"? The solution I showed functions perfectly in Strawberry Perl on Windows, out of the box.

      Strawberry gives you the gcc build environment, with dmake (older strawberries) or gmake (newer strawberries) with perl -V:make showing the make variant to use. No extra work on your part. No bash emulation needed.

      Using a perl module to build a makefile is part of the standard ExtUtils::MakeMaker environment.

      Data::IEEE754::Tools Makefile.PL shows similar syntax, with the same syntax working on both Windows and Linux environments.

      Using the Makefile.PL -> Makefile to add extra targets, to automate extra things for development, is an intended use of the ExtUtils::MakeMaker environment. If you don't like it, that's your perogative; you don't have to use it. But it is a system that works, even on Windows with Strawberry Perl.

        I have to apologize if you had the impression I was criticizing your code. Sorry. :/

        It's a great peace of work showing a lot of nifty automization.

        I replied to you in this thread because you offered an elaborated example.

        What I meant was the whole concept, to use Perl to create two extra layers of different languages.

        It feels like embedding Sed to create Awk to me.

        Those levels of indirection must lead to problems.

        Cheers Rolf
        (addicted to the Perl Programming Language :)
        Wikisyntax for the Monastery

        edit

        s/atomization/automization/

        > Strawberry ... No extra work on your part. No bash emulation needed.

        Does it also work with ActiveState "without extra work" or do I need to install bash there?

        (in continuation of Re^2: dmake and bash on Win?)

        Cheers Rolf
        (addicted to the Perl Programming Language :)
        Wikisyntax for the Monastery