extension init cleanup

[Paulo César Pereira de Andrade]

Tomas Carnecky wrote:
> On 02/05/2009 10:53 PM, Paulo César Pereira de Andrade wrote:
>> Tomas Carnecky wrote:
>>> I tried to clean up the header files that contain declarations
>>> for the various extension. Basically, in the end the header
>>> include/extinit.h contains the declarations of the extension
>>> init functions and declarations of the noXxxExtension booleans,
>>> sorted and put under their respective ifdef guards.
>>> It's that many patches because I tried to keep each commit
>>> as simple as possible, to make it easier to review. It should
>>> also be git-bisect friendly, meaning that after each single
>>> commit the tree builds.
>>>
>>> If you would rather see the patches, I can send them to the
>>> list as well. But I think I spammed the list enough yesterday
>>> so today it's just this cover mail.
>>
>>    Hi,
>>
>>    I Just looked up superficially, as I curious about the
>> "Clean up declarations to make sdksyms.sh happy" commit.
>
> Actually, neither before nor after this commit does sdksyms.sh complain.
> That's because I put a whitespace before every extern declaration. I
> know that's cheatning, but I did this so I could work on the code
> without build failures - with the intention to fix it at the end, when I
> see the big picture (which functions are used from where etc).
>
>>
>>    I did not track in which commit the prototypes were
>> added to extinit.h, but if a symbol there is to be used
>> by other shared objects, you should use
>> extern _X_EXPORT type name();
>> and not just
>> extern type name();
>>
>>    There is already enough mess in the source tree, so, if
>> you added _X_EXPORT to the function definition, I suggest
>> reconsider :-), as it makes it harder to have automated
>> tools handling this stuff... And the only usages in sources,
>> so far are basically GL and fooModuleData.
>>    The problem of adding it to sources is also mainly due
>> to way too much functions declared by macros; Things
>> things like xf86rename.h can easily get out of control.
>
> I kept the noXxxExtension declarations as-is (they were _X_EXPORT in
> includes/global.h, I just moved them to extinit.h). I didn't add any
> attribute to the functions though. Some are used only from within
> mi/miinitext.c (GE, SHAPE, bigreq, xkb, sync, xfixes and a few others).
> Other extensions are used from other modules (screensaver, dga, dri,
> glx, record, xv, ...).
>
> When I was chatting with Adam about extern and the various attributes,
> he said that he would like to make 'hidden' the default, and that you'd
> have to explicitly mark symbols for export. What's preventing us from
> using -fvisibility=hidden ?

  Are you compiling with "--disable-visibility"?  :-)
-fvisiblity=hidden is the default in git master for quite some
time already...

> I'm willing to add the proper attributes the the functions. However
> there still is one issue: I need to prevent sdksyms.sh from picking up
> certain declarations, like this one:
>   extern void DPMSExtensionInit(void);
> This function is defined in dbe/dbe.c, but is not being linked into
> libxorg.a but into a shared library that is later loaded by Xorg. So the
> final link fails because the symbol is missing. I worked around that by
> adding a whitespace before the declaration. Shouldn't sdksyms.sh only
> pick up declarations with _X_EXPORT?

  It parses cpp output, and _X_EXPORT may expand to nothing. But
sdksyms.sh also parses (ignores) the expected gcc and sun cc
expanded value.

  But about symbols that are defined in modules under the xorg/xserver
tree, you could use the #ifdef XorgLoader trick I used for Xext headers,
(it is somewhat the logic used for XFree86LOADER, but I did not want
to use that symbol for safety...) as it is a mix of builtin and non
builtin declarations, as well as modules, i.e. part is builtin in the
Xorg binary, and part is in the extmod module.

> tom
>
>