32-bit and 64-bit builds must be built separately into different build roots
Current blockers
Lack of a satisfactory solution for generating import libraries from .def files and adding them to the build dependency graph
In GitLab by @tau on Sep 28, 2019, 24:39
This is something I was looking at earlier (with help from icex2 to produce an initial proof-of-concept) but didn't have time to fully complete.
### Benefits
* Much faster compilation
* Precompiled header support (contributing to point 1)
* Ability to compile with MSVC as well as MinGW
* Ability to work on this project more or less conventionally from Visual Studio
* Integration with https://github.com/decafcode/capnhook (a public factored-out copy of this project's IAT hook core)
### Drawbacks
* 32-bit and 64-bit builds must be built separately into different build roots
### Current blockers
* Lack of a satisfactory solution for generating import libraries from .def files and adding them to the build dependency graph
There's some other very janky stuff that they do which I found occassionally causes trouble in practice. Being able to use MSVC would be nice though, for sure. Possibly worth to keep old build system in a parallel setup?
In GitLab by @praxis on Sep 28, 2019, 23:27
Worth noting that Meson's MinGW support is... suboptimal: https://github.com/mesonbuild/meson/blob/3a6920ebdcae0a2f9fee6ddf980fc8c7c94cf89c/mesonbuild/mesonlib.py#L688-L690
There's some other very janky stuff that they do which I found occassionally causes trouble in practice. Being able to use MSVC would be nice though, for sure. Possibly worth to keep old build system in a parallel setup?
Thanks for pointing this out. The proof-of-concept I created still had a few TODOs that needed to be figured out but I haven't worked on that for a while because I considered other things to have a higher priority.
I would like to avoid having two build systems in a parallel setup because I think this increases the maintenance costs a lot outweighing the benefit. I suggest we do the switch once all issues are resolved and meson supports our current build pipeline properly.
Thanks for pointing this out. The proof-of-concept I created still had a few TODOs that needed to be figured out but I haven't worked on that for a while because I considered other things to have a higher priority.
I would like to avoid having two build systems in a parallel setup because I think this increases the maintenance costs a lot outweighing the benefit. I suggest we do the switch once all issues are resolved and meson supports our current build pipeline properly.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
In GitLab by @tau on Sep 28, 2019, 24:39
This is something I was looking at earlier (with help from icex2 to produce an initial proof-of-concept) but didn't have time to fully complete.
Benefits
Drawbacks
Current blockers
In GitLab by @praxis on Sep 28, 2019, 23:27
Worth noting that Meson's MinGW support is... suboptimal: https://github.com/mesonbuild/meson/blob/3a6920ebdcae0a2f9fee6ddf980fc8c7c94cf89c/mesonbuild/mesonlib.py#L688-L690
There's some other very janky stuff that they do which I found occassionally causes trouble in practice. Being able to use MSVC would be nice though, for sure. Possibly worth to keep old build system in a parallel setup?
Thanks for pointing this out. The proof-of-concept I created still had a few TODOs that needed to be figured out but I haven't worked on that for a while because I considered other things to have a higher priority.
I would like to avoid having two build systems in a parallel setup because I think this increases the maintenance costs a lot outweighing the benefit. I suggest we do the switch once all issues are resolved and meson supports our current build pipeline properly.