JohnMG has asked for the wisdom of the Perl Monks concerning the following question:

What tool do you tend to use for automating sundry tasks around the house?

Ruby has Rake. I think Python has SCons. Java has Ant. Also, I notice that Perforce makes an open-source tool called Jam (on the Jam website they write this vaguely familiar remark: "Jam is a software build tool that makes building simple things simple and building complicated things manageable."). What is Perl's answer to GNU Make?

Replies are listed 'Best First'.
Re: Perl-specific automation tools?
by shmem (Chancellor) on Oct 23, 2006 at 08:10 UTC
    What is Perl's answer to GNU Make?
    None I guess, since GNU make isn't a challenge to perl - they work together, hand in hand and each on it's specifics. 'ant' is the Java make, perl doesn't need such a thing.

    As for tools - well, there's h2xs, ExtUtils::MakeMaker, PAR, Module::Build just to name a few, and the whole bunch of standard C and unix tools.

    --shmem

    _($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                                  /\_¯/(q    /
    ----------------------------  \__(m.====·.(_("always off the crowd"))."·
    ");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
Re: Perl-specific automation tools?
by Intrepid (Curate) on Oct 23, 2006 at 14:32 UTC

    What is Perl's answer to GNU Make?

    The esteemed (late) Perl stalwart Nick Ing-Simmons, of Perl/Tk fame, answered GNU Make with a module, Make.pm, and a script that uses it, pmake. Walter Higgins replied with TinyMake. Different people have come up with different ideas.

    Tools like TT2 can replace some of what Make does, as well. There is dependency-tracking intelligence built in to TT2, I understand.

    I'm just a huge fan of GNU Make (and BSD Make is a quite different and arguably more powerful tool, and is also very nice). I'm not going to be rushing to write a 'make' replacement anytime soon; I'd find it a better use of time to offer patches to GNU make to improve its behavior on marginal platforms (that odd little non-unixy one produced in Redmond comes to mind). That said, when 'building' a package for installation does not involve much more than copying data from templates, with interpolation, and then finding the appropriate filesystem locations in which to place the final result, Perl by itself is perfectly capable of doing the job.

        Soren A / somian / perlspinr / Intrepid

    -- 
    Words can be slippery, so consider who speaks as well as what is said; know as much as you can about the total context of the speaker's participation in a forum over time, before deciding that you fully comprehend the intention behind those words. If in doubt, ask for clarification before you 'flame'.

      That said, when 'building' a package for installation does not involve much more than copying data from templates, with interpolation, and then finding the appropriate filesystem locations in which to place the final result, Perl by itself is perfectly capable of doing the job.

      Very true. Thanks for the reply.

Re: Perl-specific automation tools?
by Anonymous Monk on Oct 23, 2006 at 10:58 UTC
    Does Perl need an answer to (GNU) make? Was there a challenge? My experience so far with ant is that's just make with an XML syntax (meaning that you need lots of keystrokes to do something simple).

    There are tools to generate make files for you - ExtUtils::MakeMaker for instance. Configure (as found in the Perl source distribution) and configure (found in many other software distros) are others. And there are even tools to write configure files: autoconf and metaconf (Larry Wall authored one).

    Note that make is language agnostic. It has a long list of language specific default rules, and it might have originally be written to compile C programs, but I have used make to compile C, Pascal, C++, generate GIF and JPEG images, generate documentation in man, PostScript, POD and PDF format, build file systems, and to build complete Linux distros. And then I forget more than half of the things I've use make for. Now, in all cases, the make I've used was written in C, but it might as well have been written in Java or Perl - the effect would have been the same.

    make is a tool, an excellent tool, and in my toolbox it ranks a close second to Perl (but it would be harder to replace than Perl).

    There's no need for a "Perl answer to GNU Make". Just as there's no need for a "Perl answer to Emacs", or a "Perl answer to horse racing".

    If there's one thing that might be seen as a partial answer to make, it's Module::Build. But as the name suggests, it's geared towards building Perl modules.

Re: Perl-specific automation tools?
by philcrow (Priest) on Oct 23, 2006 at 13:03 UTC
    Module::Build is our answer packaging things nicely for sharing with others or installing on prod boxes. You could also use the traditional ExtUtils::MakeMaker.

    C/C++ people need make to compile their programs. Pure Perl programs (at least until Perl 6) are compiled on the fly when the program runs. So, we don't need make until we add C code. Then we use make via the modules mentioned above.

    Java people need ant (or something like it) as a make replacement because the java compiler is written in java. This means that every time make sees a stale compiled file, it must start a JVM to compile a new version. Starting JVMs is hugely time consuming. Ant starts one JVM and keeps it running for all the compiles.

    A tool like Module::Build will compile C as necessary, using make, but otherwise is just an organizer. It has a manifest of the files users need to install. It has a test suite to make sure the packages are working as expected. It has a script (Build) which runs the tests, installs the modules, etc. MakeMaker actually generates a genuine make file to do those things. Since make files are not so easy to maintain, and are not competely standard between make variants, the tide seems to be moving in favor of Module::Build which is pure perl.

    Phil

      C/C++ people need make to compile their programs. {snip} ... Java people need ant {snip} ...

      Right. But there are, of course, other generic tasks you might use Make or Ant for. For example, building documentation after updating it, uploading a static website that gets modified regularly, installing your webapp from the qa server to the production one, and so on.

      Although I tend to use a mix of [MR]akefiles and homegrown scripts for these sorts of things, I'm curious if other Perl users had alternative solutions.

      BTW, Thanks for the links everyone. For my own modules, will read up on Module::Build. :)

Re: Perl-specific automation tools?
by jdporter (Paladin) on Oct 23, 2006 at 13:13 UTC
    What is Perl's answer to GNU Make?

    42.

      ++, jd, but I still want to know about what annonymonk offered:
      "Perl answer to horse racing". (sic)
Re: Perl-specific automation tools?
by eyepopslikeamosquito (Archbishop) on Oct 24, 2006 at 02:04 UTC

    Ruby has Rake. I think Python has SCons.
    In addition to Rake, Ruby also has Rant. As for SCons, it's based on the Perl Cons software construction utility, both designed by Steven Knight. Notice that Cons, SCons, Rake and Rant are all examples of an "internal" DSL (Domain Specific Language).

    As noted in Using the Rake Build Language:

    • make is an external DSL using a custom syntax
    • ant (and nant) is an external DSL using an XML based syntax
    • rake is an internal DSL using Ruby
    Internal DSLs have some advantages, notably:
    • You don't have to drop out of the DSL to perform tasks outside the scope of the DSL. For example, a home-grown concoction of makefiles, perl and shell scripts can be awkward to maintain.
    • Easy interoperability when using multiple internal DSLs.
    The trouble with Cons, SCons, rake and rant is that you are limited to using only valid syntax of the host language; that is, you can't invent new syntax to better express your domain. I feel Perl 6, due to its macro capability, should prove a superior language for implementing internal DSLs (much like Lisp).