> > 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 _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel