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

Hans Breuer hans at
Mon Sep 5 14:23:00 PDT 2005

On 04.09.2005 23:15, Owen Taylor wrote:
> On Sun, 2005-09-04 at 13:58 +0200, Hans Breuer wrote:
>>As usual the full patch to let me build cairo on win32 with
>>msvc is much bigger than just munging some headers.
>>Following the full ChangeLog entry and three pieces from the
>>patch (exports = munging headers, poratbility = non-gcc,
>>msc = makefiles for msvc build). The full patch is available
>  * 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 ;)

>  * 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.

>  * In terms of the makefile.msc stuff ... it obviously quite
>    specific to a particular build setup; see things like
>    !INCLUDE $(TOP)\glib\build\win32\make.msc. I tried for a little
>    while to get things going, but got frustrated enough with trying
>    to work in the windows command prompt (blech) that I gave up.
>    It was easier to create project files from scratch for 
>    visual studio.
Yeah, nmake needs some time to get used to it ;-)

>    To make hacking on cairo "attractive" to people using MSVC, there
>    seems to be two constraints:
>    - The solution must integrate with the IDE. It could possibly use
>      external makefiles, but even so project files are needed.
This makes the solution either highly version specific (workspace format
changes incompatible with every major release). Also I'm not convinced
project files make it more "attractive" than a simple (better two) :

	nmake -f makefile.msc

>    - It must be possible to let the user configure a couple of options - 
>      where they have libpng installed, whether they have FreeType installed,
>      and, if so where. Possibly also where the Platform SDK is installed.
>      (Needed if you are building with the free-beer "Visual Studio Express")
Which wouldn't have the IDE to process the proposed project files, would it ?

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

>    If we aren't generating project
>    files than we would probably have to just take the configuration aspect
>    of the picture (no FreeType, libpng is in ../libpng, or whatever.)
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.
> 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.

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

>    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
Or use a nmake makefile again ?

> A few comments on details:
> +#  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.

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

> +/* Every exported symbol should be decorated with this macro.
> + * It gets defined by the build system on poor platforms where
> + * exporting *all* functions possible is not the default.
> + * It should *not* be defined in cairo-features.h cause usually
> + * the definition needs to be different between exporting while
> + * *building* the library and importing while using it. 
> + */
> I think we can omit the editorializing
What ever you see fit. [Though I dont quite understand the sense
of editorializing here :-)]

>  [...]
>  * This can be defined by the build system if we need to mark
>  * exported functions for the compiler.
>  [...]
> Or something :-) The mozilla people find it useful for GCC, even.

-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to
get along without it.                -- Dilbert

More information about the cairo mailing list