I have a patch series pending review to add support for pkg_config_path as a -Doption (or in your native/cross file, if you like that better).
Quoting Tapani Pälli (2019-02-05 22:20:14) > > > On 2/5/19 8:20 PM, Marek Olšák wrote: > > PKG_CONFIG_PATH still seems to be forgotten by meson. Is there an > > alternative? > > Maybe this can be worked out since at least for me it seems to complain > that 'different PKG_CONFIG_PATH' was used when configuring last time: > > WARNING: PKG_CONFIG_PATH has changed between invocations from "" to > "/home/tpalli/mesa/lib64/pkgconfig/" > > so it is stored .. somewhere. It's literally just stored on initial config and if reconfigure happens and it's changed then it complains. :( Dylan > > > > Thanks, > > Marek > > > > On Sun, Dec 23, 2018 at 9:32 PM Ilia Mirkin <imir...@alum.mit.edu > > <mailto:imir...@alum.mit.edu>> wrote: > > > > On Wed, Dec 19, 2018 at 1:30 PM Dylan Baker <dy...@pnwbakers.com > > <mailto:dy...@pnwbakers.com>> wrote: > > > > > > Quoting Nicolai Hähnle (2018-12-18 09:37:43) > > > > On 17.12.18 23:46, Dylan Baker wrote: > > > > > Quoting Marek Olšák (2018-12-17 12:25:29) > > > > >> On Mon, Dec 17, 2018 at 1:18 PM Eric Anholt <e...@anholt.net > > <mailto:e...@anholt.net>> wrote: > > > > >> > > > > >> Eero Tamminen <eero.t.tammi...@intel.com > > <mailto:eero.t.tammi...@intel.com>> writes: > > > > >> > > > > >> > Hi, > > > > >> > > > > > >> > On 17.12.2018 8.08, Marek Olšák wrote: > > > > >> > [...] > > > > >> >> I think one of the serious usability issues is that > > environment > > > > >> >> variables such as CFLAGS, CXXFLAGS, LDFLAGS, and > > PKG_CONFIG_PATH are not > > > > >> >> saved by meson for future reconfigures. > > > > >> > > > > > >> > I don't know what Meson is supposed to do, but to me > > that would be > > > > >> > a bug in a build tool. > > > > >> > > > > > >> > Re-configure is supposed to adapt SW to the changes > > in the build > > > > >> > environment, and environment variables are part of > > that (along with > > > > >> > command line options and SW installed to to the > > system). Build > > > > >> > configure tool deciding to "remember" some of those > > things instead > > > > >> > of checking the new situation, seems like a great > > opportunity for > > > > >> > confusion. > > > > >> > > > > >> A user-triggered reconfigure, sure. Recapture env vars > > then. But "git > > > > >> pull; ninja -C build" losing track of the configuration > > state is broken. > > > > >> We don't have to specify all of your meson > > -Doption=state configuration > > > > >> on every build, why should you need to specify your > > PKG_CONFIG_PATH > > > > >> configure options on every build? > > > > >> > > > > >> > > > > >> Thanks, Eric. > > > > >> > > > > >> Yes, meson behaves such that users have to set all > > environment variables for > > > > >> every "ninja" command that might reconfigure. > > > > >> > > > > >> I see 2 solutions: > > > > >> 1) meson needs to remember the relevant env vars > > > > >> 2) meson should FAIL to configure if any of the env vars are > > set (if it wants > > > > >> to ignore them) > > > > >> > > > > >> Marek > > > > > > > > > > Meson does remember the *_FLAGS variables. Those are > > translated on configure > > > > > into meson's internal ${lang}_args and ${lang}_link args. It > > does look like > > > > > those aren't remembered when --wipe is called though, I filed > > a bug for that: > > > > > https://github.com/mesonbuild/meson/issues/4650 > > > > > > > > I ran into this same problem and noticed that Meson is already > > able to > > > > *warn* about such changes. > > > > > > > > It should either ignore the changes, or better yet, fail. > > > > > > > > (Or even better: ignore environment variables entirely; IMO > > sourcing the > > > > environment implicitly in a build system with an explicit > > configure is > > > > just a broken design that was unfortunately inherited from > > plain make > > > > without really considering the UI implications.) > > > > > > I agree with this, as do most of the upstream meson developers. > > So do the > > > autotools developers, who recommend passing CFLAGS (and friends) > > as arguments > > > instead of as env variables: > > > > > > ./configure CFLAGS='-march=native -03' LDFLAGS='-O3' --enable-foo > > > > > > meson supports this using: > > > > > > meson -Dc_args='-march-native' -Dc_link_args='-O3' -Dfoo=true > > > > > > Meson basically inherited this from autotools, and in hindsight > > we shouldn't > > > have. > > > > > > I'm going to do 3 things I think: > > > - Update our documentation to strongly recommend -Dc_args and not > > CLFAGS > > > - Push for meson to warn about using environment variables and > > recommend command > > > line options. > > > - Push for meson to remove CFLAGS and friends support: > > > https://github.com/mesonbuild/meson/issues/4664 > > > > FWIW when I was talking about env vars, I was very much referring to > > > > ./configure CFLAGS=..., not the CFLAGS=... ./configure variant -- > > that's fraught with peril. > > > > An especially important one to be able to bake in is > > PKG_CONFIG_PATH. Having support for just doing it rather than > > knowing what the mapping to meson is would be rather preferable -- e.g. > > > > meson CFLAGS=... > > _______________________________________________ > > mesa-dev mailing list > > mesa-dev@lists.freedesktop.org <mailto:mesa-dev@lists.freedesktop.org> > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > > > > > > _______________________________________________ > > mesa-dev mailing list > > mesa-dev@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > > > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
signature.asc
Description: signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
