[Adding the Module::Build list to recipient list, and getting
rid of Mac OS X...]
On Sunday, August 18, 2002, at 06:11 PM, Piers Harding wrote:
> How would Inline/Module::Build take care of ( in a platform independent
> way ) processes like moving files, copying etc. Would it still use the
> ExtUtils::Command routines for this?
In general Module::Build uses lots of ExtUtils::* or File::*
routines. I haven't yet seen the need for ExtUtils::Command in
Module::Build, because most of the things supported there either
have equivalents in File::* or in core perl.
> It is dealing with these kinds of issues that are also dealt
> with in "make" that need to be overcome. Would there be any
> benefit in producing a quick bunch of basic build tests that we
> could run on a variety of platforms to determine if this kind
> of approach is going to pay off. I can help with that if it
> seems like a good idea?
Yes, these kinds of tests can simply become part of the
regression test suite for Module::Build. It would be great to
add to its existing tests.
> What kinds of platforms do people on the list have at their
> disposal for testing out these issues?
I only have Mac OS X (perl 5.6.1) at my immediate disposal,
though I can test on Linux (perl 5.6.1) from time to time.
In general, eliminating 'make' and using the ExtUtils::* and
File::* modules seem to be doing a really good job of allowing a
single code base with no "if ($platform eq _something_) {"
statements in Module::Build.
-Ken
>
>
> On Sun, Aug 18, 2002 at 02:31:52PM +1000, Ken Williams wrote:
>>
>> On Saturday, August 17, 2002, at 08:23 AM, Nicholas Clark wrote:
>>> Inline only uses MakeMaker to compile 1 XS file into 1 C file
>>> into 1 shared
>>> object, doesn't it? It's not using most of MakeMaker's functionality.
>>
>> This is the same subset of MakeMaker's functionality that is
>> currently supported by Module::Build, too.
>>
>> The main reason Module::Build hasn't gone further is that I
>> don't yet understand the other scenarios that need to be
>> supported. I can see basically what MakeMaker is capable of
>> from its documentation, but I don't yet know how it's used in
>> practice in CPAN modules.
>>
>>> Invoking the compiler in a more direct fashion would also avoid make.
>>> So it would allow much better error diagnostics.
>>
>> Yeah, this is the approach Module::Build takes. There's a
>> compile_c() method and a link_c() method, which invoke C
>> compilers by calling the do_system() method, which just calls
>> CORE::system(). The compilation commands are just pieced
>> together from pieces of the %Config hash. I've been surprised
>> at how successful that's been, actually.
>>
>>
>> Then, on Saturday, August 17, 2002, at 04:29 PM, Brian Ingerson wrote:
>>> I've removed the dependency of Parse::RecDescent thanks to a
>>> great patch from
>>> Mitchell Charity that does the job with regexps. It'd be a
>>> shame to add a new
>>> dependency.
>>
>> If you don't want another dependency for Inline itself, you
>> could certainly copy the compile_c() and link_c() methods from
>> Module::Build. They're fairly simple. It would be nice to
>> share some code, though, for the reasons Nick outlined.
>>
>>> It would be cool to distribute M::B within Inline and also within
>>> the modules that require Inline.
>>
>> This doesn't really help, I think. It's not that people are too
>> lazy to download the prerequisites, it's that they don't want
>> the conceptual complexity of a larger (and seemingly
>> unnecessary - see below) web of installed prerequisites on their
>> system.
>>
>>> The ultimate goal being that you want
>>> authors to be able to use Inline instead of XS without it
>>> imposing any
>>> dependencies on their work. I think this is one thing that
>>> keeps people from
>>> writing serious modules with Inline.
>>
>> I think that if Inline were truly a build-time-only dependency
>> for modules (without even the small run-time stub you've been
>> thinking of), that would help quite a bit. I don't think people
>> care so much about startup performance as they do keeping track
>> of prerequisites. Module::Build introduces the concept of
>> build_requires vs. requires, maybe this would help.
>>
>> If Inline weren't a run-time dependency, then, you could feel
>> free to have Inline depend on whatever you wanted. You wouldn't
>> be saddling people's modules with more dependencies.
>>
>> -Ken
