Thread: [Module-build-general] Re: Inline and the 5.6.0 that comes with OS X

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

[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

Thread: [Module-build-general] Re: Inline and the 5.6.0 that comes with OS X

module-build-general