develooper Front page | perl.perl5.porters | Postings from March 2016

Re: generated docs files not under source control?

Thread Previous
March 26, 2016 13:04
Re: generated docs files not under source control?
Message ID:
On 26 March 2016 at 13:51, Zefram <> wrote:
> 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.

Ah, yes, this point explains it. Thanks.

> 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.

On this one I think we will have to just agree to disagree. I find
those diffs more useful than the risk of de-synchronization, which I
think is a problem we can manage via measures like git hooks on our
server if we choose to do so.

I respect that you see it otherwise, but having written some of the
autogenerated stuff, and debugged what they produce, I can say I found
the built in diffs invaluable, and the synchronization issue a
negligible problem. I positively like that when something changes I
can see the cascade into generated files. I find it educational to say
the least.

Anyway, I have a feeling our community will evenly divide into the two
camps, so I am content to leave it as it is. Thanks for pointing out
that stuff that needs a "working perl" to generate is easier managed
in make regen.


perl -Mre=debug -e "/just|another|perl|hacker/"

Thread Previous Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About