Front page | perl.perl5.porters |
Postings from March 2016
Re: generated docs files not under source control?
Thread Previous
From:
demerphq
Date:
March 26, 2016 13:04
Subject:
Re: generated docs files not under source control?
Message ID:
CANgJU+X1EmHW8i9y04+ZN_ig3eNkHz3S67J_MS7iCBzORr1jkg@mail.gmail.com
On 26 March 2016 at 13:51, Zefram <zefram@fysh.org> 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.
Cheers,
yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
Thread Previous