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
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.
Your team Zorba Coders is subscribed to branch lp:zorba.
Mailing list: https://launchpad.net/~zorba-coders
Post to : firstname.lastname@example.org
Unsubscribe : https://launchpad.net/~zorba-coders
More help : https://help.launchpad.net/ListHelp