[Spice-devel] typedefs and header dependencies

[Frediano Ziglio]

> 
> On 05/24/2016 12:19 AM, Jonathon Jongsma wrote:
> > On Mon, 2016-05-23 at 15:17 -0500, Jonathon Jongsma wrote:
> >> On Sun, 2016-05-22 at 04:19 -0400, Frediano Ziglio wrote:
> >>
> >>>>  /* FIXME: move back to display-channel.h (once structs are private) */
> >>>>  typedef struct Drawable Drawable;
> >>>> -typedef struct DisplayChannelClient DisplayChannelClient;
> >>>>
> >>>
> >>> We definitively should consider using struct Xxxx instead of moving
> >>> these typedef everytime in order to compile...
> >>
> >> Or create a spice-types.h header that contains forward declarations for
> >> all
> >> structs and include that in every other file. The includes really are
> >> quite a
> >> tangled mess and it's not an easy problem to unravel. I spent some time
> >> trying,
> >> but it's very difficult to do in a gradual way. I've resisted doing
> >> something
> >> like this in the past, but I'm starting to warm up to it...
> >>
> >> Jonathon
> >
> >
> > 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. 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.
> >
> > 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...
> >
> > 3. continue with the fragile approach we now have
> >
> > 4. use C++ :D
> >
> > Anything else I'm not thinking of? I'd like to hear opinions from as many
> > regular contributors as possible so we have a rough consensus, but I'd
> > really
> > like to do something about it.
> 
> 
> Hi,
> 
> I vote #3.
> Recently many lines of code are moving between files, but there
> should not be small amount of such moves once the refactoring
> is completed, and with option 3 the resulting code would
> be easier to read.
> 
> Regards,
>      Uri.
> 

I had some though about it and I think Uri reasoning is right,
I'll move my vote to #3.

Basically: it's not the right time to fix this issue, let
tolerate for a bit the broken rules and fix when code is settled.

This came after observing my first attempt. The attempt was using
"struct Xxxx" forward declaration so I saw where the "struct "
was added. Mainly: Drawable, DisplayChannel, DisplayChannelClient
that is all DisplayChannel related stuff. Trying to decreasing the
changes I also realized that these headers/code/structures are
really entangled and I think header problem is caused just by this.

Frediano