[FFmpeg-devel] [VOTE] Multiple inclusion guards in headers
Mon Aug 18 10:08:26 CEST 2008
On Mon, Aug 18, 2008 at 09:33:42AM +0200, Reimar Doeffinger wrote:
> On Mon, Aug 18, 2008 at 08:59:50AM +0200, Diego Biurrun wrote:
> > On Mon, Aug 18, 2008 at 08:49:31AM +0200, Reimar Doeffinger wrote:
> > > On Sun, Aug 17, 2008 at 07:17:22PM +0200, Michael Niedermayer wrote:
> > > > This is the second issue id like to see clarified
> > > >
> > > > Do we require headers that do not need multiple inclusion guards out of
> > > > technical reasons to have multiple inclusion guards?
> > > > technical here is speed, compiler warnings or errors, or spec compliance
> > > >
> > > >
> > > > My vote is of course, no, as it makes the headers bigger and thus means
> > > > more to read aka worse readability.
> > >
> > > I do not think the overhead of these is significant and avoids the annoyance
> > > of possibly having to add them later.
> > > I am against making a big deal about it though, this is nothing critical and
> > > while everyone should make an effort to remember adding them, forgetting
> > > it should not lead to flaming - IMO it might be a good idea to here "discard"
> > > the normal commit rules and allow everyone to add them without sending a patch first...
> > So you want to start handing out licenses for sloppyness? That's one
> > hell of a slippery slope...
> We are talking about 3 lines of trivial code. Yes, I think there is no problem with
> risking being a _bit_ more sloppy than usual.
It really should not be too hard to add them though. There's just one
or two things to keep in mind when adding a new file. If this is too
hard (is it really?), we can add a checklist, similar to the new codec
> Note that I don't want to see this applied to the license headers, they are much too
> easy to mess up in a slight but relevant way (though I agree there should be a more
> automated way to handle them - if not as commit hooks maybe as part of make test,
> or how about a script that adds those headers? IMO less risky than relying on copy-
> and-paste skills.
That's the first time I ever hear somebody speak of copy-and-paste
More information about the ffmpeg-devel