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::
        ....
[download]

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...
[download]

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.

sub MY::postamble  {

    return <<'MAKE_README';
...
MAKE_README
...
MAKE_README
...
MAKE_README
}
[download]

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 :)

whoops. Fixed my node. Sorry about that. :-)

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.

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}