Front page | perl.perl5.porters |
Postings from March 2016
demerphq wrote: >I was wondering why we .gitignore files like pod/perlapi.pod and >pod/perlintern.pod. I know they are autogenerated, but I don't >understand why they are different from the files that are >autogenerated by make regen. Those pod files are being handled correctly. In principle, the things that are generated by make regen should not be in the repository. Of course, that means an extra step would be required in building from a repository, and we'd want to automate that. I believe the difference in the treatment of these files historically arises from which ones are included in source tarballs. This is quite understandable with the repository's historical content having been derived from the tarballs, but now that the repository is primary we ought to have changed it. >I guess I could frame this more generally. Why do we do some build >steps "on demand", via make-regen, and why do we do some "in-line", >via make all? The distinction being made there is whether someone installing perl from source is expected to have the tools to perform that build step. Installers are not expected to have a working perl already installed, but core developers are. This dictates which generated files need to be included in source tarballs, as well as which generation processes will be automatically invoked by the build system. >Can we speed up the build process by checking in more of our files, We could, a little, but it would suck. It's the wrong direction to go in. We ought to stop committing in the generated files that we currently do. This would have the advantage that diffs aren't confounded by the noisy consequential changes in generated files. It would also eliminate the existing failure mode of committing desynchronised versions of the source and generated files. -zeframThread Previous | Thread Next