Re: typedefs and header dependencies

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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)


> 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?


> 3. continue with the fragile approach we now have

Sounds like it's not your preferred option ;)

> 
> 4. use C++ :D

I agree with Pavel here, I'd try to finish merging the remaining patches
first..

Christophe

Attachment: signature.asc
Description: PGP signature

_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]     [Monitors]