Cairo exports and more (was Re: [cairo] Re: Munging header
files for export (and other) attributes)
otaylor at redhat.com
Sun Sep 4 14:15:22 PDT 2005
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
> via http://hans.breuer.org/gtk/cairo.html
* 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.
* 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.
* 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
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.
- 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")
You may have the right idea with CMake. 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.)
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
A few comments on details:
+# ifdef __GNUC__
# warning "No mutex declarations, assuming single-threaded code"
+# pragma message("No mutex declarations, assuming single-threaded code")
The pragma here is as MSVC specific as #warning is GCC specific. So, it
would be good to conditionalize it. Long term, of course, what really
needs to be done is implement locking for Win32.
+/* 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
* 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050904/9e8ba2c0/attachment.pgp
More information about the cairo