On 10/8/12 2:52 AM, Diego Santa Cruz wrote:
-----Original Message-----
From: Pavel Koshevoy [mailto:pkoshevoy@xxxxxxxxx]
Sent: 06 October 2012 04:40
To: Diego Santa Cruz
Cc: fontconfig@xxxxxxxxxxxxxxxxxxxxx
Subject: Re: 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
_______________________________________________
Fontconfig mailing list
Fontconfig@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/fontconfig
