daokoder / dao

Dao Programming Language
http://daoscript.org
Other
199 stars 19 forks source link

Unable to run dao when installed system-wide (using CMake) #9

Closed dumblob closed 11 years ago

dumblob commented 11 years ago

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 to strace, it searches in the CWD, but not in the system folders where CMake placed the modules.

See the strace output on http://pastebin.com/ZHvqQaea

The following is a list of files and folders which CMake created for system installation.

1$ pacman -Ql dao-git
dao-git /usr/
dao-git /usr/bin/
dao-git /usr/bin/addpath.dao
dao-git /usr/bin/autobind.dao
dao-git /usr/bin/dao
dao-git /usr/include/
dao-git /usr/include/dao.h
dao-git /usr/include/daoArray.h
dao-git /usr/include/daoBase.h
dao-git /usr/include/daoBytecode.h
dao-git /usr/include/daoClass.h
dao-git /usr/include/daoConst.h
dao-git /usr/include/daoGC.h
dao-git /usr/include/daoLexer.h
dao-git /usr/include/daoMacro.h
dao-git /usr/include/daoMap.h
dao-git /usr/include/daoNamespace.h
dao-git /usr/include/daoNumtype.h
dao-git /usr/include/daoObject.h
dao-git /usr/include/daoOptimizer.h
dao-git /usr/include/daoParser.h
dao-git /usr/include/daoProcess.h
dao-git /usr/include/daoRegex.h
dao-git /usr/include/daoRoutine.h
dao-git /usr/include/daoSched.h
dao-git /usr/include/daoStdlib.h
dao-git /usr/include/daoStdtype.h
dao-git /usr/include/daoStream.h
dao-git /usr/include/daoString.h
dao-git /usr/include/daoThread.h
dao-git /usr/include/daoType.h
dao-git /usr/include/daoValue.h
dao-git /usr/include/daoVmcode.h
dao-git /usr/include/daoVmspace.h
dao-git /usr/lib/
dao-git /usr/lib/dao/
dao-git /usr/lib/dao/modules/
dao-git /usr/lib/dao/modules/addpath.dao
dao-git /usr/lib/dao/modules/libdao_aux.so
dao-git /usr/lib/dao/modules/libdao_fs.so
dao-git /usr/lib/dao/modules/libdao_graph.so
dao-git /usr/lib/dao/modules/libdao_graphics.so
dao-git /usr/lib/dao/modules/libdao_math.so
dao-git /usr/lib/dao/modules/libdao_meta.so
dao-git /usr/lib/dao/modules/libdao_net.so
dao-git /usr/lib/dao/modules/libdao_serializer.so
dao-git /usr/lib/dao/modules/libdao_sync.so
dao-git /usr/lib/dao/modules/libdao_sys.so
dao-git /usr/lib/dao/modules/stream/
dao-git /usr/lib/dao/modules/stream/libdao_clprint.so
dao-git /usr/lib/dao/modules/stream/stream.dao
dao-git /usr/lib/dao/modules/string/
dao-git /usr/lib/dao/modules/string/libdao_format.so
dao-git /usr/lib/dao/modules/string/libdao_md5.so
dao-git /usr/lib/dao/modules/string/libdao_tokenize.so
dao-git /usr/lib/dao/modules/string/libdao_xxtea.so
dao-git /usr/lib/dao/modules/string/string.dao
dao-git /usr/lib/dao/modules/web/
dao-git /usr/lib/dao/modules/web/libdao_cgi.so
dao-git /usr/lib/dao/modules/web/libdao_json.so
dao-git /usr/lib/libdao.a
dao-git /usr/lib/libdao.so
dao-git /usr/share/
dao-git /usr/share/doc/
dao-git /usr/share/doc/dao/
dao-git /usr/share/doc/dao/license.txt
daokoder commented 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?

dumblob commented 11 years ago

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.

daokoder commented 11 years ago

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".

dumblob commented 11 years ago

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).

daokoder commented 11 years ago

Done. Please check if it works on your system.

dumblob commented 11 years ago

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
daokoder commented 11 years ago

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.

dumblob commented 11 years ago

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.?

daokoder commented 11 years ago

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.

dumblob commented 11 years ago

Thank you for explanation. You must be right.