Closed dumblob closed 11 years ago
There was a minor bug in the initialization of searching paths. But after fixing it, I realized it wasn't the bug that caused this problem. Is it possible that your system has environment variable DAO_DIR defined to empty string?
I'm not quite sure why there should be any environment variable set (I don't know about any program which needs such an env var set only to find it's own files). Anyway, I have no environment variable with name containing DAO
or any of it's case-variant set.
0$ env | grep -i dao
1$
Could there be some misconfiguration in CMake? I have read all the CMakeLists.txt
files in dao, dao-modules and dao-tools repositories, but haven't found anything suspicious.
During the initialization of searching paths, env variable DAO_DIR is checked for customized setup. If DAO_DIR is not defined, it will be automatically set to the path of the Dao executable during startup, so it normally need not to be set. However, this seems not working on your system for some unknown reason. I am considering to avoid the automatic setting of DAO_DIR, and directly check and add a couple of path relative to the Dao executable, this will save one loading of "addpath.dao".
Yes, your new idea sounds good to me. Anyway, I'm certain that CMake have the capability to set the path of anything at compile time to the system-specific absolute paths. This could be another "usable" approach (in other words: let everything on CMake and don't do anything at runtime itself except the check for customized setup).
Done. Please check if it works on your system.
I still get almost the same errorneous output. See the new output of strace dao -e 'load sys; io.writeln(0)'
on http://pastebin.com/tniFWtuw .
The list of files and folders which CMake created for system installation is almost the same with the exception of missing
dao-git /usr/bin/addpath.dao
dao-git /usr/bin/autobind.dao
Thank you for testing it. Finally I did some tests on Linux, it turned out that the problem is that argv[0] does not contain the path to the executable. Now I fixed it by parsing $PATH and checking for the executable.
Thank you, now it works like a charm. Btw it is sad, that one have to parse $PATH
(there must be some better solution at compile-time, but for now this is the safest method I know about).
For convenience I ran strace
once more and you can see the output on http://pastebin.com/RJiuu4Xq . Would it be possible to instruct CMake to include the "right" paths and names, such that it would not be needed to check many different names for each particular module (e.g. (sys.da[oc]|(lib)?dao_sys.so)
) in many different "nonsensical" directories like .../modules/stream/
, .../modules/string/
etc.?
I think it is better not to assume the executable is always placed in the directory that is configured at compiling time. Flexibility is more preferable here, besides, the parsing and checking time should be neglectable.
Regarding module searching, to avoid searching through the paths and checking for different types of modules, the mapping from module names to paths has to be generated and saved at compiling time. As mentioned above, there is no guarantee that these path will be valid, for example, when the modules are not installed at the configured locations.
Please note that, each module is search only once when it is loaded at the first time. So such overhead is just one time thing, and it should be acceptable.
Thank you for explanation. You must be right.
So, I tried to install Dao right into my system (Arch linux 3.7.5-1-ARCH x86_64), but
dao
can't find any of the modules. According tostrace
, it searches in the CWD, but not in the system folders where CMake placed the modules.See the
strace
output on http://pastebin.com/ZHvqQaeaThe following is a list of files and folders which CMake created for system installation.