[cairo] Buidling cairomm with MSVC
Andrea Canciani
ranma42 at gmail.com
Mon Nov 11 02:04:16 PST 2013
On Sun, Nov 10, 2013 at 12:28 PM, John Emmas <johne53 at tiscali.co.uk> wrote:
> Hi guys,
>
> According to the cairomm information page, this is the correct mailing
> list for asking questions about cairomm. I hope that information's still
> current. I have a simple question about building cairomm with MSVC.
>
> After downloading cairomm from git, I can see that it contains a number of
> MSVC projects. AFAICT the various tests tend to build exes whereas the
> libraries are mostly built as DLLs. When building DLLs for Windows its
> common (in fact, mandatory AFAIK) to use __declspec for indicating when a
> symbol needs to get imported from a DLL.
See http://msdn.microsoft.com/en-us/library/aa271769(v=vs.60).aspx
__declspec(import) is mandatory for variables, but for functions it is just
an optimization which removes a jump.
> Exporting is slightly different because a module definition file can be
> used instead of __declspec. Indeed, I can see that the cairomm.vcproj
> files do generate a ".def" file at build time. But it still leaves the
> problem of how an application will know that cairomm.lib is the symbols
> library for a DLL as opposed to a regular static lib. This is the most
> common strategy... I've taken glibmm as an example because it also uses
> gendef:-
>
> #ifdef GLIBMM_DLL
> #if defined(GLIBMM_BUILD) && defined(_WINDLL)
> /* Do not dllexport as it is handled by gendef on MSVC */
> #define GLIBMM_API
> #elif !defined(GLIBMM_BUILD)
> #define GLIBMM_API __declspec(dllimport)
> #else
> /* Build a static library */
> #define GLIBMM_API
> #endif /* GLIBMM_BUILD - _WINDLL */
> #else
> #define GLIBMM_API
> #endif /* GLIBMM_DLL */
>
> I've looked for something similar in cairomm but I couldn't find anything.
> In fact, I couldn't find any use of __declspec at all, so how does this
> work in cairomm?
>
The idea is that the jump optimization is not usually needed.
If in your usage, it has a significant performance impact, could you
provide some testcases to reproduce the issue?
(I agree that a better handling of win32 DLLs would be quite desirable, but
right now I'm more concerned with other issues, like initialization and
TLS).
Andrea
>
> John
> --
> cairo mailing list
> cairo at cairographics.org
> http://lists.cairographics.org/mailman/listinfo/cairo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cairographics.org/archives/cairo/attachments/20131111/cecea04f/attachment.html>
More information about the cairo
mailing list