[Fontconfig] CMakeLists.txt for fontconfig library (enables native compilation on windows)

[Pavel Koshevoy]

On 10/8/12 2:52 AM, Diego Santa Cruz wrote:
>> -----Original Message-----
>> From: Pavel Koshevoy [mailto:pkoshevoy at gmail.com]
>> Sent: 06 October 2012 04:40
>> To: Diego Santa Cruz
>> Cc: fontconfig at lists.freedesktop.org
>> Subject: Re: [Fontconfig] CMakeLists.txt for fontconfig library (enables
>> native compilation on windows)
>>
>> Turns out the only reason my cmake project worked was because I had
> previously
>> run ./configure and it generated those .h files for me.  I need to figure
> out
>> a way to generate them via cmake instead.  I would appreciate if you would
>> share your vs2008 project.
>>
> Please find attached my VS2005 project as patch.
>
> The fc-case.c, fc-glyphname.c and fc-lang.c build utilities are built via a
> custom build step and each have as stated output the corresponding .exe file
> name. The fccase.tmpl.h, fcglyphname.tmpl.h and fclang.tmpl.h also have a
> custom build step each, stating the corresponding final header file (e.g.,
> fccase.h) as output and the necessary .exe as dependency, so that they
> automatically run. The dependencies are not perfect, but good enough to build
> fontconfig out of its source tree.
>
> The solution also has a pre-link build event that generates the .def file for
> the DLL and a post-build event that installs the library, include and
> configuration files according to our in-house conventions.
>
> Some of the custom build steps use perl to process the info. For instance the
> fclang.tmlp.h custom build step extracts the list of orth files from the
> Makefile.am file via perl, instead of recopying the list into the VS project
> because that always ends up being out of sync at one point.
>
> Note that the header files such as fccase.h are not created in an object file
> output directory but right in the source tree because MSVC looks for #include
> "xxxx.h" in the directory of the file containing the include directive and
> not in the current directory as GCC does. If the files were created elsewhere
> the ones picked up would be the ones in the source distribution and not the
> ones created in the custom build steps.
>
> The config.h file I generated manually, starting from the config.h.in and the
> config.h generated by configure under Linux x86. I do not see how it could be
> easily auto-generated.
>
> Also note that the VS project has some of our in-house conventions, like
> generating a debug version of the lib (linked with the debug runtime) with
> the "d" suffix, looks for include and lib dependencies in an external
> directory, uses .so as the extension for most import libs instead of .lib,
> etc.
>
> If people are interested in a cleaned-up version of this VS project to
> include in the fontconfig distribution I would be glad to create one.
>
> One thing that I have not yet solved is how to properly implement the
> FcFStatFs() function for Win32. I will be sending a separate message to the
> ml about it.
>

Thank you for this.  I've looked through the patch and I've noticed that 
fontconfig.def generation relies on perl.  Fortunately I was able to 
avoid this dependency using cmake built-in regex facilities.

You provide a faithful dirent.h reproduction and follow the WIN32 
conventions regarding ANSI and Unicode encoded string APIs (opendir and 
_wopendir).

I didn't bother to go to those lengths.  Since fontconfig uses char * 
for paths/strings and WIN32 unfortunately doesn't support UTF-8 file 
paths -- in my implementation I stated that all char * strings are 
treated as UTF-8.  I convert from UTF-8 to UTF-16 wchar_t * strings 
prior to calling the WIN32 Unicode enabled APIs.  In my view this is a 
reasonable method to enable Unicode filepath support in fontconfig on 
windows without switching all of fontconfig APIs to wchar_t * strings.  
Along those lines I've also provided UTF-8 wrappers for other filesystem 
functions used by fontconfig (access, open, unlink, rmdir, mkdir, chmod)

One thing that you provide and that is missing from my cmake project is 
the auto generation of fontconfig.pc -- I'll see what I can do about that.

     Pavel