Cairo exports and more (was Re: [cairo] Re: Munging header files for export (and other) attributes)

[Carl Worth]

On Wed, 07 Sep 2005 23:36:17 +0200, Hans Breuer wrote:
> On 06.09.2005 22:58, Carl Worth wrote:
> > We've have "cairo_private" inside cairoint.h for a long time. Why not
> > "cairo_public" for this new attribute?

I've gone ahead and committed the addition of "cairo_public" now, (no
addition for the calling convention stuff yet).

It appears that it has confused gtk-doc quite badly. Fortunately,
we're not auto-publishing the web-page version of the manual from CVS
anymore, but this is something we'll need to fix.

> - Is a calling convention supposed to be part of the cairo API ?
> 
>    On win32 compilers you can define to have cdecl, stdcall, fastcall.
>    Gtk+ defines it's calling convention implicit to cdecl by it's use
>    of function pointer calls. To be compatible cairo must either do the
>    same or *explicit* declare the calling convention in any public function.
>    BTW: if the calling convention is not part of the cairo API it will not
>    be possible to have a stable ABI (Application Binary Interface)

Cairo has API calls that accept function pointers. Doe that mean it is
explicitly cdecl?

> - If a calling convention is part of the cairo API : is there any interest
>    to allow to use cairo from an application which chooses another defualt
>    calling convention (for whatever reason?).

This is the question I've been wondering about. I think I'm waiting to
hear from someone that actually runs into a problem trying to do
something before changing anything in this area.

> But with the current patch as an example I already have done the extra
> work to separate it into three independent parts. Which would be just
> another waste of time if all three are not accepted ;)

Oh, yes. The separated versions were quite helpful. In addition to the
cairo_public stuff mentioned above, I've also committed a modified
version of your portability patch. Thanks for the contribution!

> > 	http://freedesktop.org/wiki/AccountRequests
> > 
> Nope. The ssh part is easy enough but for the pgp part I currently dont
> know what steps I would need to done.

We should get that page modified with more details. I know that
basically you'll need to do:

	gpg --gen-key

It asks a bunch of questions, and I think that the defaults are sane
for anything you're not sure about.

After that, you'll want to do:

	gpg --export --armor address at example.com

using the address which you provided in generating the key. The output
here is what should be attached to the bug report.

> For Gtk+, Dia, The GIMP and some other projects the msvc build relies on
> configuration *by hand*. You basically need one master makefile-include-file
> which defines FOO_CFLAGS and FOO_LIBS matching your installation.
> It is described in more detail in :
> >>http://cvs.gnome.org/viewcvs/*checkout*/glib/README.win32 ?

If this is static, (or at least "sane defaults"), I think we should
probably just copy in the bits we need to let these cairo Makefiles
stand alone.

> >>AFAIK unknown pragmas are supposed to be ignored (with warning).
> >>#warning on the other hand gives a build error with msvc.
> > 
> > Setting aside the poor portability of "#warning", I think that either
> > version of the above should be considered a bug.

In the version of this patch that I committed I changed this to
#error. It's more portable that way, and better reflects our plans. (I
also added win32 mutex support to the 1.2.0 features in ROADMAP).

> HANDLE hMutex = CreateMutex (NULL, FALSE, NULL);
> 
> Lock:
> WaitForSingleObject (hMutex, INFINITE);
> 
> Unlock:
> ReleaseMutex (hMutex);

Those look simple enough to drop into CAIRO_MUTEX_DECLARE,
CAIRO_MUTEX_LOCK and CAIRO_MUTEX_UNLOCK, (except the call to
CreateMutex of course).

> On win32 there is DllMain() which could be used to intialize 'global'
> synchronization objects in a thread safe manner. (It is guaranteed that
> no other threads are started during DLL initialization).

If that's a function that we can define that is called implicitly,
then that's exactly what we'll want. We'll have to put a list of all
current mutex objects in the function of course. I don't see a great
way to guarantee that we don't add new instances of
CAIRO_MUTEX_DECLARE and forget to augment this function. But maybe that
will have to do for now. (Fortunately, we aren't adding new MUTEX
objects frequently).

> would be possible - if one is willing to leak the synchronizaion objects.
> Does not solve the intialization race though.

Yeah, that's pretty bogus. If I understand DllMain correctly it sounds
like a much better solution. I look forward to seeing a patch for all
of this.

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050907/23b3d3c6/attachment-0001.pgp