# from Andreas J. Koenig
# on Tuesday 11 September 2007 11:04 pm:
What you're describing sounds like a combination between the two.
>diplomatic writes Makefile.PL (diplomatic) and Makefile-trad.PL
> (traditional).
(and probably Makefile-pass.PL (passthru))
> On the user box: The diplomatic calls the
> traditional if no Module::Build is install,
Yeah, just passes-through.
> otherwise it plays the Build.PL.
> In the latter case a small Makefile is provided too, so
> that a call to 'make' translates to a a call to './Build'.
That's what passthru does. So, you're describing a layer which would
multiplex between the two existing compatibility layers and requires
shipping two more Makefile-like.PL files.
It would work, but not any better than whichever compatibility file it
dispatches to. I don't think that solves much.
If Makefile.PL and make were adequate interfaces, Module::Build would
behave like Module::Install in that it prints a makefile (then binds,
spindles, and mutilates the ExtUtils::MakeMaker warranty by applying
s/// to said Makefile.)
Or, we could just rewrite all of that printing-of-Makefiles code and
replicate all of that cross-platform goodness. Let's call it m4, but
that probably won't be high-level enough, so we'll wrap that with an
'autoconf' layer.
Or, hey! Maybe we could use the language for which we are building code
(and which we know is installed and is known to work) to build said
code. This might even enable the author to use such modern
conveniences as subclasses to redefine the build behavior. It might
even run faster.
--Eric
--
The only thing that could save UNIX at this late date would be a new $30
shareware version that runs on an unexpanded Commodore 64.
--Don Lancaster (1991)
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
