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:
Post to     :
Unsubscribe :
More help   :

Reply via email to