Front page | perl.perl5.porters |
Postings from April 2010
Quoth nick@ccl4.org (Nicholas Clark): > On Mon, Apr 05, 2010 at 10:24:39PM +0100, Ben Morrow wrote: > > Quoth nick@ccl4.org (Nicholas Clark): > > > > > > So I can't see how the whole tree can be done this way. Given that > DynaLoader > > > needs XS compilation, and DynaLoader.o needs to be built to build perl, > > > > Is there a good reason for this? That is, is there some reason dl_*.c > > can't just be included in the normal build, rather than an extension? We > > would still need an ext/DynaLoader/Makefile.PL to do the preprocessing > > on DynaLoader_pm.PL, but it could become a nonxs module. > > Good question, and one I'd not thought of. > I don't know, but I'm guessing that it's this way because > > a: it always was this way > b: it was historically assumed that it's easier to write XS than to write > equivalent C code > > > Do the same for File::Glob and we could probably get rid of miniperl > > altogether in the common case of no other static extensions. > > Except, I think that we'd still need to retain the existing infrastructure to > cope with building static extensions. I don't think you do, though. If you can get perl built without building any (XS) extensions, you can do the static linking using the already- existing 'make perl' infrastructure in MakeMaker. (You can't link a Module::Build extension statically, but you can't do that anyway). This means we can get rid of miniperl, which simplifies the build (especially on Win32, where everything has to be copied and compiled twice). It also means that modules packaged with core are built the same way as if they were installed from CPAN, which should simplify the process of creating 'fat core' distributions. > And, IIRC, static extensions are needed to use one of gprof or gcov. > So there is an obvious non-Unicos use case for them, and hence no > simplification, as best I can tell. > > "Change is inevitable, progress is not". Hence I'm seeking to maximise the > amount of progress for unit change. And in this case, I view maintainability > as progress, and simplification as a likely proxy for maintainability. Hence > why I'm viewing any of this in terms of simplification. Oh, I agree entirely. Making things 'neater' without actually simplifying them is not helpful. BenThread Previous | Thread Next