I had the privilege to apply the fist series of patches to trunk after the 2.4 branch was created. After some IRC chat with Derek yesterday, I think these patches require some more explanation and discussion.
The birdseye view to this issue is this: * In total I applied 12 patches, which actually are all required to get the Windows build working with guile 1.8. * These patches have been tested and work (on my system), but are fairly invasive, as they require a gcc update. * This is no problem if you are only interested in the unstable branch. * It becomes a problem if you wish to be able to build either the unstable branch or a stable branch alternatively in one and the same mingw environment, because the updated gcc can't build the stable branch on Windows. We need to find a solution for this on our own (Windows) build server. Your feedback on this is welcome. If you care about this, or want to know more, please read on for the more detailed version. For reference, the patches are: 1. http://svn.gnucash.org/trac/changeset/20435 2. http://svn.gnucash.org/trac/changeset/20436 3. http://svn.gnucash.org/trac/changeset/20437 4. http://svn.gnucash.org/trac/changeset/20438 5. http://svn.gnucash.org/trac/changeset/20439 6. http://svn.gnucash.org/trac/changeset/20440 7. http://svn.gnucash.org/trac/changeset/20441 8. http://svn.gnucash.org/trac/changeset/20442 9. http://svn.gnucash.org/trac/changeset/20443 10. http://svn.gnucash.org/trac/changeset/20444 11. http://svn.gnucash.org/trac/changeset/20445 12. http://svn.gnucash.org/trac/changeset/20446 Let me start with some background on these patches. Why 12 and why are they all required ? I started this work a couple of months back [1], attempting to get guile 1.8.7 running on Windows. This didn't work at all back then, because guile 1.8.7 had bugs that prevented it from being built on Windows. These bugs have been fixed in guile 1.8.8, so I restarted my attempts as soon as 1.8.8 was out. It became clear quite early in the process that is was not possible to build the more recent guile with gcc 3.x. So as a first intermediate step, I tried to get guile 1.6 (the old version) to build with gcc 4.x. Unfortunately after many attempts and tweaks I didn't manage to do so. So the choice for Windows was guile 1.8.8 with gcc 4.5.2 or guile 1.6.x with gcc 3.x. I just didn't find another way. Getting the window build compiling with gcc 4.5.2 and guile 1.8.8 is the work of patches 5, 8, 9 and part of patch 10. Initially I didn't remove the slib stuff, because it was still used in many parts of GnuCash. But while I could build guile 1.8.8 with gcc 4.5.2, it didn't work at all with slib. For some reason the search path used by slib's "require" function was completely garbled in the new setup. There are two slib functions which are used a lot in GnuCash: require and printf. But require is even used to test if slib is installed correctly at configure time (both for guile/slib on windows as for gnucash on all platforms). I did spend some time trying to correct this, but eventually I gave up. The primary reason is that I remembered a set of patches by Andy Wingo to remove the slib dependency from gnucash [2]. So it would be a waste of effort to get slib running in the new setup, only to remove it again shortly afterwards. So instead, I chose to apply Andy's patches first (temporarily breaking the build on Windows in the process), and simply remove the slib dependency completely before updating guile itself. These are the first 4 patches in the list. The remaining patches are just some cleanup actions for small bugs that appeared as a result of the other patches. That's the background on the patchset. I have tested it, and it works fine here. So in itself this patchset is good for trunk. So where's the problem ? As said before, due to some compilation issues, it's either gcc 4.5.2/guile 1.8 or gcc 3.x/guile 1.6. A mixed combination doesn't work. And I'm simplifying this slightly, because gcc has it's own depencencies on mingwrt. I don't remember exactly, but I *believe* the mingwrt version required by gcc 4.5.2 isn't compatible with gcc 3.x and the other way around. And something similar may be the case for other gcc dependencies. So that means that the same build environment can't be used anymore for stable builds and unstable builds. If you already had a GnuCash build environment set up earlier and wish to test new patches, you can upgrade your build environment with these steps: * run reset.sh * remove g++.exe from your mingw/bin directory. * configure custom.sh to get svn updates from trunk * update the build scripts (svn update in the directory containing install.sh) The next run of install.sh will then download and install the proper version of gcc and its dependencies over the old ones. But I haven't tested this in the other direction. I'm not sure you can do the same thing to go back to the old gcc and dependencies if you need to build from the gnucash 2.4 branch or an older tag somewhere. Obviously this is only a problem if you intend to build both stable and unstable versions of gnucash on one and the same machine. I'm not sure if many people are building gnucash on Windows anyways, let alone both stable and unstable. But our automated build server is heavily impacted because of this. It is configured to automatically build the latest svn trunk commit and any tags that weren't build until then. That means it will try to build both sources that require the old or the new gcc. Something we can't right now. So the big question here is, how can we solve this, both short term (the trunk build is broken right now) as potentially long term (so a future major build system change doesn't cause the same head-ache again) ? I don't have a complete answer yet. But here are some thoughts: * A "minimal" impact solution would be to change the install scripts to allow for multiple gcc installations. I'm not sure if this is even possible though. gcc may require a particular mingwrt version. And at the same time, we don't support multiple build directories for any other dependency. If you want a new version of libofx, you need to remove the older version first. By default the same would be true for gcc. This may need some tweaking and testing to pull off. The advantage of this solution (if it can be done) would be that one build system can build all tags and releases, simply because it just has to pick the right compiler depending on the target. But both are installed alongside one another. * Slightly more invase approach is to have independent MSYS/mingw build environments depending on what you want to build. This can be set up relatively easily. There is a problem with the msys installer script that IIRC assumes it's the only installation available and hence interferes with already installed msys configurations. But that can be worked around. I am successfully using two independent MSYS/mingw configurations for quite some time now. This works fine if you manually choose which tag or branch to build, because depending on your target, you can choose to work in to old or the new build environment. The complication here comes from the automated setup on the build server. How can it determine automatically which MSYS/mingw environment to use depending on the target ? How does it know it should build trunk in the new environment, while 2.4.5 should be built in the old environment. But later 2.5.0 should be built in the new environment again ? * For the build server, we could go one step further and simply have two separate VM's, one for the old build environment and one for the new build environment. This avoids the msys interference issue from the previous point, but the other issue remains ? How does the automated system know in which environment to build its targets ? * And a last option I hadn't considered so far: if the guile/gcc update turns out to be stable enough, we may backport it to the 2.4 branch. That would avoid any build system duplication after all. Obviously that would mean the build system from that point on wouldn't be able to rebuild old tags, but it would be able to build both new tags and trunk. Old tags are normally not rebuilt anyway so that may not be an issue. The issue here is that I don't want to call this update stable enough. I have tested it locally, but that doesn't mean it doesn't contain bugs. What do you think ? Which solution would be preferable and realistic (in terms of effort vs gain) ? Geert [1] https://bugzilla.gnome.org/show_bug.cgi?id=621238 [2] https://bugzilla.gnome.org/show_bug.cgi?id=615168 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
