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

[Hans Breuer]

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
>>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.
> 
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 http://cvs.gnome.org/viewcvs/*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:
> 
>  #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.

> 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.
> 
Thanks,
	Hans

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