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
