On 2013-06-28 09:44-0000 Schwartz, Steven J wrote: > There is a potential snag in your approach which is that the build-projects wrapping of a project's own autotools/whatever is only as good as that project's build strategy. Good, relatively small projects are probably ok. I've read tales of woe and pages of "minor tweaks" trying to build Qt on Windows from source.
To help insure a fixed set of tweaks (and to control the numbers of such tweaks that are necessary), the premise of the build_projects approach (and also any Linux distribution of software for that matter) is to fix each library/software version at values that are known to interact well together. Getting this right is non-trivial for large distributions of software. A good example of this is the year or so of hard effort by many users and packagers stabilizing a new Fedora or new Debian distribution of free software. Of course, this effort is still non-trivial even for relatively small collections of software such as PLplot and all its dependencies. The build_projects project already has reliable builds of wxwidgets (a large PLplot dependency) as well as the many small dependencies of PLplot on Linux and Wine. However, for this case reliable builds of pango/cairo and Qt4 (as you have pointed out) on all platforms are an ongoing concern. Fortunately, the jhbuild system normally used to build the GTK stack of libraries (pango and cairo are a subset of that stack of libraries) on Linux, Mac OS X, and Windows has configuration files specifying the dependencies between the many different projects in the stack, and for each project, the download command, the checksum for that download, the configuration command, the build command, the install command, and the test command. All these jhbuild configuration files are expressed in xml form so it should be straightforward to parse those files and transform them to equivalent arguments of the ExternalProject_Add command using a python script. Also, known working values of those xml files are provided for each release of the GTK stack of libraries So my idea is to automatically (via the proposed python script) take full advantage of the GTK development team's expertise in building their software stack on Linux, Mac OS X, and Windows when configuring build_projects to build pango, cairo, and all their dependencies. With luck this should allow reliable building of pango/cairo (and even all of GTK if someone else becomes interested in the full GTK stack) out of the box on all platforms using the build_projects project. I currently don't know any details in the Qt4 case except that someone on the CMake list gave me the references for something called the "emerge" project that is equivalent to what jhbuild does for the GTK stack of libraries. So in that case as well I hope to take full advantage of the build expertise of the "emerge" team when configuring build_projects to build Qt4. So I will see how that goes when the time comes, but I will deal with pango/cairo first because I already have some familiarity with jhbuild and the build data provided in jhbuild configuration files. > In chasing your build-project on the web I stumbled on mingw-builds which generates some external binaries. Actually only two: msys+friends and Qt. So I am going to try to build plplot (and our software) using their gcc 4.7.2 build of gcc and Qt4.8.4. Their documentation is non-existent and they don't tell me revision of 4.7.2 matches which of their Qt builds, but I've taken a good guess based on the date stamps. Since Qt 4.8.4 is the end of the Qt4 line, and gcc 4.7.2 reckoned to be a very good gcc, I'm hopeful that this will be a solid toolchain that is futureproof for a few years perhaps. I'll let you know how I get on in case you get driven in similar directions against your will or, as in my case, desperation. Thanks for that reference which might be a good supplement in the Windows case to the "emerge" project as a source of the necessary information to reliably build Qt-4.8.4 on all platforms. 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 __________________________ ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Plplot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/plplot-devel
