Cairo exports and more (was Re: [cairo] Re:
Munging header files for export (and other) attributes)
cworth at cworth.org
Wed Sep 7 18:59:48 PDT 2005
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
> - 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:
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
> >>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);
> WaitForSingleObject (hMutex, INFINITE);
> 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
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050907/23b3d3c6/attachment-0001.pgp
More information about the cairo