On Wed, 2 Jan 2013, Jeff Law wrote: > I've always found lazily updating the copyright years to be error prone. If > we could just update all of them now, which is OK according to the FSF > guidelines we could avoid one class of problems.
I suspect dealing with generated files will be more complicated for GCC than for glibc. There are more of them, and many of them are architecture-specific with update rules in architecture makefile fragments, so a simple "make" for one architecture won't regenerate them all as it does for glibc. Some may require unusual tools, or special versions of tools, or not have makefile rules at all (e.g. the various ARM files generated using O'Caml). Some may not be listed in contrib/gcc_update either, further complicating identifying them all, although that's certainly a useful place to start getting information about generated files in the source tree. And it's often the case for generated files in GCC that the generator has both its own copyright notice at the top of the file, and a later one that gets put in the generated file, so both need updating before regenerating the generated file (but update-copyright only updates one copyright notice per file). It may make sense to start automation with a limited set of files, under the gcc/ directory only and excluding both generated files and their sources, before gradually extending what's covered by automation for updating copyright notices. Other ways of looking for generated files, apart from targets in makefiles and makefile fragments that update files in srcdir, and apart from the lists in gcc_update, include looking for characteristic comments such as "automatically generated", "Generated automatically", "do not edit manually" and "-*- buffer-read-only: t -*-" that various generators output. (When such things are found, appropriate makefile rules and gcc_update entries could then be added to make future regenerations easier.) -- Joseph S. Myers jos...@codesourcery.com
