[Mesa-dev] last call for autotools

Tapani Pälli tapani.palli at intel.com
Wed Feb 6 06:20:14 UTC 2019



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.


> Thanks,
> Marek
> 
> On Sun, Dec 23, 2018 at 9:32 PM Ilia Mirkin <imirkin at alum.mit.edu 
> <mailto:imirkin at alum.mit.edu>> wrote:
> 
>     On Wed, Dec 19, 2018 at 1:30 PM Dylan Baker <dylan at pnwbakers.com
>     <mailto:dylan at 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 <eric at anholt.net
>     <mailto:eric at anholt.net>> wrote:
>      > > >>
>      > > >>      Eero Tamminen <eero.t.tamminen at intel.com
>     <mailto:eero.t.tamminen at 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 at lists.freedesktop.org <mailto:mesa-dev at lists.freedesktop.org>
>     https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 
> 
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 


More information about the mesa-dev mailing list