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? 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? What kinds of platforms do people on the list have at their disposal for testing out these issues?
Cheers. 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
