MSYS2/MINGW builds for MS Windows #3069
Comments
|
@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. |
pvanek
pushed a commit
that referenced
this issue
Oct 29, 2018
pvanek
pushed a commit
that referenced
this issue
Oct 29, 2018
pvanek
pushed a commit
that referenced
this issue
Oct 29, 2018
|
Also here is a HOWTO for Windows: |
davidnich
added a commit
that referenced
this issue
Oct 30, 2018
davidnich
added a commit
that referenced
this issue
Nov 2, 2018
sejvlond
pushed a commit
that referenced
this issue
Nov 27, 2018
* refs #3069 cmake changes for building on Windows * refs #3069 - allow to use relative paths for module location for MS Windows * refs #3069 - forgotten patches * refs #3069 minor fix for cross-compiling with autotools * refs #3069 fixed builtin module installation when cross compiling with autotools * refs #3079: Make Counter::inc() return count to align with dec() * refs #3084 added Qore logo to docs, removed reference to the long-unavailable FreeSans font, added references to the already-merged FsUtil module in the docs (#3085) * refs #3079: Minor docs fixes * Feature/3080 class instance of (#3083) * refs #3080 implemented Class::instanceOf() * refs #3080 added Class::getInheritanceAccess() to the reflection API + tests * refs #3080 added a negative test * refs #3080 fixed tests for new methods * refs #3080 added missing tests for Class::instanceOf() * refs #3080 fixed testing inaccessible classes in debug mode * refs #3086: Add logo to README * Fixed the Qore logo in README.md * refs 3069 proper usage of std::string. ModuleDirList::push_back is changed to use std::string
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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/somethingorC:/msys64/home/pvanek/src/qore/RELEASE/share/qore-modules/0.9.0for 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_DIRenv 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-modulesetc.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"The text was updated successfully, but these errors were encountered: