Aha. Yes, I was aware that this was a problem on MacOS; in fact, bug 867139 
discusses it. (It's a problem on Linux too, but the symptom is much less 

I think before committing any questionable changes to core Zorba, I would like 
to explore two alternatives:

1. If you could arrange for your testing process to rm -rf build/*_PATH after 
you do "make install", this problem would go away. A quick "make" will restore 
the contents of those directories. It's not a beautiful solution, but it 
actually is the "right one" because it guarantees that you are testing your 
installed image in exactly the way it will be run on a deployed machine, 
without a build/ directory. (Ideally you should blow away the build/ directory 
in its entirety to be really sure you're testing what you ship, but I 
understand that has ... drawbacks.)

2. Alternately, take a look at the description of bug 867139 and then do some 
research. If you can give me a reliable way on MacOS to determine the 
filesystem location of libzorba_simplestore.dylib (or, of the zorba executable 
itself, but that is less preferable), then we can implement the relocatable 
install feature that is already working on Windows. That  would fix this 
problem, make Zorba a little bit more efficient, and even allow people to move 
Zorba after installation.

I think both of these solutions are better than this proposal, because they 
actually address the underlying problem instead of dusting it under the carpet. 
Hopefully at least one of them can be implemented quickly.
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

Reply via email to