On 2015-03-23 17:56-0000 Phil Rosenberg wrote: > i) Fontconfig is nearly impossible to build on native Windows. We have > had these discussions before. GIMP does appear to use it, but they > have no doubt had considerably more development person-hours than us > to work out how on earth to get it to build.
I am sure you are right (but see commment about CMake-based build system for fontconfig at the end). Virtually everything in the GTK+ stack of libraries including fontconfig is built with autotools (out of inertia and absolute unwillingness by those developers to change to CMake-based build systems). For example, the epa_build of fontconfig is is currently forced to use autotools because there is no CMake-based build system for fontconfig at the moment. In theory, such autools-based builds should work on Cygwin and MinGW + variants, but in my experience autotools really is not a good basis for cross-platform builds. I frankly cannot recall whether I had success or not with epa_building fontconfig on MinGW/MSYS, and I may not have even tried that before I gave up on epa_building all of GTK+ on Windows because of autotools issues on Windows I kept running into. Furthermore, I also got advice from one guy to follow what he used to do which was to build all GTK+ for Windows using a Linux cross-compiling environment rather than a Windows platform (such as Wine in my case). He felt so strongly that cross-compiling was the only answer that he described any attempt to build a GTK+ component on a Windows platform as only for the masochistic! :-) So in the short term, I think your best course is to use a binary downoad of a Windows version of fontconfig. There are at least three immediate possibilities here which are the following: 1. Cygwin 2. MinGW-w64/MSYS2 (see <https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-fontconfig>) 3. Either 32-bit or 64-bit versions built by GTK+ developers (see <http://www.gtk.org/download/win32.php> or <http://www.gtk.org/download/win64.php>). (I think these variants are built on Linux using cross-compilation.) I assume all of these possibilities could be used by simply putting fontconfig on your PATH without you having to use, say, Cygwin or MinGW-w64/MSYS2 for the rest of your build. On the other hand, for the long term, I think our best bet is simply to implement a CMake-based build system for fontconfig and its gperf dependency which would guarantee that you could build fontconfig on native windows similarly to the way you use our CMake-based build system to build PLplot on native Windows. I have already looked into this possibility a little bit, and it turns out fontconfig has only one dependency, gperf, which in turn has none. So this greatly simplifies the problem (compared, say, to having to create CMake-based build systems for the ~40 different software packages that are built as part of the GTK+ stack of libraries). Of course, creating CMake-based build systems even for just two software packages is non-trivial, but I suspect from my other fairly extensive experiences with converting autotools-based builds to CMake-based builds for packages with limited dependencies like fontconfig and gperf it would be a matter of, say, a week or so to get this done rather than months. I obviously do not have a spare week at the moment, and neither do you which is why I have classified this as a long-term possibility, but for now can you see anything wrong with using one of the 3 alternatives above for some PLplot developer who was looking to generalize the current plfreetype approach to use fontconfig? Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
