-
Notifications
You must be signed in to change notification settings - Fork 981
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[feature] Support visual studio backend for meson #10440
Comments
Hi @Makogan To change the def build(self):
meson = Meson(self, backend="vs2019")
meson.configure()
meson.build() If you don't pass anything, by default, it's going to use the Anyway, I invite you to have a look at the new MesonToolchain/Meson generator/build-helper documentation. from conan.tools.meson import Meson, MesonToolchain
class App(ConanFile):
# ....
def generate(self):
tc = MesonToolchain(self, backend="vs2019")
tc.generate()
def build(self):
meson = Meson(self)
meson.configure()
meson.build() |
Actually, it is not really necessary to modify the default in the recipe. You can let the Ninja default, and define |
Sorry if I try this:
I get
I also tried doing things with the generate syntax and i get this error:
Looking here: There does not seem to be a call path for the vs backend. |
It seems you are using the wrong |
This is the start of my recipe:
If I modify the code to match the suggestion i.e. change my imports
I start getting a series of errors about unrecognized keywords, meaning I can no longer do any of the following:
This class seems to expect all work to be done in the generate step. I tried setting up everything there:
I get:
I read the docs: I am not 100% what I am doing wrong (thank you for the help and sorry to be lost) |
This is wrong: from conans import ConanFile, tools, Meson You need to: from conans import ConanFile, tools
from conan.tools.meson import MesonToolchain, Meson Then, yes, the new integration |
I did, I explained on the comment I changed from one to the other: This is at the header of the recipe:
|
I am reading this issue and it seems the feature is pretty new. Can I ask what was the rationale to not simply modify the _run_ninja_backend command? It seems trivial to modify it to accept other backends. |
We have a few tests that cover the new integrations, let me for example paste one of them as an example: from conans import ConanFile, tools
from conan.tools.meson import Meson, MesonToolchain
class App(ConanFile):
settings = "os", "arch", "compiler", "build_type"
options = {"shared": [True, False], "fPIC": [True, False]}
default_options = {"shared": False, "fPIC": True}
def config_options(self):
if self.settings.os == "Windows":
del self.options.fPIC
def layout(self):
self.folders.build = "build"
def generate(self):
tc = MesonToolchain(self, backend='vs')
tc.generate()
def build(self):
meson = Meson(self)
meson.configure()
meson.build()
""") that is missing the |
If it is not clear, a recipe like this:
Produces this error:
|
The previous Meson integration is legacy, it has a few issues, but cannot be modified without breaking. So all the build system integrations are going to be fully replaced with the new ones, in the |
Also, it seems you are referencing to the latest docs, but the latest Conan does not have the constructor arguments you are using, check: https://docs.conan.io/en/latest/reference/conanfile/tools/meson.html#constructor: def __init__(self, conanfile, backend=None): So the |
For your reference I copy pasted this onto my computer and ran the same set of commands I normally use to install and compile with meson, I get this error:
So something seems odd. conan version is 1.44.0 Commands to run:
|
Oh, which Meson version are your using? Maybe it could be your Meson not supporting this? |
0.60.3 |
I am on a git bash terminal, is the command expecing a cmd maybe? It happens inside a cmd as well |
In my honest opinion this new design seems to suffer from taking on too much responsibility. The old design was better in that it was a thin wrapper that just let you pass what you needed straight through to meson. Conan's value proposition is to be a package manager, not a build system. In my opinion it should delegate as much as possible to the build system. The legacy code seemed, to me, near perfect, except for an explicit check that was unnecessary. In other words, conan was almost perfect and the only time it wasn't was because it took more responsibility than it needed.
My honest feedback, conan should just pass the user arguments straight to meson and be as transparent as possible. It is less burden on the tool, the conan developers and conan users. Users know how to use meson and it;s less frustrating and less error prone to just let them use the tool directly, that way they can setup the compilation commands the way that their program needs. As a user I am not sure what:
Is trying to do, that's already a problem as the way I use meson and the way conan wants to use it iffer, complicating my build process. Moreover this new tool seems to be setting up a bunch of scary files: I see these files being generated by the new command
They dont seem to be generated by the old tool'. The fact that conan is moving in a direction where it needs to autogen bat files is spooky. They don;t do much but imho it;s symptomatic of overengineering. |
Hi @Makogan Sorry for all the failing points, I know that's a bit frustrating 😞 Let me put here all the steps to try to have something simple working fine from your side. Let's imagine that we have this project structure in another empty folder to be sure that it's clean:
Where the
Then, the from conans import ConanFile, tools
from conan.tools.meson import Meson, MesonToolchain
class App(ConanFile):
settings = "os", "arch", "compiler", "build_type"
options = {"shared": [True, False], "fPIC": [True, False]}
default_options = {"shared": False, "fPIC": True}
def layout(self):
self.folders.build = "build"
def generate(self):
tc = MesonToolchain(self, backend="vs2019")
tc.generate()
def build(self):
meson = Meson(self)
meson.configure()
meson.build() Now, if you run the commands that you already put in your previous comment: $ conan install . -if build_visual_studio_debug/ -s build_type=Debug -s compiler.runtime=MDd -s compiler="Visual Studio" -s compiler.version=17 --build=missing
$ conan build . -if build_visual_studio_debug/ Let's try this simple approach at first to see if it's working without any kind of odd problem. |
I have wanted to do a |
Sorry if my reply was too brusque I did mean what I say but I was trying to give honest feedback, it might have sounded a little ranty. On any case I did make a repository as suggested with exactly 3 files:
The conan file is almost the same as the one you suggested except the build directory is different to match the one in my commands. This is the meson:
And the main.cpp is your typical hello world. I run the commands and I get the same error:
I really appreciate the help and I think conan is an awesome tool and I am grateful for it. Please understand, my prior feedback is not just frustration, it is my legitimate belief that tools should not do my work for me, they should just make it easier to do my work. When tools start to take power away from me to try to make my life easier all they accomplish is to prevent me from designing solutions that solve my needs. I really do mean, from a sober perspective, the legacy design was better. I don't like that conan needs to create all of these intermediary bat files and this Please, I am saying this as a legitimate concern, as a user, as someone whose life has been made better by the tool, please consider returning to the old design. Please keep conan transparent. There is no need for this additional functionality. I used to handle my dependencies through a python script I wrote myself, it wasn't fun, conan made my life better by handling the package management for me, I don't want to go back to writing my own tool. But the reality is, if conan moves in a direction where it opaques what it's doing and tries to solve my problems for me then my own technical constraints may force me to not use the tool :C. If I cannot understand how conan delivers commands to meson or if conan assembles itself in a way that is too dissimilar to how meson should be run without the wrapper then the tool would no longer be able to serve the needs of the project I work on. Once more thank you so much for your patience and help, please consider my feedback if possible. |
To stress how close to working the prior design was I hacked conan just a little bit this is what the "_run_ninja_commands" looks like:
This works just fine, it's such a minor change. In order to presserve backwards compatibility all it;s needed is to add a new command and an if statment checking the backend |
I made a pull request, the change is so small this should not break compatibility, it handles a strict superset of cases: |
Hi @Makogan Thanks a lot for your feedback and the PR (we have to review it), they are really appreciated for sure. After figuring it out, I just realized what was really going on. I did not get why you were receiving this output:
It was not happening on my side because I was using the |
That's nice to hear but I am still a little worried that the file needs to be made in the first place. As mentioned, I really think the "legacy" implementation was the right design. |
No, it is not. We have tons of evidence that the previous design was harming many developers. The main reason is that it couples the build to Conan completely, unless you call This approach is exactly the same that has been already deployed to other build systems, like CMake, and so far the feedback is very solid it is a step in the right direction. We apologize for the inconvenience and the frustration of the migration attempt, it is true, that MesonToolchain is behind other integrations, but we will get there soon too, and we are positive that it will be smoother and a better integration than the current one. |
Thanks for contributing @Makogan 😄 It will be released in the next Conan 1.45. |
Reading the docs https://docs.conan.io/en/latest/reference/build_helpers/meson.html
It would seem conan assumes that meson will always use ninja as the build backend. However meson allows you to build using msvc through the flan
--backend
.This means that the following meson command:
meson setup build_vs --backend=vs2019 -Dpkg_config_path=build_vs
Cannot be assembled from the conan.py script.
If you try something like this:
You will get this error:
The text was updated successfully, but these errors were encountered: