Regarding the GenZorbaRuntime.cmake change: I noticed when I merged this change locally *into an already-working build* that the build started failing. Turns out to be because GenZorbaRuntime implicitly depends on the XML module, and once the new xml.xq file was installed in URI_PATH, you couldn't import the XML module because it couldn't find the implementation of the new canonicalize#1 function (because it hadn't actually been compiled yet). Classic chicken-egg problem.
GenZorbaRuntime.cmake has always had a solution to the chicken-egg problem: It checks to make sure Zorba works before attempting to re-generate the runtime files, and if Zorba "doesn't work", it copies the pre-generated files instead. My change just extends the "doesn't work" check to verify that the XML module is working too. FYI the ZorbaRuntimeGenerator.cmake change is similar. There I discovered that there was a race condition if you launched the build in parallel, because the target which copied the new version of xml.xq to the URI_PATH wasn't guaranteed to run before the runtime generation. In some cases, the copy occurred between the times GenZorbaRuntime.cmake performed the "Zorba doesn't work" check and when it actually invoked Zorba, so the runtime generation still failed. I added a dependency to ensure that all URI_PATH copies happen before runtime generation is attempted. -- https://code.launchpad.net/~zorba-coders/zorba/canonicalize-core-fixed/+merge/142394 Your team Zorba Coders is subscribed to branch lp:zorba. -- Mailing list: https://launchpad.net/~zorba-coders Post to : zorba-coders@lists.launchpad.net Unsubscribe : https://launchpad.net/~zorba-coders More help : https://help.launchpad.net/ListHelp
