search

apache / buildstream-plugins

BuildStream plugins
https://buildstream.build/
Apache License 2.0
4 stars 5 forks source link

Fix deprecation warning for Meson #38

Closed nanonyme closed 1 year ago

nanonyme commented 1 year ago

See https://github.com/mesonbuild/meson/commit/3c7ab542c0c4770241eae149b0d4cd8de329aee0

nanonyme commented 1 year ago

Turns out we're been doing it wrong since Meson 0.42.

eli-schwartz commented 1 year ago

"Doing it wrong since Meson 0.42" would imply that we actually informed users of that for the last 5 years. :rofl:

As a matter of compatibility, it is however true that making this change works since relatively forever.

nanonyme commented 1 year ago

Yeah, that's kind of what I was going for. This is unlikely to break anything (except cache keys) and the deprecated way will eventually go away so it's better to do it now when majority of users still use BuildStream 1 and not BuildStream 2.

nanonyme commented 1 year ago

@eli-schwartz your point is valid though. I probably would not have noticed this being deprecated now either if gstreamer doc created hadn't broken with update to Meson 0.64.1.

abderrahim commented 1 year ago

I'm tempted to change ninja too (and use meson compile and meson install instead).

Not sure what @gtristan would think of this, but it at least implies we need to block the buildstream-plugins 2.0 release.

nanonyme commented 1 year ago

I agree but if we do that, we should also change API which is forbidden kind of

nanonyme commented 1 year ago

It's not great going towards something that should last next decade with legacy ways of doing things.

eli-schwartz commented 1 year ago

meson compile is a questionable python wrapper that imports tens of thousands of lines of code, then immediately executes ninja. It basically exists to be better in documentation for people that don't want to explain in README.md how to run msbuild on Windows. There is nothing you can do with meson compile that ninja doesn't do better. I would always just run ninja.

meson install is the other way around. ninja install runs meson install as a convenience wrapper (and will never go away) and while the two are effectively the same, it's useful to run meson directly if you need to pass options such as meson install --tags runtime. I would say either one is fine.

nanonyme commented 1 year ago

It would probably be most reasonable if the variables (API) were meson-build and meson-install and former would directly invoke ninja whereas latter would invoke meson install. The fact meson-build directly invokes ninja is an implementation detail and you could override it to something completely different.

nanonyme commented 1 year ago

@abderrahim can we merge this though? I can make new PR that is explicitly about changing API.