Skip to content
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] meson toolchain doesn't support debug built-in option #15408

Open
1 task done
lukester1975 opened this issue Jan 7, 2024 · 4 comments
Open
1 task done

[feature] meson toolchain doesn't support debug built-in option #15408

lukester1975 opened this issue Jan 7, 2024 · 4 comments

Comments

@lukester1975
Copy link
Contributor

What is your suggestion?

Hi

I'm not sure if this is intentional, but is seems the meson toolchain doesn't support the debug (i.e. debug info) built-in option. However, it is in the template:

{% if debug %}debug = {{debug}}{% endif %}

but MesonToolchain._context() never returns a debug property so it's never rendered into the native/cross file, AFAICT.

It looks like meson are starting to rework the buildtype/debug(info) options, so even if unintentional maybe you want to wait for those changes? FWIW, for my own purposes I've just hacked MesonToolchain._context() to include:

"debug": to_meson_value(self._debug),

such that in my conanfile's generate() I can meson_toolchain._debug = True. Pretty hacky I'm sure, but at least works for now...

Thanks

Have you read the CONTRIBUTING guide?

  • I've read the CONTRIBUTING guide
@memsharded
Copy link
Member

Hi @lukester1975

Thanks for your suggestion.

It doesn't really seem accidental, these are the relevant lines:

       self._buildtype = {"Debug": "debug",  # Note, it is not "'debug'"
                           "Release": "release",
                           "MinSizeRel": "minsize",
                           "RelWithDebInfo": "debugoptimized"}.get(build_type, build_type)
        self._b_ndebug = "true" if self._buildtype != "debug" else "false"

        # https://mesonbuild.com/Builtin-options.html#core-options
        # Do not adjust "debug" if already adjusted "buildtype"

So there is a note that if build_type has been defined above, then the debug shouldn't be set. The Meson docs read:

For setting optimization levels and toggling debug, you can either set the buildtype option, or you can set the optimization and debug options which give finer control over the same. Whichever you decide to use, the other will be deduced from it. For example, -Dbuildtype=debugoptimized is the same as -Ddebug=true -Doptimization=2 and vice-versa. This table documents the two-way mapping:

So it seems that using the build_type should be enough?

It looks like meson are starting to rework the buildtype/debug(info) options, so even if unintentional maybe you want to wait for those changes?

Yes, it would be good to know and understand what is the current expectation and what are the plans for the future.

@lukester1975
Copy link
Contributor Author

Yeah I saw that comment but I don't think it makes sense really - let meson worry about whether the options are sane :)

And despite what the meson docs say, I think it does make sense to set both buildtype and debug - the problem with the current meson implementation is debugoptimized is not the same as release (O2 vs O3). It's a while since I looked at it, but I think there was a reason optimization=2 debug wasn't "right" either and I settled on buildtype=release debug (possibly it didn't set NDEBUG; i.e. literally just set the -O compiler option).

I think they've realised the error of not emitting debuginfo by default for a release build, so like I say whether it makes sense to wait for their changes (some in mesonbuild/meson#12699 I guess) I couldn't say...

Hopefully they'll rename the option --debuginfo too!

Thanks

@memsharded
Copy link
Member

And despite what the meson docs say, I think it does make sense to set both buildtype and debug

I understand the intention, but we strongly think Conan shouldn't ignore the tools that is using documentation, but quite the opposite. We try quite hard to respect the "upstream" libraries and tools names, conventions, docs, etc. following as much as possible their guidelines, recommended practices, etc. Because trying to workaround their possible issues, bugs or limitations of such tools within Conan code and integration is bad in our experience, it almost always leads to issues, confusion, more support tickets, maintenance, etc, and we cannot afford that.

So yes, I'd definitely prefer to wait for them to stabilize their behavior (and criteria and docs), before doing something in the Conan integration that is explicitly against the current tool documentation, even if we believed it made sense.

@lukester1975
Copy link
Contributor Author

Any chance you could have a rethink? Who knows when meson might be sorted out in a released version (some of those issues are pretty old). Meson's runtime message is:

Recommend using either -Dbuildtype or -Doptimization + -Ddebug. Using both is redundant since they override each other.

I.e. it's only a recommendation, and an invalid one (another link: mesonbuild/meson#9540).

Just to clarify: I'm not asking for you to change conan's default behaviour here. Whilst I think you should (RelWithDebInfo is not the same as Release with debug info due to the different optimization level - and that's surely worse than ignoring a bad meson warning. How many users might be missing out on an optimization level due to assuming RelWithDebInfo is just Release with -g?), but all I want is a way to get debug rendered in the native file when I want it. I can live with my hack, but would rather use vanilla upstream conan.

For me, one of the nice things about conan is all the customization points that allow working around various foibles - but this one seems intractable. It's not like meson's suggestion of using --optimization=N --debug instead of --buildtype=release --debug can be used, as --optimization isn't supported and --buildtype appears to always be rendered, right?

From the myriad meson issues on the topic, I'd say it's only a matter of time before you have to implement rendering debug anyway as it seems they are moving to optimization and debug and only inferring buildtype from those. Otherwise, maybe remove the debug option from _meson_file_template? Unless I'm missing something, it's pointless as-is.

Thanks!

PS I looked into my distant memory that it was NDEBUG that is broken with --optimization vs --buildtype in meson and this is indeed true, when using the b_ndebug=if-release option. That only sets NDEBUG when the buildtype is release (or plain, for whatever reason that might be!). I guess you may have tripped over this yourselves, given that self._b_ndebug = "true" if self._buildtype != "debug" else "false".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants