Braden McDaniel <braden <at> endoframe.com> writes:
> But in any case, who really cares if the patch is big as long as the
> changes are necessary and appropriate?
A big patch is a patch which touches many locations and that is a patch which
easily breaks when upstream makes any changes to their source code.
> We can do without the strawman.
I don't see how comparing the situation to GCC and Binutils is a strawman,
they're all translators which take a source file as input and generate an
output file.
> > So how are the autotools different from GCC and Binutils?
>
> Source packages produced by an autotools build are designed to be
> buildable in the absence of the autotools themselves. They are not
> designed to be buildable without a compiler and POSIX environment.
That distinction is artificial, you're defining "building" to include the
compilation step for the code, but not the one for the build system. The only
difference I can see between the autotools and a compiler is that the
compiler's output is platform-specific (meaning you have to build from source
for portability), but take Java/OpenJDK/IcedTea as the example and that
distinction vanishes. Java binaries are "designed" to not need rebuilding at
all, so should we just ship them from binaries?
No matter how you spin the definitions, generated files are _not_ source code.
> Probably the reason there is no guideline treating all generated files
> the same way is that doing so is a really dumb idea.
And why?
Now, banning all generated files is probably unnecessarily radical (there may
be some valid reasons for them, even if I disagree about there being such valid
reasons in the case of the autotools, as most of the alternatives do fine
without shipped generated files), but that still doesn't mean you should blame
maintainers for doing their modifications on the actual source code (which is,
after all, the "preferred form for modification" under the GPL's definition)
rather than some autogenerated file. Generated files are not meant to be
edited.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
