Closed pvanek closed 5 years ago
@davidnich your opinion on 2nd point, please?
@pvanek I think your proposal with relative paths on Windows is great
Also it looks like the current windows build is broken regarding the astparser and reflection modules; they don't get installed with the autotools build. I'm not sure if the cmake build supports cross compiling yet either.
Also here is a HOWTO for Windows: https://github.com/qorelanguage/qore/wiki/MS-Windows
patches for proper building under MSYS2/MINGW on Windows - in progress
discussion about module paths: The problem with Windows is that we are distributing zip files which can be extracted anywhere. But these binaries have hardcoded paths for modules (
/z/something/something
orC:/msys64/home/pvanek/src/qore/RELEASE/share/qore-modules/0.9.0
for example). These hardcoded paths are fine on Linux because the language should be distributed in a form of system packages (rpm, deb). But on Windows the user decides where to put (extract) the zip archive content. It can be anywhere.I know there is
QORE_MODULE_DIR
env variable. But it requires logout/login on Windows to be in action. Also user has to set 4 paths there. And unfortunately 2 of them must contain qore version in the path. So it (theoretically) requires to change env variable (and re-login) after any qore upgrade. It's pretty annoying IMHO.So what about to introduce (windows only?) solution that modules will be searched in relative paths from current qore.exe binary? Paths can be compiled in (as defines) as e.g.
<qore.exe>\..\lib\qore-modules
etc.Then, during interpret start, the
<qore.exe>
placeholder can be expanded to a real interpret location with a full path. And the modules can be found "automagically"