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

[Piers H. <pi...@om...>]

Cool.

Brian did talk about wanting to remove make from the build process - he 
was probably refering to his conversations with you.  I must admit that
I didn't think it was a good idea at the time, but perhaps it would work
if there is sufficient other ways ( that are part of the core ) to get
rid of the OS specific parst that make and MakeMaker deals with.

Another question - is it possible to get the Build.PL file to
sufficiently emulate a Makefile.PL file so that -
(a) if someone doesn't have Module::Build they get informed of it 
and
(b) CPAN.pm can work with it?  ie. rename the Build.PL to Makefile.PL -
and it just works.  That might be a goal to aim for, as people who are
not familiar/interested in module build processes use tools like CPAN.pm
and ppms.

I have Linux, and HP-UX, Windows ( of all sorts of nasty flavours ;-),
and maybe some more via Melbourne.pm if I can ask them the favour.
 
Cheers.



On Sun, Aug 18, 2002 at 07:15:55PM +1000, Ken Williams wrote:
> [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