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

[Carl Worth]

On Mon, 05 Sep 2005 23:23:00 +0200, Hans Breuer wrote:
> On 04.09.2005 23:15, Owen Taylor wrote:
> > On Sun, 2005-09-04 at 13:58 +0200, Hans Breuer wrote:
> >  * The addition of export markers generally looks good to me.
> >    Carl will have to make the final call as to whether he
> >    likes the names.
> > 
> IMO after all it doesn't look that bad. Though my prefered solution
> would have beem the symbols file approach as well - and drop the
> concept of messing with calling conventions ;)

We've have "cairo_private" inside cairoint.h for a long time. Why not
"cairo_public" for this new attribute? I'm definitely not yet
convinced it makes sense to put the calling convention attribute into
the public header yet.

> >  * The portability stuff is mostly good. I think rather than
> >    hacking up the PDF and PS backends to build without font
> >    support, it would be better to not build them until we 
> >    get font embedding working with win32 fonts. It's not
> >    that much work.
>
> Maybe, but my patches are huge enough for now.

As an aside, the one-big-patch style has always made these harder for
me to work with in terms of pulling things into cairo. With the
current patch for example, I definitely don't want these PDF and PS
modifications in the tree. One patch per change would definitely make
it easier to take the changes that are acceptable.

> >    You may have the right idea with CMake.
> I'm not sure. There wasn't much interest in bringing it any further as I
> announced it. Also maintaining the files for a cross-platform build alone
> seems to be a little out of my scope.

I've been meaning to respond to the cmake proposal for a long time,
but I've just been too busy. I wanted to try it out on Linux since to
see if it would be a viable candidate for replacing what we're
currently using. In some ways I would be more easily convinced to
replace our current system rather than supporting two simultaneously.

But in the meantime...

> On 04.09.2005 23:18, Owen Taylor wrote:
> > I forgot to finish what I was saying, which was that while I don't think
> > the .msc makefiles are a full solution, I think it makes sense to get
> > them into the tree ... might as well have *something* there.

Owen's likely right that something is better than nothing, so we
should probably just put the .msc Makefiles into CVS. Hans, did you
request/get CVS commit access yet?

	http://freedesktop.org/wiki/AccountRequests

> > Perhaps we should include the relevant parts of build\..\make.msc in the
> > cairo tree to avoid having GLib be a build dependency of cairo? 
> > 
> A better solution may be to detect if the bigger environment is available
> and fallback to a *no dependencies* cairo build? That approach was quite
> simple to get working even with the ugly nmake syntax.

What's the issue here? Is it that the current patch depends on glib
just to borrow a piece of its build infrastructure? That's something I
definitely don't want. What piece is it borrowing?

> > A short document describing how to set up a build using this stuff would
> > be quite useful.
> > 
> Something along the line of
> http://cvs.gnome.org/viewcvs/*checkout*/glib/README.win32 ?

Yes, something along those lines would be quite useful. I wrote up
something like that for the current auto* system before releasing 1.0:

	http://cairographics.org/INSTALL

And I think a similar document is a requirement for any new build
system to land in the tree.

> >    One additional problem with project files is the structure of 
> >    tests/ ... as far as I can see, we would need a project file *per*
> >    executable. Perhaps we should consider switching from lots of 
> >    separate files to:
> >  
> >      cairo-test # runs all 
> >      cairo-test a8-mask # runs one

We might want to do that anyway. I've wanted better control of the
individual and summary print messages anyway.

> >  #ifndef CAIRO_MUTEX_DECLARE
> > +#  ifdef __GNUC__
> >  # warning "No mutex declarations, assuming single-threaded code"
> > +#  else
> > +#  pragma message("No mutex declarations, assuming single-threaded code")
> > +#  endif
> > 
> > The pragma here is as MSVC specific as #warning is GCC specific. So, it
> > would be good to conditionalize it. 
> 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. Cairo really should
be thread-safe. An obscure message scrolling by during compilation of
cairo itself shouldn't be sufficient for building a non-thread-safe
cairo.

> > Long term, of course, what really
> > needs to be done is implement locking for Win32.
> > 
> That one depends on a backend constructor facility cause the synchronization
> objects can not be initialized statically. Otherwise quite a simple
> task.

And hopefully the initialization to make this complete isn't too hard
either.

Would it be possible to have CAIRO_MUTEX_DECLARE define a function
that initialized the synchronization object on its first call and then
make CAIRO_MUTEX_LOCK call into that function first? Is there some
non-object based mutual-exclusion mechanism that could be used to do
that without a race condition?

A less desirable approach would be to put the call to the mutex
initializing function at the beginning of the body of every public
function. The problem would then be that we'd need a single list of
all mutex objects in that function, so we'd need some way to make sure
that list stayed consistent with all instances of
CAIRO_MUTEX_DECLARE.

And this wouldn't be any less racy, but could at least be documented
that some public cairo function call must be called before starting up
non-primary threads. (That's a pretty ugly interface, so hopefully we
can avoid having to document it that way.)

-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/20050906/e1b4b651/attachment.pgp