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

[Owen Taylor]

On Sun, 2005-09-04 at 13:58 +0200, Hans Breuer wrote:
> On
> 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 
   visual studio.

   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:

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

Regards,
						Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050904/9e8ba2c0/attachment.pgp