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 : firstname.lastname@example.org
Unsubscribe : https://launchpad.net/~zorba-coders
More help : https://help.launchpad.net/ListHelp