[Spice-devel] typedefs and header dependencies

[Jonathon Jongsma]

On Tue, 2016-05-24 at 12:08 +0200, Christophe Fergeau wrote:
> On Mon, May 23, 2016 at 04:19:02PM -0500, Jonathon Jongsma wrote:
> > 
> > So, I chatted (very briefly) with Frediano about this on IRC after sending
> > this
> > email and I thought we should gauge opinions on options here.
> > 
> > This typedef stuff really does make refactoring more difficult. When we move
> > stuff around, we have to keep adding temporary typedefs to make things
> > compile.
> > Or we have to remove these typedefs to avoid redefining the same struct
> > multiple
> > types.
> 
> This removal of typedefs is only needed to address el6 build I think?
> Imo it's fine if RHEL6 is temporarily broken because of that and if we
> fix it later.
> 
> > So there are several options:
> > 
> > 1. Use 'struct Foo' throughout the code instead of 'Foo' so that we don't
> > have
> > to deal with the typedef mess.
> 
> I'd hate having a mass rename, and I'd hate things to be inconsistent
> too :-/ (except if it's only for a few specific types that "struct foo"
> is used, but it seems it's not the case here)

I think we be consistent: either ust "struct foo" for everything or "foo" for
everything. Having a mixture is a recipe for confusion, IMO.

> 
> 
> > 2. the approach listed above (a spice-types.h file that simply typedefs all
> > structs). This is a bit of a maintenance nightmare and needs to be kept up
> > to
> > date and for a lot of types that are relatively self-contained it's not even
> > necessary to put them in a global header like this...
> 
> I'm afraid I don't get how much of a mess it is, but would it be
> realistic to just add the most problematic typedefs to it?

It's a possibility, but it would be a bit arbitrary I think. We'd end up with a
hodgepodge of typedefs in a header that only are related by the fact that at one
time they caused build failures. I don't really like that. 

> 
> 
> > 3. continue with the fragile approach we now have
> 
> Sounds like it's not your preferred option ;)

Oh, you mean I have to give my opinion as well? :P  Yes, I did forget to do
that. And yes, I don't like the current state. It's annoying to have to
constantly move things around when refactoring.

That said, I am a bit conflicted about the best approach to take. I initially
was quite opposed to the spice-types.h solution, but then started thinking it
might not be too bad. But now I'm thinking it would be a maintenance headache
and I'm actually leaning a bit more toward solution #1: using "struct foo"
everywhere. But I don't really like either of them very much...

> 
> > 
> > 4. use C++ :D
> 
> I agree with Pavel here, I'd try to finish merging the remaining patches
> first..

Yes, I wasn't clear on the time frame, but my personal opinion is that we should
probably do this (whichever option we choose) after the branch has been fully
merged. Trying to do it now would just create more work for rebasing, etc.

And the C++ thing was a bit of a joke. As Frediano said, this issue is not
really a reason to switch to C++. But (as you might expect) I would not oppose a
gradual switch to C++ for a variety of other reasons.

Jonathon