Re: [Mesa-dev] last call for autotools

[Dylan Baker]

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  > > wrote:
> > 
> > On Wed, Dec 19, 2018 at 1:30 PM Dylan Baker  > > 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  > > wrote:
> >  > > >>
> >  > > >>      Eero Tamminen  > > 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

Re: [Mesa-dev] last call for autotools

[Tapani Pälli]

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 > wrote:


On Wed, Dec 19, 2018 at 1:30 PM Dylan Baker 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 mailto:e...@anholt.net>> wrote:
 > > >>
 > > >>      Eero Tamminen 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 

Re: [Mesa-dev] last call for autotools

[Marek Olšák]

Another usability issue is that meson doesn't re-run llvm-config when
auto-reconfiguring.

Marek

On Tue, Feb 5, 2019 at 1:20 PM Marek Olšák  wrote:

> PKG_CONFIG_PATH still seems to be forgotten by meson. Is there an
> alternative?
>
> Thanks,
> Marek
>
> On Sun, Dec 23, 2018 at 9:32 PM Ilia Mirkin  wrote:
>
>> On Wed, Dec 19, 2018 at 1:30 PM Dylan Baker  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 
>> wrote:
>> > > >>
>> > > >>  Eero Tamminen  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
>> 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

Re: [Mesa-dev] last call for autotools

[Marek Olšák]

PKG_CONFIG_PATH still seems to be forgotten by meson. Is there an
alternative?

Thanks,
Marek

On Sun, Dec 23, 2018 at 9:32 PM Ilia Mirkin  wrote:

> On Wed, Dec 19, 2018 at 1:30 PM Dylan Baker  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 
> wrote:
> > > >>
> > > >>  Eero Tamminen  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
> 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

Re: [Mesa-dev] last call for autotools

[Ilia Mirkin]

On Wed, Dec 19, 2018 at 1:30 PM Dylan Baker  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  wrote:
> > >>
> > >>  Eero Tamminen  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
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] last call for autotools

[Dave Airlie]

On Tue, 18 Dec 2018 at 06:26, Marek Olšák  wrote:
>
> On Mon, Dec 17, 2018 at 1:18 PM Eric Anholt  wrote:
>>
>> Eero Tamminen  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)
>

I just wanted to note here that autotools was broken for a long time
in this area.

for ages it would rerun configure and lose PKG_CONFIG_PATH, and I
still think it doesn't remember PATH when you rerun, as I've had it
jump between my llvm versions when I haven't set the correct path.

Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] last call for autotools

[Dylan Baker]

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  wrote:
> >>
> >>  Eero Tamminen  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

Dylan


signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] last call for autotools

[Nicolai Hähnle]

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  wrote:

 Eero Tamminen  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.)


Cheers,
Nicolai




Dylan


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev



--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] last call for autotools

[Dylan Baker]

Quoting Marek Olšák (2018-12-17 12:25:29)
> On Mon, Dec 17, 2018 at 1:18 PM Eric Anholt  wrote:
> 
> Eero Tamminen  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

Dylan


signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] last call for autotools

[Marek Olšák]

On Mon, Dec 17, 2018 at 1:18 PM Eric Anholt  wrote:

> Eero Tamminen  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
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] last call for autotools

[Eric Anholt]

Eero Tamminen  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?


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] last call for autotools

[Dylan Baker]

Quoting Kai Wasserbäch (2018-12-17 07:48:38)
> Hey Dylan,
> Dylan Baker wrote on 11.12.18 00:10:
> > Meson 0.49.0 has been out for a couple of days now, and I'd like to make the
> > final call for autotools. My patch is so massive that it's a huge pain to 
> > send
> > to the list, the latest versions is here:
> > https://gitlab.freedesktop.org/dbaker/mesa/commits/delete-autotools
> 
> I've switched to building with meson now and everything seems to work for my
> environment, including the usage of a particular LLVM version.
> 
> I've noticed, that Debian carries the changes from
>  as local patches. It would
> probably be good, if those patches land before autotools support is nuked.
> 
> Also: meson complains that deprecated features are used:
>  - DEPRECATION: Project targetting '>= 0.45' but tried to use feature 
> deprecated
> since '0.48.0': python3 module
>  - DEPRECATION: build_always is deprecated. Combine build_by_default and
> build_always_stale instead.
> 
> Can these be fixed before making meson mandatory? Or are they completely
> harmless and won't break builds?

These are both cases of overly aggressive error messages. build_aways was
deprecated in 0.47 which is newer than 0.45 (which is our current oldest
supported version of meson). There is an issue filed against meson about not
printing the deprecated message in these cases, it looks like there's just a
couple of issues to iron out:

https://github.com/mesonbuild/meson/pull/4362

> 
> This leaves me with a feature request: the autotools build generated a
> configuration summary at the end, which is helpful in checking if changes to 
> the
> configuration in my debian/rules file are actually propagated to the build or 
> if
> something went wrong. Could the meson build provide such a summary as well?
> 
> Cheers,
> Kai
> 


signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] last call for autotools

[Dylan Baker]

Quoting Gert Wollny (2018-12-16 03:57:48)
> Am Freitag, den 14.12.2018, 13:11 +0100 schrieb Gert Wollny:
> > Am Freitag, den 14.12.2018, 01:19 -0500 schrieb Ilia Mirkin:
> > > I have to say that the user experience for autotools is WAY better
> > > than for meson. As a concrete example, I had a meson build. Then I
> > > updated meson (0.48.1 to 0.48.2). Now ninja -C foo doesn't work.
> > > meson
> > > --reconfigure (which presumably is what ninja would end up running)
> > > doesn't work. http://paste.debian.net/hidden/cf777f3e/
> > 
> > I think that was fixed with this PR (although I so far I didn't try
> > to use this new feature, so I don't know how well it works):
> >   https://github.com/mesonbuild/meson/pull/4356
> > The error message should probably be updated accordingly. 
> 
> Today I updated to 0.49 (from 0.47) and there it didn't work (the file
> meson-private/cmd_line.txt was missing), so my guess this is only
> availabe for builds that were already created with 0.49.

Yes, the build has to be configured with 0.49 to have a cmd_line.txt

> 
> However, there it doesn't work for me: 
> https://bugs.freedesktop.org/show_bug.cgi?id=109071

I'll look at that, it doesn't look good

Dylan

> 
> Best,
> Gert
> 


signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] last call for autotools

[Jason Ekstrand]

On Mon, Dec 17, 2018 at 8:54 AM Eero Tamminen 
wrote:

> 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.
>

I think both ways of looking at this particular issue are at least
partially valid and this is exactly why meson recommends you don't set
those options via environment variables.  Even with autotools provides a
mechanism to set those things as part of the command (by putting CFLAGS= as
a parameter) rather than the environment.  If you pay attention to the
command in config.log (and the one you use for reconfigure), it moves them
to the explicit argument format.  I think the real answer here is to tell
people to stop using CFLAGS in the environment.

--Jason
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] last call for autotools

[Kai Wasserbäch]

Hey Dylan,
Dylan Baker wrote on 11.12.18 00:10:
> Meson 0.49.0 has been out for a couple of days now, and I'd like to make the
> final call for autotools. My patch is so massive that it's a huge pain to send
> to the list, the latest versions is here:
> https://gitlab.freedesktop.org/dbaker/mesa/commits/delete-autotools

I've switched to building with meson now and everything seems to work for my
environment, including the usage of a particular LLVM version.

I've noticed, that Debian carries the changes from
 as local patches. It would
probably be good, if those patches land before autotools support is nuked.

Also: meson complains that deprecated features are used:
 - DEPRECATION: Project targetting '>= 0.45' but tried to use feature deprecated
since '0.48.0': python3 module
 - DEPRECATION: build_always is deprecated. Combine build_by_default and
build_always_stale instead.

Can these be fixed before making meson mandatory? Or are they completely
harmless and won't break builds?

This leaves me with a feature request: the autotools build generated a
configuration summary at the end, which is helpful in checking if changes to the
configuration in my debian/rules file are actually propagated to the build or if
something went wrong. Could the meson build provide such a summary as well?

Cheers,
Kai



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] last call for autotools

[Eero Tamminen]

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.


- Eero


I think meson should ignore the 
variables completely, or the Mesa documentation should discourage users 
from the setting the variables. The current situation would be 
acceptable to me if users were warned that setting environment variables 
is a trap.

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] last call for autotools

[Marek Olšák]

On Sun, Dec 16, 2018 at 9:19 PM Marek Olšák  wrote:

> On Thu, Dec 13, 2018 at 7:48 PM Dylan Baker  wrote:
>
>> Quoting Marek Olšák (2018-12-13 11:28:10)
>> > Another issue with meson is this:
>> >
>> > I have to set PKG_CONFIG_PATH when I type meson for 32-bit builds. If I
>> do
>> > meson configure --clearcache and then type "ninja", it will
>> reconfigure, but
>> > will use 64-bit libraries instead because PKG_CONFIG_PATH is not set
>> when ninja
>> > is run, which will fail to link.
>> >
>> > Luckily, at least CC="gcc -m32" and CXX="g++ -m32" weren't wiped out by
>> > --clearcache.
>> >
>> > Additionally, it would be nice if the default build type was release
>> instead of
>> > plain.
>> >
>> > Thanks,
>> > Marek
>> >
>> > On Mon, Dec 10, 2018 at 6:11 PM Dylan Baker 
>> wrote:
>> >
>> > Meson 0.49.0 has been out for a couple of days now, and I'd like to
>> make
>> > the
>> > final call for autotools. My patch is so massive that it's a huge
>> pain to
>> > send
>> > to the list, the latest versions is here:
>> > https://gitlab.freedesktop.org/dbaker/mesa/commits/delete-autotools
>> >
>> > Dylan
>> > ___
>> > mesa-dev mailing list
>> > mesa-dev@lists.freedesktop.org
>> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>> >
>>
>> I've had much better luck using a cross file for doing x86 builds on
>> x86_64, I
>> believe I've posted my cross file before but I can do so again.
>>
>
> Can this possibly be documented in the Mesa docs? The current
> documentation is misleading (LLVM and PKG_CONFIG_PATH sections) and missing
> other information.
>

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 think meson should ignore the variables
completely, or the Mesa documentation should discourage users from the
setting the variables. The current situation would be acceptable to me if
users were warned that setting environment variables is a trap.

Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] last call for autotools

[Marek Olšák]

On Thu, Dec 13, 2018 at 7:48 PM Dylan Baker  wrote:

> Quoting Marek Olšák (2018-12-13 11:28:10)
> > Another issue with meson is this:
> >
> > I have to set PKG_CONFIG_PATH when I type meson for 32-bit builds. If I
> do
> > meson configure --clearcache and then type "ninja", it will reconfigure,
> but
> > will use 64-bit libraries instead because PKG_CONFIG_PATH is not set
> when ninja
> > is run, which will fail to link.
> >
> > Luckily, at least CC="gcc -m32" and CXX="g++ -m32" weren't wiped out by
> > --clearcache.
> >
> > Additionally, it would be nice if the default build type was release
> instead of
> > plain.
> >
> > Thanks,
> > Marek
> >
> > On Mon, Dec 10, 2018 at 6:11 PM Dylan Baker  wrote:
> >
> > Meson 0.49.0 has been out for a couple of days now, and I'd like to
> make
> > the
> > final call for autotools. My patch is so massive that it's a huge
> pain to
> > send
> > to the list, the latest versions is here:
> > https://gitlab.freedesktop.org/dbaker/mesa/commits/delete-autotools
> >
> > Dylan
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >
>
> I've had much better luck using a cross file for doing x86 builds on
> x86_64, I
> believe I've posted my cross file before but I can do so again.
>

Can this possibly be documented in the Mesa docs? The current documentation
is misleading (LLVM and PKG_CONFIG_PATH sections) and missing other
information.

Thanks,
Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] last call for autotools

[Gert Wollny]

Am Freitag, den 14.12.2018, 13:11 +0100 schrieb Gert Wollny:
> Am Freitag, den 14.12.2018, 01:19 -0500 schrieb Ilia Mirkin:
> > I have to say that the user experience for autotools is WAY better
> > than for meson. As a concrete example, I had a meson build. Then I
> > updated meson (0.48.1 to 0.48.2). Now ninja -C foo doesn't work.
> > meson
> > --reconfigure (which presumably is what ninja would end up running)
> > doesn't work. http://paste.debian.net/hidden/cf777f3e/
> 
> I think that was fixed with this PR (although I so far I didn't try
> to use this new feature, so I don't know how well it works):
>   https://github.com/mesonbuild/meson/pull/4356
> The error message should probably be updated accordingly. 

Today I updated to 0.49 (from 0.47) and there it didn't work (the file
meson-private/cmd_line.txt was missing), so my guess this is only
availabe for builds that were already created with 0.49.

However, there it doesn't work for me: 
https://bugs.freedesktop.org/show_bug.cgi?id=109071

Best,
Gert

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] last call for autotools

[Matt Turner]

On Fri, Dec 14, 2018 at 11:40 AM Ilia Mirkin  wrote:
>
> On Fri, Dec 14, 2018 at 11:32 AM Matt Turner  wrote:
> >
> > On Fri, Dec 14, 2018 at 4:12 AM Gert Wollny  wrote:
> > > I second that, I voiced my concerns in a former thread, especially that
> > > so far this upcoming change has not been officially announced in the
> > > release notes or on mesa-user, and that I don't understand why it is so
> > > urgent to drop autotools when there is still someone who offers to
> > > maintain it and some who prefer to use it.
> >
> > It's because the objective is to have as few build systems as
> > necessary. This is an obvious first step and has been a stated goal
> > for more than a year. I'm surprised that you're surprised.
> >
> > Let's just make an external contrib repo and keep all the autotools
> > files there. Then Emil and company can continue having fun maintaining
> > autotools and all you'll need to do is rsync into the Mesa repo to use
> > autotools.
>
> So ... not last call for autotools? More like "railroad notification
> that the train is in motion"?

I wouldn't say that, but I think it is pretty apparent that people
haven't attempted to switch before some of these recent discussions.
So.. not sure how better to handle it.

> This kind of talk just causes everyone to entrench into their
> positions, so I'd rather avoid it. I'm not opposed to switching build
> systems in principle, but the current proposal is, in my and seemingly
> some other people's views, inadequate. Let's make it adequate before
> dropping the thing that works for everyone.

How can we make it adequate if people never even test the thing we've
been talking about deleting autotools in favor or for 15 months?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] last call for autotools

[Dylan Baker]

Quoting Dave Airlie (2018-12-14 12:27:35)
> On Fri, 14 Dec 2018 at 16:19, Ilia Mirkin  wrote:
> >
> > I have to say that the user experience for autotools is WAY better
> > than for meson. As a concrete example, I had a meson build. Then I
> > updated meson (0.48.1 to 0.48.2). Now ninja -C foo doesn't work. meson
> > --reconfigure (which presumably is what ninja would end up running)
> > doesn't work. http://paste.debian.net/hidden/cf777f3e/
> >
> > So now what? I don't remember how that config was done, except that it
> > was done the way I decided I needed it at the time. I have no way to
> > recover it. With autotools, in such cases (which are immensely rare),
> > you just run "head config.log" and it tells you what you did last
> > time. And by updating the build component, now I have to rebuild
> > EVERYTHING?
> >
> > meson is not at a point where it Just Works. It ... sometimes works.
> > The fact that everyone has scripts which wrap meson is a symptom of
> > that. I don't feel good about dumping the system that everyone (and I
> > don't just mean people on this list -- I mean the wider open source
> > community as well) knows how to use and has worked reliably for years
> > (decades, really) to be replaced by a system that everyone is having
> > problems with (it's not just me -- others are running into trouble too
> > -- just look at this thread). It's just not ready yet.
> >
> 
> I've kinda stayed out of this discussion as I wanted to see which way
> the wind was blowing, and I like to tune my workflows to the project
> not vice-versa as much as possible.
> 
> At this point I don't like using meson in my workflows for two main
> reasons: (mostly like Ilia)
> 
> a) meson upgrades crap out my builddirs. (0.49 will fix it? then yay
> when 0.49 lands in distros, I'll consider this done)

This is supposed to be fixed in 0.49.0.

> b) I can't extract either the original configuration line or even a
> give me a command line to reproduce the current state so I can cut and
> paste it.

The fix for a) stores the information to get the configuration back (it's in an
ini file, so not great for readability). I can write a patch to print the line
in a printable form.

Dylan


signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] last call for autotools

[Dave Airlie]

On Fri, 14 Dec 2018 at 16:19, Ilia Mirkin  wrote:
>
> I have to say that the user experience for autotools is WAY better
> than for meson. As a concrete example, I had a meson build. Then I
> updated meson (0.48.1 to 0.48.2). Now ninja -C foo doesn't work. meson
> --reconfigure (which presumably is what ninja would end up running)
> doesn't work. http://paste.debian.net/hidden/cf777f3e/
>
> So now what? I don't remember how that config was done, except that it
> was done the way I decided I needed it at the time. I have no way to
> recover it. With autotools, in such cases (which are immensely rare),
> you just run "head config.log" and it tells you what you did last
> time. And by updating the build component, now I have to rebuild
> EVERYTHING?
>
> meson is not at a point where it Just Works. It ... sometimes works.
> The fact that everyone has scripts which wrap meson is a symptom of
> that. I don't feel good about dumping the system that everyone (and I
> don't just mean people on this list -- I mean the wider open source
> community as well) knows how to use and has worked reliably for years
> (decades, really) to be replaced by a system that everyone is having
> problems with (it's not just me -- others are running into trouble too
> -- just look at this thread). It's just not ready yet.
>

I've kinda stayed out of this discussion as I wanted to see which way
the wind was blowing, and I like to tune my workflows to the project
not vice-versa as much as possible.

At this point I don't like using meson in my workflows for two main
reasons: (mostly like Ilia)

a) meson upgrades crap out my builddirs. (0.49 will fix it? then yay
when 0.49 lands in distros, I'll consider this done)
b) I can't extract either the original configuration line or even a
give me a command line to reproduce the current state so I can cut and
paste it.

The solution everyone is giving me is hacks using locally prepared
scripts, which doesn't scale for me at all. Why am I different you
ask?

Unlike most people I work on nearly every driver in the tree, in GL
and Vulkan, in gallium, in sw drivers, and I do it all the time and I
do it across lots of machines.

Currently in my eyeline I have 5 regular work machines (3 desktops, 2
laptops), in my RH office I have currently 2 workstations and another
2 laptops, I regularly bring new machines in on other distros (Fedora
29 vs RHEL7 vs RHEL8), I regularly image machines from scratch in RH
network.

On one workstation I have lots of main work trees currently (mesa
master, vulkan dev, zink dev, opencl dev, iris dev, virgl dev, radv
wip trees), nuking builds and having to remember what command line I
used to configure them is a losing battle for my memory.

I really don't want to have special scripts that I have to remember to
bring with me across installs, the extra scripts you have are a
workaround for meson not a fix for my problem. scripts work fine if
you are just building anv, i965, when you move around a lot they suck.

So personally I don't think meson is going to enhance my workflow
until those two things get sorted out in the project, if (a) is
already solved, then maybe we can get upstream to solve (b), and
revisit the removal of autotools.

Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] last call for autotools

[Jason Ekstrand]

On Fri, Dec 14, 2018 at 11:25 AM Andre Heider  wrote:

> On 14/12/2018 17:53, Dylan Baker wrote:
> > Quoting Gert Wollny (2018-12-14 03:44:32)
> >> Am Montag, den 10.12.2018, 15:10 -0800 schrieb Dylan Baker:
> >> (2) It would be nice if Meson would distribute some default cross build
> >> files, currently everybody has to roll its own, and I guess in the end
> >> they all look mostly the same.
> >
> > Please ask your distro to write and distribute the cross files. It's
> simply
> > impossible for meson to distribute them for a huge number of reasons, but
> > basically it boils down to too many distros with too many differences. I
> have
> > done basically everything I can (personally) to make this easier,
> including
> > adding support for loading cross files from XDG paths
> (/usr/share/meson/cross,
> > etc)
> >
> >>
> >> (3) I also noted that with across build one has to set the library
> >> install directory manually, because it defaults to the directory used
> >> for the build machine - i.e. a i386 cross build on debian amd64 should
> >> set the lib install directory on Debian to "lib/i386-linux-gnu" but it
> >> sets it to "lib/x86_64-linux-gnu"
> >
> > There is this issue: https://github.com/mesonbuild/meson/issues/4008
> >
> > This is another case that is really hard to handle because of the way
> different
> > distros have handled installing x86 and x86_64 binaries on the same OS.
> To name
> > a few:
> > debian : lib/$gnu-tri/
> > arch   : lib/ + lib32/
> > fedora : lib64/ + lib32/
> >
> > I'm sure there are more, but getting that right all of the time is
> actually
> > pretty hard. I'll look into it.
>
> It's not just the libdir, there's no real way for a project to provide
> all the required cross settings so it works everywhere. Like the
> pkg-config binary name for e.g. cross-compiling 32bit binaries. I didn't
> find anything user friendly, so I worked around that on another project
> [0]. And I'm sure there's more.
>
> While all that is doable, it is annoying. Isn't there any way for meson
> to provide a standard set of cross files for distros? If it's the
> distro's responsibility to provide these without any guidelines it's
> just going to be another mess, because either a distro doesn't at all or
> they all do it differently.
>

I think it's very easy to mistake the way autotools handles things for
somehow being easier.  For quite some time now, Fedora has carried a
patched version of autools which has a special case to automatically
redirects you to lib64 if --prefix=/usr.  It's horrible because it means
that autotools behaves differently with every other possible prefix unless
you manually set libdir.  If they're going to carry patches against
autotools, they can carry a meson cross file.  Autotools is only "easier"
because distros have beat on it with a hammer until it mostly works.

--Jason
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] last call for autotools

[Dylan Baker]

Quoting Andre Heider (2018-12-14 09:24:56)
> On 14/12/2018 17:53, Dylan Baker wrote:
> > Quoting Gert Wollny (2018-12-14 03:44:32)
> >> Am Montag, den 10.12.2018, 15:10 -0800 schrieb Dylan Baker:
> >> (2) It would be nice if Meson would distribute some default cross build
> >> files, currently everybody has to roll its own, and I guess in the end
> >> they all look mostly the same.
> > 
> > Please ask your distro to write and distribute the cross files. It's simply
> > impossible for meson to distribute them for a huge number of reasons, but
> > basically it boils down to too many distros with too many differences. I 
> > have
> > done basically everything I can (personally) to make this easier, including
> > adding support for loading cross files from XDG paths 
> > (/usr/share/meson/cross,
> > etc)
> > 
> >>
> >> (3) I also noted that with across build one has to set the library
> >> install directory manually, because it defaults to the directory used
> >> for the build machine - i.e. a i386 cross build on debian amd64 should
> >> set the lib install directory on Debian to "lib/i386-linux-gnu" but it
> >> sets it to "lib/x86_64-linux-gnu"
> > 
> > There is this issue: https://github.com/mesonbuild/meson/issues/4008
> > 
> > This is another case that is really hard to handle because of the way 
> > different
> > distros have handled installing x86 and x86_64 binaries on the same OS. To 
> > name
> > a few:
> > debian : lib/$gnu-tri/
> > arch   : lib/ + lib32/
> > fedora : lib64/ + lib32/
> > 
> > I'm sure there are more, but getting that right all of the time is actually
> > pretty hard. I'll look into it.
> 
> It's not just the libdir, there's no real way for a project to provide 
> all the required cross settings so it works everywhere. Like the 
> pkg-config binary name for e.g. cross-compiling 32bit binaries. I didn't 
> find anything user friendly, so I worked around that on another project 
> [0]. And I'm sure there's more.
> 
> While all that is doable, it is annoying. Isn't there any way for meson 
> to provide a standard set of cross files for distros? If it's the 
> distro's responsibility to provide these without any guidelines it's 
> just going to be another mess, because either a distro doesn't at all or 
> they all do it differently.
> 
> [0] https://github.com/dhewg/nine/blob/master/bootstrap.sh
> 
> Thanks,
> Andre

We can provide some skeleton templates I guess, but most of what a cross file is
is just a list of binary locations and a name to pass to the --cross-file
option. This is just another pain point of there being mⁿ distros making subtly
different choices. We probably can ship cross files for MSVC or Apple's Clang
since we can make some pretty safe assumptions about how those are installed.

I can write some guidelines for distro cross files and add that to meson's
documentation if that's helpful.

Dylan


signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] last call for autotools

[Andre Heider]

On 14/12/2018 17:53, Dylan Baker wrote:

Quoting Gert Wollny (2018-12-14 03:44:32)

Am Montag, den 10.12.2018, 15:10 -0800 schrieb Dylan Baker:
(2) It would be nice if Meson would distribute some default cross build
files, currently everybody has to roll its own, and I guess in the end
they all look mostly the same.


Please ask your distro to write and distribute the cross files. It's simply
impossible for meson to distribute them for a huge number of reasons, but
basically it boils down to too many distros with too many differences. I have
done basically everything I can (personally) to make this easier, including
adding support for loading cross files from XDG paths (/usr/share/meson/cross,
etc)



(3) I also noted that with across build one has to set the library
install directory manually, because it defaults to the directory used
for the build machine - i.e. a i386 cross build on debian amd64 should
set the lib install directory on Debian to "lib/i386-linux-gnu" but it
sets it to "lib/x86_64-linux-gnu"


There is this issue: https://github.com/mesonbuild/meson/issues/4008

This is another case that is really hard to handle because of the way different
distros have handled installing x86 and x86_64 binaries on the same OS. To name
a few:
debian : lib/$gnu-tri/
arch   : lib/ + lib32/
fedora : lib64/ + lib32/

I'm sure there are more, but getting that right all of the time is actually
pretty hard. I'll look into it.


It's not just the libdir, there's no real way for a project to provide 
all the required cross settings so it works everywhere. Like the 
pkg-config binary name for e.g. cross-compiling 32bit binaries. I didn't 
find anything user friendly, so I worked around that on another project 
[0]. And I'm sure there's more.


While all that is doable, it is annoying. Isn't there any way for meson 
to provide a standard set of cross files for distros? If it's the 
distro's responsibility to provide these without any guidelines it's 
just going to be another mess, because either a distro doesn't at all or 
they all do it differently.


[0] https://github.com/dhewg/nine/blob/master/bootstrap.sh

Thanks,
Andre
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] last call for autotools

[Dylan Baker]

Quoting Gert Wollny (2018-12-14 03:44:32)
> Am Montag, den 10.12.2018, 15:10 -0800 schrieb Dylan Baker:
> > Meson 0.49.0 has been out for a couple of days now, and I'd like to
> > make the final call for autotools. My patch is so massive that it's a
> > huge pain to send to the list, the latest versions is here:
> > https://gitlab.freedesktop.org/dbaker/mesa/commits/delete-autotools
> 
> Well, 
> 
> (1) there is stil this Heisenbug that pops up there and then, and that
> I send a patch for some time ago [1]: 
> 
> [1088/1140] Linking target src/gallium/tests/trivial/quad-tex.
> FAILED: src/gallium/tests/trivial/quad-tex 
> g++  -o src/gallium/tests/trivial/quad-tex 'src/gallium/tests/trivial/s
> rc@gallium@tests@trivial@@quad-tex@exe/quad-tex.c.o' -Wl,--no-undefined 
> -Wl,--as-needed -Wl,--start-group src/util/libmesa_util.a
> src/gallium/auxiliary/libgallium.a src/gallium/auxiliary/pipe-
> loader/libpipe_loader_dynamic.a src/loader/libloader.a
> src/util/libxmlconfig.a /usr/lib64/libz.so -lm -Wl,--end-group
> /usr/lib64/libdrm.so -L/usr/lib64/llvm/6/lib64 -lLLVMAMDGPUDisassembler
> -lLLVMAMDGPUCodeGen -lLLVMAMDGPUAsmParser -lLLVMAMDGPUDesc
> -lLLVMAMDGPUInfo -lLLVMAMDGPUAsmPrinter -lLLVMAMDGPUUtils -lLLVMMCJIT
> -lLLVMExecutionEngine -lLLVMRuntimeDyld -lLLVMX86Disassembler
> -lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMGlobalISel -lLLVMSelectionDAG
> -lLLVMAsmPrinter -lLLVMDebugInfoCodeView -lLLVMDebugInfoMSF
> -lLLVMCodeGen -lLLVMTarget -lLLVMX86Desc -lLLVMMCDisassembler
> -lLLVMX86Info -lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMipo
> -lLLVMInstrumentation -lLLVMVectorize -lLLVMScalarOpts -lLLVMLinker
> -lLLVMIRReader -lLLVMAsmParser -lLLVMInstCombine -lLLVMTransformUtils
> -lLLVMBitWriter -lLLVMAnalysis -lLLVMProfileData -lLLVMObject
> -lLLVMMCParser -lLLVMMC -lLLVMBitReader -lLLVMCore -lLLVMBinaryFormat
> -lLLVMSupport -lLLVMDemangle /usr/lib64/libunwind.so -ldl -lm
> /usr/lib64/libsensors.so /usr/lib64/libexpat.so -lm  
> src/util/libmesa_util.a(u_cpu_detect.c.o): In function `call_once':
> /home/gerddie/src/Collabora/Qemu2/build/mesa-
> debug/../../samba/mesa/src/../include/c11/threads_posix.h:96: undefined
> reference to `pthread_once'
> collect2: error: ld returned 1 exit status
> 
> The bug popped up just now when I rebased a tree that was building fine
> before. I think it was related to rebasing a rather old branch that
> still had some files in gallium/util that are now in util, so some
> library is probably not rebuild correctly, but "ninja clean" doesn't
> help to get things right. Setting  up a build from scratch usually
> doesn't show the problem though.
> 
> (2) It would be nice if Meson would distribute some default cross build
> files, currently everybody has to roll its own, and I guess in the end
> they all look mostly the same.

Please ask your distro to write and distribute the cross files. It's simply
impossible for meson to distribute them for a huge number of reasons, but
basically it boils down to too many distros with too many differences. I have
done basically everything I can (personally) to make this easier, including
adding support for loading cross files from XDG paths (/usr/share/meson/cross,
etc)

> 
> (3) I also noted that with across build one has to set the library
> install directory manually, because it defaults to the directory used
> for the build machine - i.e. a i386 cross build on debian amd64 should
> set the lib install directory on Debian to "lib/i386-linux-gnu" but it
> sets it to "lib/x86_64-linux-gnu" 

There is this issue: https://github.com/mesonbuild/meson/issues/4008

This is another case that is really hard to handle because of the way different
distros have handled installing x86 and x86_64 binaries on the same OS. To name
a few:
debian : lib/$gnu-tri/
arch   : lib/ + lib32/
fedora : lib64/ + lib32/

I'm sure there are more, but getting that right all of the time is actually
pretty hard. I'll look into it.

Dylan

> 
> Best, 
> Gert
> 
> [1] https://patchwork.freedesktop.org/series/52749/
> 
> > 
> > Dylan
> > ___
> > 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

Re: [Mesa-dev] last call for autotools

[Alex Deucher]

On Fri, Dec 14, 2018 at 11:32 AM Matt Turner  wrote:
>
> On Fri, Dec 14, 2018 at 4:12 AM Gert Wollny  wrote:
> > I second that, I voiced my concerns in a former thread, especially that
> > so far this upcoming change has not been officially announced in the
> > release notes or on mesa-user, and that I don't understand why it is so
> > urgent to drop autotools when there is still someone who offers to
> > maintain it and some who prefer to use it.
>
> It's because the objective is to have as few build systems as
> necessary. This is an obvious first step and has been a stated goal
> for more than a year. I'm surprised that you're surprised.

A laudable goal, but if it's not ready, it's not ready.

>
> Let's just make an external contrib repo and keep all the autotools
> files there. Then Emil and company can continue having fun maintaining
> autotools and all you'll need to do is rsync into the Mesa repo to use
> autotools.

Seems like a bigger turn off for casual developers that are having
trouble with meson.  At this point it seems like we have a few
enthusiastic supporters, and a bunch of people begrudgingly going
along with it despite having limitations to their work flow.  Every
conversion seems to go this way.  It's not like these are new
sentiments.

Alex
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] last call for autotools

[Ilia Mirkin]

On Fri, Dec 14, 2018 at 11:32 AM Matt Turner  wrote:
>
> On Fri, Dec 14, 2018 at 4:12 AM Gert Wollny  wrote:
> > I second that, I voiced my concerns in a former thread, especially that
> > so far this upcoming change has not been officially announced in the
> > release notes or on mesa-user, and that I don't understand why it is so
> > urgent to drop autotools when there is still someone who offers to
> > maintain it and some who prefer to use it.
>
> It's because the objective is to have as few build systems as
> necessary. This is an obvious first step and has been a stated goal
> for more than a year. I'm surprised that you're surprised.
>
> Let's just make an external contrib repo and keep all the autotools
> files there. Then Emil and company can continue having fun maintaining
> autotools and all you'll need to do is rsync into the Mesa repo to use
> autotools.

So ... not last call for autotools? More like "railroad notification
that the train is in motion"?

This kind of talk just causes everyone to entrench into their
positions, so I'd rather avoid it. I'm not opposed to switching build
systems in principle, but the current proposal is, in my and seemingly
some other people's views, inadequate. Let's make it adequate before
dropping the thing that works for everyone.

  -ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] last call for autotools

[Matt Turner]

On Fri, Dec 14, 2018 at 4:12 AM Gert Wollny  wrote:
> I second that, I voiced my concerns in a former thread, especially that
> so far this upcoming change has not been officially announced in the
> release notes or on mesa-user, and that I don't understand why it is so
> urgent to drop autotools when there is still someone who offers to
> maintain it and some who prefer to use it.

It's because the objective is to have as few build systems as
necessary. This is an obvious first step and has been a stated goal
for more than a year. I'm surprised that you're surprised.

Let's just make an external contrib repo and keep all the autotools
files there. Then Emil and company can continue having fun maintaining
autotools and all you'll need to do is rsync into the Mesa repo to use
autotools.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] last call for autotools

[Henri Verbeet]

On Fri, 14 Dec 2018 at 15:42, Gert Wollny  wrote:
> Am Freitag, den 14.12.2018, 01:19 -0500 schrieb Ilia Mirkin:
> > meson is not at a point where it Just Works. It ... sometimes works.
> > The fact that everyone has scripts which wrap meson is a symptom of
> > that. I don't feel good about dumping the system that everyone (and I
> > don't just mean people on this list -- I mean the wider open source
> > community as well) knows how to use and has worked reliably for years
> > (decades, really) to be replaced by a system that everyone is having
> > problems with (it's not just me -- others are running into trouble
> > too -- just look at this thread). It's just not ready yet.
>
> I second that, I voiced my concerns in a former thread, especially that
> so far this upcoming change has not been officially announced in the
> release notes or on mesa-user, and that I don't understand why it is so
> urgent to drop autotools when there is still someone who offers to
> maintain it and some who prefer to use it.
>
Just to add my +1, as a user, I prefer the more mainstream build system.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] last call for autotools

[Gert Wollny]

Am Freitag, den 14.12.2018, 01:19 -0500 schrieb Ilia Mirkin:
> I have to say that the user experience for autotools is WAY better
> than for meson. As a concrete example, I had a meson build. Then I
> updated meson (0.48.1 to 0.48.2). Now ninja -C foo doesn't work.
> meson
> --reconfigure (which presumably is what ninja would end up running)
> doesn't work. http://paste.debian.net/hidden/cf777f3e/

I think that was fixed with this PR (although I so far I didn't try to
use this new feature, so I don't know how well it works):
  https://github.com/mesonbuild/meson/pull/4356
The error message should probably be updated accordingly. 

[...]
> 
> meson is not at a point where it Just Works. It ... sometimes works.
> The fact that everyone has scripts which wrap meson is a symptom of
> that. I don't feel good about dumping the system that everyone (and I
> don't just mean people on this list -- I mean the wider open source
> community as well) knows how to use and has worked reliably for years
> (decades, really) to be replaced by a system that everyone is having
> problems with (it's not just me -- others are running into trouble
> too -- just look at this thread). It's just not ready yet.

I second that, I voiced my concerns in a former thread, especially that
so far this upcoming change has not been officially announced in the
release notes or on mesa-user, and that I don't understand why it is so
urgent to drop autotools when there is still someone who offers to
maintain it and some who prefer to use it.

What I wanted to add: Dylan, you did a great job in adding meson and
getting it to the point where it is now, please don't see it in any way
as an attempt to diminish your achievment here that some of us are
reluctant to drop autotools.

Just look at how long it takes to allow c++11 in the whole of mesa's
C++ code. I think not even now it is official that -std=c++11 can be
assumed for all mesa c++ code, and there is still one build config in
travis that uses gcc 4.7 that supports the flag -std=c++11, but is
actually missing some features of c++11, so even now, by the end of
2018 one can not fully use c++11, and most compilers already default to
c++14. I understand the need for some to use older compilers, so I
don't complain about this. AFAICS meson actually defaults to -std=c++11
on the whole C++ code base, so from that point of view I'm actually in
favour of making it the preferred build system, I just don't see the
need to remove autotools already.

Cheers, 
Gert

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] last call for autotools

[Gert Wollny]

Am Montag, den 10.12.2018, 15:10 -0800 schrieb Dylan Baker:
> Meson 0.49.0 has been out for a couple of days now, and I'd like to
> make the final call for autotools. My patch is so massive that it's a
> huge pain to send to the list, the latest versions is here:
> https://gitlab.freedesktop.org/dbaker/mesa/commits/delete-autotools

Well, 

(1) there is stil this Heisenbug that pops up there and then, and that
I send a patch for some time ago [1]: 

[1088/1140] Linking target src/gallium/tests/trivial/quad-tex.
FAILED: src/gallium/tests/trivial/quad-tex 
g++  -o src/gallium/tests/trivial/quad-tex 'src/gallium/tests/trivial/s
rc@gallium@tests@trivial@@quad-tex@exe/quad-tex.c.o' -Wl,--no-undefined 
-Wl,--as-needed -Wl,--start-group src/util/libmesa_util.a
src/gallium/auxiliary/libgallium.a src/gallium/auxiliary/pipe-
loader/libpipe_loader_dynamic.a src/loader/libloader.a
src/util/libxmlconfig.a /usr/lib64/libz.so -lm -Wl,--end-group
/usr/lib64/libdrm.so -L/usr/lib64/llvm/6/lib64 -lLLVMAMDGPUDisassembler
-lLLVMAMDGPUCodeGen -lLLVMAMDGPUAsmParser -lLLVMAMDGPUDesc
-lLLVMAMDGPUInfo -lLLVMAMDGPUAsmPrinter -lLLVMAMDGPUUtils -lLLVMMCJIT
-lLLVMExecutionEngine -lLLVMRuntimeDyld -lLLVMX86Disassembler
-lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMGlobalISel -lLLVMSelectionDAG
-lLLVMAsmPrinter -lLLVMDebugInfoCodeView -lLLVMDebugInfoMSF
-lLLVMCodeGen -lLLVMTarget -lLLVMX86Desc -lLLVMMCDisassembler
-lLLVMX86Info -lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMipo
-lLLVMInstrumentation -lLLVMVectorize -lLLVMScalarOpts -lLLVMLinker
-lLLVMIRReader -lLLVMAsmParser -lLLVMInstCombine -lLLVMTransformUtils
-lLLVMBitWriter -lLLVMAnalysis -lLLVMProfileData -lLLVMObject
-lLLVMMCParser -lLLVMMC -lLLVMBitReader -lLLVMCore -lLLVMBinaryFormat
-lLLVMSupport -lLLVMDemangle /usr/lib64/libunwind.so -ldl -lm
/usr/lib64/libsensors.so /usr/lib64/libexpat.so -lm  
src/util/libmesa_util.a(u_cpu_detect.c.o): In function `call_once':
/home/gerddie/src/Collabora/Qemu2/build/mesa-
debug/../../samba/mesa/src/../include/c11/threads_posix.h:96: undefined
reference to `pthread_once'
collect2: error: ld returned 1 exit status

The bug popped up just now when I rebased a tree that was building fine
before. I think it was related to rebasing a rather old branch that
still had some files in gallium/util that are now in util, so some
library is probably not rebuild correctly, but "ninja clean" doesn't
help to get things right. Setting  up a build from scratch usually
doesn't show the problem though.

(2) It would be nice if Meson would distribute some default cross build
files, currently everybody has to roll its own, and I guess in the end
they all look mostly the same.

(3) I also noted that with across build one has to set the library
install directory manually, because it defaults to the directory used
for the build machine - i.e. a i386 cross build on debian amd64 should
set the lib install directory on Debian to "lib/i386-linux-gnu" but it
sets it to "lib/x86_64-linux-gnu" 
 

Best, 
Gert

[1] https://patchwork.freedesktop.org/series/52749/

> 
> Dylan
> ___
> 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

Re: [Mesa-dev] last call for autotools

[Ilia Mirkin]

On Fri, Dec 14, 2018 at 2:13 AM Matt Turner  wrote:
>
> On Thu, Dec 13, 2018 at 10:19 PM Ilia Mirkin  wrote:
> > So now what? I don't remember how that config was done, except that it
> > was done the way I decided I needed it at the time. I have no way to
> > recover it. With autotools, in such cases (which are immensely rare),
> > you just run "head config.log" and it tells you what you did last
> > time. And by updating the build component, now I have to rebuild
> > EVERYTHING?
>
> Since it uses ccache, that should take about 20 seconds...

I don't have ccache. No clue how to set it up, and don't have the disk
space for it anyways -- constantly teetering on the edge of fullness.
It takes about 10 minutes to build. And if the hope is that meson
becomes used for other projects, then this is multiplied by all the
other meson-using projects. Your answer is an apology for tool
shortcomings.

As someone who frequently builds a particular project, I'm sure you
have everything all set up perfectly (enough) for your situation. But
you're not the average user. I have things set up "well enough" as
well. I edit a handful of files, and expect a ~full rebuild when I
rebase, which I do relatively rarely.

The average user is the one who knows just a smidgen more than
"./configure; make install". That's what I mean by the user experience
being better in autotools.

But like I said on IRC ... if I'm the lone cranky old man who doesn't
like the new thing, then I won't (and probably couldn't even if I
wanted to) stand in the way of this. However my impression is that
there's a larger contingent dissatisfied with meson.

  -ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] last call for autotools

[Marek Olšák]

So your issue is that meson upgrade broke the build and you are unable to
get config.log. Let me tell you something. Ninja upgrade also breaks the
build. I think that's the way it's going to be now. I think people will use
the new build system anyway as conf and compile time is all that matters.

Marek

On Fri, Dec 14, 2018, 1:19 AM Ilia Mirkin  I have to say that the user experience for autotools is WAY better
> than for meson. As a concrete example, I had a meson build. Then I
> updated meson (0.48.1 to 0.48.2). Now ninja -C foo doesn't work. meson
> --reconfigure (which presumably is what ninja would end up running)
> doesn't work. http://paste.debian.net/hidden/cf777f3e/
>
> So now what? I don't remember how that config was done, except that it
> was done the way I decided I needed it at the time. I have no way to
> recover it. With autotools, in such cases (which are immensely rare),
> you just run "head config.log" and it tells you what you did last
> time. And by updating the build component, now I have to rebuild
> EVERYTHING?
>
> meson is not at a point where it Just Works. It ... sometimes works.
> The fact that everyone has scripts which wrap meson is a symptom of
> that. I don't feel good about dumping the system that everyone (and I
> don't just mean people on this list -- I mean the wider open source
> community as well) knows how to use and has worked reliably for years
> (decades, really) to be replaced by a system that everyone is having
> problems with (it's not just me -- others are running into trouble too
> -- just look at this thread). It's just not ready yet.
>
>   -ilia
>
> On Mon, Dec 10, 2018 at 6:11 PM Dylan Baker  wrote:
> >
> > Meson 0.49.0 has been out for a couple of days now, and I'd like to make
> the
> > final call for autotools. My patch is so massive that it's a huge pain
> to send
> > to the list, the latest versions is here:
> > https://gitlab.freedesktop.org/dbaker/mesa/commits/delete-autotools
> >
> > Dylan
> > ___
> > 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
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] last call for autotools

[Matt Turner]

On Thu, Dec 13, 2018 at 10:19 PM Ilia Mirkin  wrote:
> So now what? I don't remember how that config was done, except that it
> was done the way I decided I needed it at the time. I have no way to
> recover it. With autotools, in such cases (which are immensely rare),
> you just run "head config.log" and it tells you what you did last
> time. And by updating the build component, now I have to rebuild
> EVERYTHING?

Since it uses ccache, that should take about 20 seconds...
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] last call for autotools

[Ilia Mirkin]

I have to say that the user experience for autotools is WAY better
than for meson. As a concrete example, I had a meson build. Then I
updated meson (0.48.1 to 0.48.2). Now ninja -C foo doesn't work. meson
--reconfigure (which presumably is what ninja would end up running)
doesn't work. http://paste.debian.net/hidden/cf777f3e/

So now what? I don't remember how that config was done, except that it
was done the way I decided I needed it at the time. I have no way to
recover it. With autotools, in such cases (which are immensely rare),
you just run "head config.log" and it tells you what you did last
time. And by updating the build component, now I have to rebuild
EVERYTHING?

meson is not at a point where it Just Works. It ... sometimes works.
The fact that everyone has scripts which wrap meson is a symptom of
that. I don't feel good about dumping the system that everyone (and I
don't just mean people on this list -- I mean the wider open source
community as well) knows how to use and has worked reliably for years
(decades, really) to be replaced by a system that everyone is having
problems with (it's not just me -- others are running into trouble too
-- just look at this thread). It's just not ready yet.

  -ilia

On Mon, Dec 10, 2018 at 6:11 PM Dylan Baker  wrote:
>
> Meson 0.49.0 has been out for a couple of days now, and I'd like to make the
> final call for autotools. My patch is so massive that it's a huge pain to send
> to the list, the latest versions is here:
> https://gitlab.freedesktop.org/dbaker/mesa/commits/delete-autotools
>
> Dylan
> ___
> 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

Re: [Mesa-dev] last call for autotools

[Dylan Baker]

Quoting Marek Olšák (2018-12-13 11:28:10)
> Another issue with meson is this:
> 
> I have to set PKG_CONFIG_PATH when I type meson for 32-bit builds. If I do
> meson configure --clearcache and then type "ninja", it will reconfigure, but
> will use 64-bit libraries instead because PKG_CONFIG_PATH is not set when 
> ninja
> is run, which will fail to link.
> 
> Luckily, at least CC="gcc -m32" and CXX="g++ -m32" weren't wiped out by
> --clearcache.
> 
> Additionally, it would be nice if the default build type was release instead 
> of
> plain.
> 
> Thanks,
> Marek
> 
> On Mon, Dec 10, 2018 at 6:11 PM Dylan Baker  wrote:
> 
> Meson 0.49.0 has been out for a couple of days now, and I'd like to make
> the
> final call for autotools. My patch is so massive that it's a huge pain to
> send
> to the list, the latest versions is here:
> https://gitlab.freedesktop.org/dbaker/mesa/commits/delete-autotools
> 
> Dylan
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 

I've had much better luck using a cross file for doing x86 builds on x86_64, I
believe I've posted my cross file before but I can do so again.

Dylan


signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] last call for autotools

[Rob Clark]

On Thu, Dec 13, 2018 at 2:41 PM Jason Ekstrand  wrote:
>
> On Wed, Dec 12, 2018 at 2:52 PM Rob Clark  wrote:
>>
>> On Wed, Dec 12, 2018 at 3:45 PM Marek Olšák  wrote:
>> >
>> > On Wed, Dec 12, 2018 at 3:37 PM Rob Clark  wrote:
>> >>
>> >> On Wed, Dec 12, 2018 at 3:13 PM Bas Nieuwenhuizen
>> >>  wrote:
>> >> >
>> >> > On Wed, Dec 12, 2018 at 8:59 PM Marek Olšák  wrote:
>> >> > >
>> >> > > There are 2 issues with meson:
>> >> > > * -DDEBUG is not present in debugoptimized builds.
>> >> >
>> >> > Do people expect -DDEBUG for debugoptimized? I would think that debug
>> >> > optimized would be an optimized build with debug symbols, but not
>> >> > expensive checks & asserts, which would match the current
>> >> > debugoptimized build?
>> >>
>> >> please, no -DDEBUG for debugoptimized.. I use that when I want debug
>> >> syms but not (for example) nir_validate and other expensive checks.
>> >
>> >
>> > If nir_validate is so bad, perhaps it shouldn't be run at all. If you work 
>> > on NIR and it's not important for you to run nir_validate, perhaps it 
>> > shouldn't be run at all. It doesn't have anything to do with build systems.
>> >
>>
>> I do actually want it enabled when I piglit/deqp..  for which I use
>> debug builds.  But I don't want it if I'm profiling or valgrinding,
>> where I use debugoptimized..
>
>
> IMO, you shouldn't do any profiling with any build that has the world "debug" 
> in the name.  What it sounds like you want is a meson equivalent of CMake's 
> RelWithDebugInfo which meson doesn't currently have.

this is kinda what I expect debugoptimzied to be.  And in fact we only
set -DDEBUG for 'debug' and not 'debugoptimized' if I'm reading
meson.build correctly..

BR,
-R
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] last call for autotools

[Jason Ekstrand]

On Wed, Dec 12, 2018 at 2:42 PM Marek Olšák  wrote:

> Most assertions and checks are enabled, because NDEBUG is not defined, but
> DEBUG is not defined either, which is a Mesa-specific definition.
>
> The default debug build for autotools is debugoptimized (-g -O2 -DDEBUG).
> meson changed that behavior by removing -DDEBUG. Autotools doesn't have
> what meson calls "debug", which indicates that most people don't want to
> use "debug" much. People who wanted to -O0 had to set CFLAGS. Now people
> who want the autotools debug build have to add -DDEBUG into CFLAGS.
>

For whatever it's worth, I never do a debug build with either build system
without throwing in -O0 because otherwise the symbols are nearly useless.


> On top of that, I discovered a 3rd issue with meson:
> * meson --reconfigure doesn't re-run llvm-config.
>
> Marek
>
> On Wed, Dec 12, 2018 at 3:13 PM Bas Nieuwenhuizen 
> wrote:
>
>> On Wed, Dec 12, 2018 at 8:59 PM Marek Olšák  wrote:
>> >
>> > There are 2 issues with meson:
>> > * -DDEBUG is not present in debugoptimized builds.
>>
>> Do people expect -DDEBUG for debugoptimized? I would think that debug
>> optimized would be an optimized build with debug symbols, but not
>> expensive checks & asserts, which would match the current
>> debugoptimized build?
>>
>> > * meson ignores CFLAGS with --reconfigure, for example:
>> CFLAGS="-DDEBUG" meson --reconfigure ... doesn't update CFLAGS.
>> >
>> > Marek
>> >
>> > On Mon, Dec 10, 2018 at 6:11 PM Dylan Baker 
>> wrote:
>> >>
>> >> Meson 0.49.0 has been out for a couple of days now, and I'd like to
>> make the
>> >> final call for autotools. My patch is so massive that it's a huge pain
>> to send
>> >> to the list, the latest versions is here:
>> >> https://gitlab.freedesktop.org/dbaker/mesa/commits/delete-autotools
>> >>
>> >> Dylan
>> >> ___
>> >> 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
>>
> ___
> 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

Re: [Mesa-dev] last call for autotools

[Jason Ekstrand]

On Wed, Dec 12, 2018 at 2:52 PM Rob Clark  wrote:

> On Wed, Dec 12, 2018 at 3:45 PM Marek Olšák  wrote:
> >
> > On Wed, Dec 12, 2018 at 3:37 PM Rob Clark  wrote:
> >>
> >> On Wed, Dec 12, 2018 at 3:13 PM Bas Nieuwenhuizen
> >>  wrote:
> >> >
> >> > On Wed, Dec 12, 2018 at 8:59 PM Marek Olšák  wrote:
> >> > >
> >> > > There are 2 issues with meson:
> >> > > * -DDEBUG is not present in debugoptimized builds.
> >> >
> >> > Do people expect -DDEBUG for debugoptimized? I would think that debug
> >> > optimized would be an optimized build with debug symbols, but not
> >> > expensive checks & asserts, which would match the current
> >> > debugoptimized build?
> >>
> >> please, no -DDEBUG for debugoptimized.. I use that when I want debug
> >> syms but not (for example) nir_validate and other expensive checks.
> >
> >
> > If nir_validate is so bad, perhaps it shouldn't be run at all. If you
> work on NIR and it's not important for you to run nir_validate, perhaps it
> shouldn't be run at all. It doesn't have anything to do with build systems.
> >
>
> I do actually want it enabled when I piglit/deqp..  for which I use
> debug builds.  But I don't want it if I'm profiling or valgrinding,
> where I use debugoptimized..
>

IMO, you shouldn't do any profiling with any build that has the world
"debug" in the name.  What it sounds like you want is a meson equivalent of
CMake's RelWithDebugInfo which meson doesn't currently have.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] last call for autotools

[Marek Olšák]

Another issue with meson is this:

I have to set PKG_CONFIG_PATH when I type meson for 32-bit builds. If I do
meson configure --clearcache and then type "ninja", it will reconfigure,
but will use 64-bit libraries instead because PKG_CONFIG_PATH is not set
when ninja is run, which will fail to link.

Luckily, at least CC="gcc -m32" and CXX="g++ -m32" weren't wiped out by
--clearcache.

Additionally, it would be nice if the default build type was release
instead of plain.

Thanks,
Marek

On Mon, Dec 10, 2018 at 6:11 PM Dylan Baker  wrote:

> Meson 0.49.0 has been out for a couple of days now, and I'd like to make
> the
> final call for autotools. My patch is so massive that it's a huge pain to
> send
> to the list, the latest versions is here:
> https://gitlab.freedesktop.org/dbaker/mesa/commits/delete-autotools
>
> Dylan
> ___
> 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

Re: [Mesa-dev] last call for autotools

[Dylan Baker]

Quoting Axel Davy (2018-12-12 14:31:34)
> On 12/12/2018 23:06, Dylan Baker wrote:
> > Quoting Marek Ol\u0161k (2018-12-12 13:07:10)
> >> On Wed, Dec 12, 2018 at 3:52 PM Rob Clark  wrote:
> >>
> >>  On Wed, Dec 12, 2018 at 3:45 PM Marek Ol\u0161k  
> >> wrote:
> >>  >
> >>  > On Wed, Dec 12, 2018 at 3:37 PM Rob Clark  
> >> wrote:
> >>  >>
> >>  >> On Wed, Dec 12, 2018 at 3:13 PM Bas Nieuwenhuizen
> >>  >>  wrote:
> >>  >> >
> >>  >> > On Wed, Dec 12, 2018 at 8:59 PM Marek Ol\u0161k 
> >>  wrote:
> >>  >> > >
> >>  >> > > There are 2 issues with meson:
> >>  >> > > * -DDEBUG is not present in debugoptimized builds.
> >>  >> >
> >>  >> > Do people expect -DDEBUG for debugoptimized? I would think that 
> >> debug
> >>  >> > optimized would be an optimized build with debug symbols, but not
> >>  >> > expensive checks & asserts, which would match the current
> >>  >> > debugoptimized build?
> >>  >>
> >>  >> please, no -DDEBUG for debugoptimized.. I use that when I want 
> >> debug
> >>  >> syms but not (for example) nir_validate and other expensive checks.
> >>  >
> >>  >
> >>  > If nir_validate is so bad, perhaps it shouldn't be run at all. If 
> >> you
> >>  work on NIR and it's not important for you to run nir_validate, 
> >> perhaps it
> >>  shouldn't be run at all. It doesn't have anything to do with build 
> >> systems.
> >>  >
> >>
> >>  I do actually want it enabled when I piglit/deqp.. for which I use
> >>  debug builds. But I don't want it if I'm profiling or valgrinding,
> >>  where I use debugoptimized..
> >>
> >>
> >> At some point, DEBUG will be replaced by !NDEBUG.
> >>
> >> Marek
> > The whole point of DEBUG is to hide really expensive checks like nir 
> > validate.
> > If there are are asserts hidden behind debug that's wrong, those should be
> > behind !NDEBUG, that's what NDEBUG is for. We've talked about renaming DEBUG
> > because it's confusing, something like EXPENSIVE_DEBUG or 
> > EXPENSIVE_VALIDATION
> > or something along those lines.
> >
> > The thread I linked you to previously has extensive discussion of why DEBUG 
> > was
> > removed from the debugoptimized build.
> >
> > For CFLAGS: yes, environment variables are only read during the initial
> > configuration by design, they basically exist for compatibility with 
> > autotools.
> > You want to use -Dc_args and -Dcpp_args (for CFLAGS and CXXFLAGS 
> > respectively)
> > these are read by meson, meson configure, and meson reconfigure.
> >
> > Dylan
> 
> Hi,
> 
> Currently nine debug log (enabled with NINE_DEBUG=all) only works with 
> --enable-debug build.
> 
> There is quite a performance difference with autotools when you build 
> with --enable-debug. However we often need users to use NINE_DEBUG to 
> produce logs for issues.
> 
> These sorts of things should be made to work with debugoptimized if 
> possible.
> 
> Currently we hide that against the DEBUG env var. Should that be 
> replaced by !NDEBUG when autotools support is killed ?
> 
> Axel
> 

Likely it means we (the mesa community) needs to have a discussion about -DDEBUG
in general. We (intel) use it to hide things that will make performance suck,
but it seems like others are using it just to hide debugging information. I'll
send a separate mail about DEBUG.

Dylan


signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] last call for autotools

[Dylan Baker]

Quoting Marek Olšák (2018-12-12 14:27:21)
> On Wed, Dec 12, 2018 at 5:14 PM Dylan Baker  wrote:
> 
> Quoting Marek Olšák (2018-12-12 12:42:01)
> > Most assertions and checks are enabled, because NDEBUG is not defined,
> but
> > DEBUG is not defined either, which is a Mesa-specific definition.
> >
> > The default debug build for autotools is debugoptimized (-g -O2 
> -DDEBUG).
> meson
> > changed that behavior by removing -DDEBUG. Autotools doesn't have what
> meson
> > calls "debug", which indicates that most people don't want to use 
> "debug"
> much.
> > People who wanted to -O0 had to set CFLAGS. Now people who want the
> autotools
> > debug build have to add -DDEBUG into CFLAGS.
> >
> > On top of that, I discovered a 3rd issue with meson:
> > * meson --reconfigure doesn't re-run llvm-config.
> >
> > Marek
> 
> Don't use --reconfigure, you're abusing it to get it to do what you want.
> --reconfigure is for handling cases where an option has been removed or
> renamed
> and meson can't figure out how to fix it itself, so you smash it with a
> hammer.
> meson configure has an option to force llvm-config (and all dependencies)
> to be
> rechecked. In your wrapper script you'd be better off with something like:
> 
> if [ ! -a $BUILDDIR ]; then
>     meson $BUILDDIR $OPTIONS
> else
>     meson configure $BUILDDIR $OPTIONS --clearcache
> fi
> 
> 
> I'll just do rm -r $BUILDDIR instead of relying on various options that might
> get broken.
> 
> Marek

If that's what you want to do.

Dylan


signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] last call for autotools

[Axel Davy]

On 12/12/2018 23:06, Dylan Baker wrote:

Quoting Marek Olšák (2018-12-12 13:07:10)

On Wed, Dec 12, 2018 at 3:52 PM Rob Clark  wrote:

 On Wed, Dec 12, 2018 at 3:45 PM Marek Olšák  wrote:
 >
 > On Wed, Dec 12, 2018 at 3:37 PM Rob Clark  wrote:
 >>
 >> On Wed, Dec 12, 2018 at 3:13 PM Bas Nieuwenhuizen
 >>  wrote:
 >> >
 >> > On Wed, Dec 12, 2018 at 8:59 PM Marek Olšák  wrote:
 >> > >
 >> > > There are 2 issues with meson:
 >> > > * -DDEBUG is not present in debugoptimized builds.
 >> >
 >> > Do people expect -DDEBUG for debugoptimized? I would think that debug
 >> > optimized would be an optimized build with debug symbols, but not
 >> > expensive checks & asserts, which would match the current
 >> > debugoptimized build?
 >>
 >> please, no -DDEBUG for debugoptimized.. I use that when I want debug
 >> syms but not (for example) nir_validate and other expensive checks.
 >
 >
 > If nir_validate is so bad, perhaps it shouldn't be run at all. If you
 work on NIR and it's not important for you to run nir_validate, perhaps it
 shouldn't be run at all. It doesn't have anything to do with build systems.
 >

 I do actually want it enabled when I piglit/deqp..  for which I use
 debug builds.  But I don't want it if I'm profiling or valgrinding,
 where I use debugoptimized..


At some point, DEBUG will be replaced by !NDEBUG.

Marek

The whole point of DEBUG is to hide really expensive checks like nir validate.
If there are are asserts hidden behind debug that's wrong, those should be
behind !NDEBUG, that's what NDEBUG is for. We've talked about renaming DEBUG
because it's confusing, something like EXPENSIVE_DEBUG or EXPENSIVE_VALIDATION
or something along those lines.

The thread I linked you to previously has extensive discussion of why DEBUG was
removed from the debugoptimized build.

For CFLAGS: yes, environment variables are only read during the initial
configuration by design, they basically exist for compatibility with autotools.
You want to use -Dc_args and -Dcpp_args (for CFLAGS and CXXFLAGS respectively)
these are read by meson, meson configure, and meson reconfigure.

Dylan


Hi,

Currently nine debug log (enabled with NINE_DEBUG=all) only works with 
--enable-debug build.


There is quite a performance difference with autotools when you build 
with --enable-debug. However we often need users to use NINE_DEBUG to 
produce logs for issues.


These sorts of things should be made to work with debugoptimized if 
possible.


Currently we hide that against the DEBUG env var. Should that be 
replaced by !NDEBUG when autotools support is killed ?


Axel

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] last call for autotools

[Marek Olšák]

On Wed, Dec 12, 2018 at 5:14 PM Dylan Baker  wrote:

> Quoting Marek Olšák (2018-12-12 12:42:01)
> > Most assertions and checks are enabled, because NDEBUG is not defined,
> but
> > DEBUG is not defined either, which is a Mesa-specific definition.
> >
> > The default debug build for autotools is debugoptimized (-g -O2
> -DDEBUG). meson
> > changed that behavior by removing -DDEBUG. Autotools doesn't have what
> meson
> > calls "debug", which indicates that most people don't want to use
> "debug" much.
> > People who wanted to -O0 had to set CFLAGS. Now people who want the
> autotools
> > debug build have to add -DDEBUG into CFLAGS.
> >
> > On top of that, I discovered a 3rd issue with meson:
> > * meson --reconfigure doesn't re-run llvm-config.
> >
> > Marek
>
> Don't use --reconfigure, you're abusing it to get it to do what you want.
> --reconfigure is for handling cases where an option has been removed or
> renamed
> and meson can't figure out how to fix it itself, so you smash it with a
> hammer.
> meson configure has an option to force llvm-config (and all dependencies)
> to be
> rechecked. In your wrapper script you'd be better off with something like:
>
> if [ ! -a $BUILDDIR ]; then
> meson $BUILDDIR $OPTIONS
> else
> meson configure $BUILDDIR $OPTIONS --clearcache
> fi
>

I'll just do rm -r $BUILDDIR instead of relying on various options that
might get broken.

Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] last call for autotools

[Dylan Baker]

Quoting Marek Olšák (2018-12-12 12:42:01)
> Most assertions and checks are enabled, because NDEBUG is not defined, but
> DEBUG is not defined either, which is a Mesa-specific definition.
> 
> The default debug build for autotools is debugoptimized (-g -O2 -DDEBUG). 
> meson
> changed that behavior by removing -DDEBUG. Autotools doesn't have what meson
> calls "debug", which indicates that most people don't want to use "debug" 
> much.
> People who wanted to -O0 had to set CFLAGS. Now people who want the autotools
> debug build have to add -DDEBUG into CFLAGS.
> 
> On top of that, I discovered a 3rd issue with meson:
> * meson --reconfigure doesn't re-run llvm-config.
> 
> Marek

Don't use --reconfigure, you're abusing it to get it to do what you want.
--reconfigure is for handling cases where an option has been removed or renamed
and meson can't figure out how to fix it itself, so you smash it with a hammer.
meson configure has an option to force llvm-config (and all dependencies) to be
rechecked. In your wrapper script you'd be better off with something like:

if [ ! -a $BUILDDIR ]; then
meson $BUILDDIR $OPTIONS
else
meson configure $BUILDDIR $OPTIONS --clearcache
fi

Dylan


signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] last call for autotools

[Dylan Baker]

Quoting Marek Olšák (2018-12-12 13:07:10)
> On Wed, Dec 12, 2018 at 3:52 PM Rob Clark  wrote:
> 
> On Wed, Dec 12, 2018 at 3:45 PM Marek Olšák  wrote:
> >
> > On Wed, Dec 12, 2018 at 3:37 PM Rob Clark  wrote:
> >>
> >> On Wed, Dec 12, 2018 at 3:13 PM Bas Nieuwenhuizen
> >>  wrote:
> >> >
> >> > On Wed, Dec 12, 2018 at 8:59 PM Marek Olšák  wrote:
> >> > >
> >> > > There are 2 issues with meson:
> >> > > * -DDEBUG is not present in debugoptimized builds.
> >> >
> >> > Do people expect -DDEBUG for debugoptimized? I would think that debug
> >> > optimized would be an optimized build with debug symbols, but not
> >> > expensive checks & asserts, which would match the current
> >> > debugoptimized build?
> >>
> >> please, no -DDEBUG for debugoptimized.. I use that when I want debug
> >> syms but not (for example) nir_validate and other expensive checks.
> >
> >
> > If nir_validate is so bad, perhaps it shouldn't be run at all. If you
> work on NIR and it's not important for you to run nir_validate, perhaps it
> shouldn't be run at all. It doesn't have anything to do with build 
> systems.
> >
> 
> I do actually want it enabled when I piglit/deqp..  for which I use
> debug builds.  But I don't want it if I'm profiling or valgrinding,
> where I use debugoptimized..
> 
> 
> At some point, DEBUG will be replaced by !NDEBUG.
>
> Marek

The whole point of DEBUG is to hide really expensive checks like nir validate.
If there are are asserts hidden behind debug that's wrong, those should be
behind !NDEBUG, that's what NDEBUG is for. We've talked about renaming DEBUG
because it's confusing, something like EXPENSIVE_DEBUG or EXPENSIVE_VALIDATION
or something along those lines.

The thread I linked you to previously has extensive discussion of why DEBUG was
removed from the debugoptimized build.

For CFLAGS: yes, environment variables are only read during the initial
configuration by design, they basically exist for compatibility with autotools.
You want to use -Dc_args and -Dcpp_args (for CFLAGS and CXXFLAGS respectively)
these are read by meson, meson configure, and meson reconfigure.

Dylan


signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] last call for autotools

[Marek Olšák]

On Wed, Dec 12, 2018 at 3:52 PM Rob Clark  wrote:

> On Wed, Dec 12, 2018 at 3:45 PM Marek Olšák  wrote:
> >
> > On Wed, Dec 12, 2018 at 3:37 PM Rob Clark  wrote:
> >>
> >> On Wed, Dec 12, 2018 at 3:13 PM Bas Nieuwenhuizen
> >>  wrote:
> >> >
> >> > On Wed, Dec 12, 2018 at 8:59 PM Marek Olšák  wrote:
> >> > >
> >> > > There are 2 issues with meson:
> >> > > * -DDEBUG is not present in debugoptimized builds.
> >> >
> >> > Do people expect -DDEBUG for debugoptimized? I would think that debug
> >> > optimized would be an optimized build with debug symbols, but not
> >> > expensive checks & asserts, which would match the current
> >> > debugoptimized build?
> >>
> >> please, no -DDEBUG for debugoptimized.. I use that when I want debug
> >> syms but not (for example) nir_validate and other expensive checks.
> >
> >
> > If nir_validate is so bad, perhaps it shouldn't be run at all. If you
> work on NIR and it's not important for you to run nir_validate, perhaps it
> shouldn't be run at all. It doesn't have anything to do with build systems.
> >
>
> I do actually want it enabled when I piglit/deqp..  for which I use
> debug builds.  But I don't want it if I'm profiling or valgrinding,
> where I use debugoptimized..
>

At some point, DEBUG will be replaced by !NDEBUG.

Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] last call for autotools

[Rob Clark]

On Wed, Dec 12, 2018 at 3:45 PM Marek Olšák  wrote:
>
> On Wed, Dec 12, 2018 at 3:37 PM Rob Clark  wrote:
>>
>> On Wed, Dec 12, 2018 at 3:13 PM Bas Nieuwenhuizen
>>  wrote:
>> >
>> > On Wed, Dec 12, 2018 at 8:59 PM Marek Olšák  wrote:
>> > >
>> > > There are 2 issues with meson:
>> > > * -DDEBUG is not present in debugoptimized builds.
>> >
>> > Do people expect -DDEBUG for debugoptimized? I would think that debug
>> > optimized would be an optimized build with debug symbols, but not
>> > expensive checks & asserts, which would match the current
>> > debugoptimized build?
>>
>> please, no -DDEBUG for debugoptimized.. I use that when I want debug
>> syms but not (for example) nir_validate and other expensive checks.
>
>
> If nir_validate is so bad, perhaps it shouldn't be run at all. If you work on 
> NIR and it's not important for you to run nir_validate, perhaps it shouldn't 
> be run at all. It doesn't have anything to do with build systems.
>

I do actually want it enabled when I piglit/deqp..  for which I use
debug builds.  But I don't want it if I'm profiling or valgrinding,
where I use debugoptimized..

BR,
-R
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] last call for autotools

[Marek Olšák]

On Wed, Dec 12, 2018 at 3:37 PM Rob Clark  wrote:

> On Wed, Dec 12, 2018 at 3:13 PM Bas Nieuwenhuizen
>  wrote:
> >
> > On Wed, Dec 12, 2018 at 8:59 PM Marek Olšák  wrote:
> > >
> > > There are 2 issues with meson:
> > > * -DDEBUG is not present in debugoptimized builds.
> >
> > Do people expect -DDEBUG for debugoptimized? I would think that debug
> > optimized would be an optimized build with debug symbols, but not
> > expensive checks & asserts, which would match the current
> > debugoptimized build?
>
> please, no -DDEBUG for debugoptimized.. I use that when I want debug
> syms but not (for example) nir_validate and other expensive checks.
>

If nir_validate is so bad, perhaps it shouldn't be run at all. If you work
on NIR and it's not important for you to run nir_validate, perhaps it
shouldn't be run at all. It doesn't have anything to do with build systems.

Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] last call for autotools

[Marek Olšák]

Most assertions and checks are enabled, because NDEBUG is not defined, but
DEBUG is not defined either, which is a Mesa-specific definition.

The default debug build for autotools is debugoptimized (-g -O2 -DDEBUG).
meson changed that behavior by removing -DDEBUG. Autotools doesn't have
what meson calls "debug", which indicates that most people don't want to
use "debug" much. People who wanted to -O0 had to set CFLAGS. Now people
who want the autotools debug build have to add -DDEBUG into CFLAGS.

On top of that, I discovered a 3rd issue with meson:
* meson --reconfigure doesn't re-run llvm-config.

Marek

On Wed, Dec 12, 2018 at 3:13 PM Bas Nieuwenhuizen 
wrote:

> On Wed, Dec 12, 2018 at 8:59 PM Marek Olšák  wrote:
> >
> > There are 2 issues with meson:
> > * -DDEBUG is not present in debugoptimized builds.
>
> Do people expect -DDEBUG for debugoptimized? I would think that debug
> optimized would be an optimized build with debug symbols, but not
> expensive checks & asserts, which would match the current
> debugoptimized build?
>
> > * meson ignores CFLAGS with --reconfigure, for example: CFLAGS="-DDEBUG"
> meson --reconfigure ... doesn't update CFLAGS.
> >
> > Marek
> >
> > On Mon, Dec 10, 2018 at 6:11 PM Dylan Baker  wrote:
> >>
> >> Meson 0.49.0 has been out for a couple of days now, and I'd like to
> make the
> >> final call for autotools. My patch is so massive that it's a huge pain
> to send
> >> to the list, the latest versions is here:
> >> https://gitlab.freedesktop.org/dbaker/mesa/commits/delete-autotools
> >>
> >> Dylan
> >> ___
> >> 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
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] last call for autotools

[Rob Clark]

On Wed, Dec 12, 2018 at 3:13 PM Bas Nieuwenhuizen
 wrote:
>
> On Wed, Dec 12, 2018 at 8:59 PM Marek Olšák  wrote:
> >
> > There are 2 issues with meson:
> > * -DDEBUG is not present in debugoptimized builds.
>
> Do people expect -DDEBUG for debugoptimized? I would think that debug
> optimized would be an optimized build with debug symbols, but not
> expensive checks & asserts, which would match the current
> debugoptimized build?

please, no -DDEBUG for debugoptimized.. I use that when I want debug
syms but not (for example) nir_validate and other expensive checks.

BR,
-R

>
> > * meson ignores CFLAGS with --reconfigure, for example: CFLAGS="-DDEBUG" 
> > meson --reconfigure ... doesn't update CFLAGS.
> >
> > Marek
> >
> > On Mon, Dec 10, 2018 at 6:11 PM Dylan Baker  wrote:
> >>
> >> Meson 0.49.0 has been out for a couple of days now, and I'd like to make 
> >> the
> >> final call for autotools. My patch is so massive that it's a huge pain to 
> >> send
> >> to the list, the latest versions is here:
> >> https://gitlab.freedesktop.org/dbaker/mesa/commits/delete-autotools
> >>
> >> Dylan
> >> ___
> >> 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
> ___
> 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

Re: [Mesa-dev] last call for autotools

[Bas Nieuwenhuizen]

On Wed, Dec 12, 2018 at 8:59 PM Marek Olšák  wrote:
>
> There are 2 issues with meson:
> * -DDEBUG is not present in debugoptimized builds.

Do people expect -DDEBUG for debugoptimized? I would think that debug
optimized would be an optimized build with debug symbols, but not
expensive checks & asserts, which would match the current
debugoptimized build?

> * meson ignores CFLAGS with --reconfigure, for example: CFLAGS="-DDEBUG" 
> meson --reconfigure ... doesn't update CFLAGS.
>
> Marek
>
> On Mon, Dec 10, 2018 at 6:11 PM Dylan Baker  wrote:
>>
>> Meson 0.49.0 has been out for a couple of days now, and I'd like to make the
>> final call for autotools. My patch is so massive that it's a huge pain to 
>> send
>> to the list, the latest versions is here:
>> https://gitlab.freedesktop.org/dbaker/mesa/commits/delete-autotools
>>
>> Dylan
>> ___
>> 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
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] last call for autotools

[Marek Olšák]

There are 2 issues with meson:
* -DDEBUG is not present in debugoptimized builds.
* meson ignores CFLAGS with --reconfigure, for example: CFLAGS="-DDEBUG"
meson --reconfigure ... doesn't update CFLAGS.

Marek

On Mon, Dec 10, 2018 at 6:11 PM Dylan Baker  wrote:

> Meson 0.49.0 has been out for a couple of days now, and I'd like to make
> the
> final call for autotools. My patch is so massive that it's a huge pain to
> send
> to the list, the latest versions is here:
> https://gitlab.freedesktop.org/dbaker/mesa/commits/delete-autotools
>
> Dylan
> ___
> 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

Re: [Mesa-dev] last call for autotools

[Rhys Kidd]

On Tue, 11 Dec 2018 at 16:46, Emil Velikov  wrote:

> On Tue, 11 Dec 2018 at 19:49, Dylan Baker  wrote:
> >
> > Quoting Emil Velikov (2018-12-11 10:48:56)
> > > On Tue, 11 Dec 2018 at 18:18, Eric Anholt  wrote:
> > > >
> > > > Emil Velikov  writes:
> > > >
> > > > > On Mon, 10 Dec 2018 at 23:11, Dylan Baker 
> wrote:
> > > > >>
> > > > >> Meson 0.49.0 has been out for a couple of days now, and I'd like
> to make the
> > > > >> final call for autotools. My patch is so massive that it's a huge
> pain to send
> > > > >> to the list, the latest versions is here:
> > > > >>
> https://gitlab.freedesktop.org/dbaker/mesa/commits/delete-autotools
> > > > >>
> > > > > Can you split this up a bit? I'm mostly conserved about a couple
> of things:
> > > > > - we're loosing multiple testing permutations with Travis -
> there's no
> > > > > meson equivalent
> > > > > - needed/missing bits are impossible to spot as-is
> > > > >
> > > > > Personally, I'd do something like:
> > > > >  - move .travis autotools permutations to meson
> > > > >  - docs changes
> > > > >  - rm Makefile{.*,}.am autogen.sh and configure.ac
> > > > >  - rm Makefile.sources
> > > > >  - .gitignore
> > > >
> > > > I don't think we should block on anything related to travis at this
> > > > point.  I wrote it initially hoping it would let us prevent build
> > > > breakages.  Instead, whenever I try to use travis to prevent build
> > > > breakage, I find that travis has already been broken for a while.
> > > >
> > > You must be really unlucky.
> > >
> > > > The CI needs to be integrated with our actual repository host, or it
> > > > doesn't work.  We should just delete .travis.yml and push the gitlab
> > > > stuff forward instead.
> > >
> > > If we have anything better in place (say gitlab CI/other) - sure.
> > > Removing something without a replacement in place is quite meh.
> > > That said, I think we agree that this is a topic for another day.
> > >
> > > HTH
> > > -Emil
> >
> > I'm actually finding myself agreeing that travis is just a pain. Could
> you help
> > me debug my WIP of porting the autotools tests to meson? They're just
> failing
> > randomly with no good debuging output:
> >
> > https://travis-ci.org/dcbaker/mesa/jobs/45289
> >
> If you don't mind I'll have a look first thing tomorrow morning. It's
> 9:43pm and I've yet to cook some food :-\
>

I was able to catch and fix most of the remaining meson / travis build
errors. RFC patch series on the mailing list that applies on top of Dylan's
WIP branch.

Hope that helps!


> -Emil
> ___
> 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

Re: [Mesa-dev] last call for autotools

[Samuel Pitoiset]

On 12/11/18 7:18 PM, Eric Anholt wrote:

Emil Velikov  writes:


On Mon, 10 Dec 2018 at 23:11, Dylan Baker  wrote:


Meson 0.49.0 has been out for a couple of days now, and I'd like to make the
final call for autotools. My patch is so massive that it's a huge pain to send
to the list, the latest versions is here:
https://gitlab.freedesktop.org/dbaker/mesa/commits/delete-autotools


Can you split this up a bit? I'm mostly conserved about a couple of things:
- we're loosing multiple testing permutations with Travis - there's no
meson equivalent
- needed/missing bits are impossible to spot as-is

Personally, I'd do something like:
  - move .travis autotools permutations to meson
  - docs changes
  - rm Makefile{.*,}.am autogen.sh and configure.ac
  - rm Makefile.sources
  - .gitignore


I don't think we should block on anything related to travis at this
point.  I wrote it initially hoping it would let us prevent build
breakages.  Instead, whenever I try to use travis to prevent build
breakage, I find that travis has already been broken for a while.

The CI needs to be integrated with our actual repository host, or it
doesn't work.  We should just delete .travis.yml and push the gitlab
stuff forward instead.



Gitlab CI is probably the way to go.



___
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

Re: [Mesa-dev] last call for autotools

[Emil Velikov]

On Tue, 11 Dec 2018 at 19:49, Dylan Baker  wrote:
>
> Quoting Emil Velikov (2018-12-11 10:48:56)
> > On Tue, 11 Dec 2018 at 18:18, Eric Anholt  wrote:
> > >
> > > Emil Velikov  writes:
> > >
> > > > On Mon, 10 Dec 2018 at 23:11, Dylan Baker  wrote:
> > > >>
> > > >> Meson 0.49.0 has been out for a couple of days now, and I'd like to 
> > > >> make the
> > > >> final call for autotools. My patch is so massive that it's a huge pain 
> > > >> to send
> > > >> to the list, the latest versions is here:
> > > >> https://gitlab.freedesktop.org/dbaker/mesa/commits/delete-autotools
> > > >>
> > > > Can you split this up a bit? I'm mostly conserved about a couple of 
> > > > things:
> > > > - we're loosing multiple testing permutations with Travis - there's no
> > > > meson equivalent
> > > > - needed/missing bits are impossible to spot as-is
> > > >
> > > > Personally, I'd do something like:
> > > >  - move .travis autotools permutations to meson
> > > >  - docs changes
> > > >  - rm Makefile{.*,}.am autogen.sh and configure.ac
> > > >  - rm Makefile.sources
> > > >  - .gitignore
> > >
> > > I don't think we should block on anything related to travis at this
> > > point.  I wrote it initially hoping it would let us prevent build
> > > breakages.  Instead, whenever I try to use travis to prevent build
> > > breakage, I find that travis has already been broken for a while.
> > >
> > You must be really unlucky.
> >
> > > The CI needs to be integrated with our actual repository host, or it
> > > doesn't work.  We should just delete .travis.yml and push the gitlab
> > > stuff forward instead.
> >
> > If we have anything better in place (say gitlab CI/other) - sure.
> > Removing something without a replacement in place is quite meh.
> > That said, I think we agree that this is a topic for another day.
> >
> > HTH
> > -Emil
>
> I'm actually finding myself agreeing that travis is just a pain. Could you 
> help
> me debug my WIP of porting the autotools tests to meson? They're just failing
> randomly with no good debuging output:
>
> https://travis-ci.org/dcbaker/mesa/jobs/45289
>
If you don't mind I'll have a look first thing tomorrow morning. It's
9:43pm and I've yet to cook some food :-\

-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] last call for autotools

[Dylan Baker]

Quoting Emil Velikov (2018-12-11 10:48:56)
> On Tue, 11 Dec 2018 at 18:18, Eric Anholt  wrote:
> >
> > Emil Velikov  writes:
> >
> > > On Mon, 10 Dec 2018 at 23:11, Dylan Baker  wrote:
> > >>
> > >> Meson 0.49.0 has been out for a couple of days now, and I'd like to make 
> > >> the
> > >> final call for autotools. My patch is so massive that it's a huge pain 
> > >> to send
> > >> to the list, the latest versions is here:
> > >> https://gitlab.freedesktop.org/dbaker/mesa/commits/delete-autotools
> > >>
> > > Can you split this up a bit? I'm mostly conserved about a couple of 
> > > things:
> > > - we're loosing multiple testing permutations with Travis - there's no
> > > meson equivalent
> > > - needed/missing bits are impossible to spot as-is
> > >
> > > Personally, I'd do something like:
> > >  - move .travis autotools permutations to meson
> > >  - docs changes
> > >  - rm Makefile{.*,}.am autogen.sh and configure.ac
> > >  - rm Makefile.sources
> > >  - .gitignore
> >
> > I don't think we should block on anything related to travis at this
> > point.  I wrote it initially hoping it would let us prevent build
> > breakages.  Instead, whenever I try to use travis to prevent build
> > breakage, I find that travis has already been broken for a while.
> >
> You must be really unlucky.
> 
> > The CI needs to be integrated with our actual repository host, or it
> > doesn't work.  We should just delete .travis.yml and push the gitlab
> > stuff forward instead.
> 
> If we have anything better in place (say gitlab CI/other) - sure.
> Removing something without a replacement in place is quite meh.
> That said, I think we agree that this is a topic for another day.
> 
> HTH
> -Emil

I'm actually finding myself agreeing that travis is just a pain. Could you help
me debug my WIP of porting the autotools tests to meson? They're just failing
randomly with no good debuging output:

https://travis-ci.org/dcbaker/mesa/jobs/45289

Dylan


signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] last call for autotools

[Emil Velikov]

On Tue, 11 Dec 2018 at 18:18, Eric Anholt  wrote:
>
> Emil Velikov  writes:
>
> > On Mon, 10 Dec 2018 at 23:11, Dylan Baker  wrote:
> >>
> >> Meson 0.49.0 has been out for a couple of days now, and I'd like to make 
> >> the
> >> final call for autotools. My patch is so massive that it's a huge pain to 
> >> send
> >> to the list, the latest versions is here:
> >> https://gitlab.freedesktop.org/dbaker/mesa/commits/delete-autotools
> >>
> > Can you split this up a bit? I'm mostly conserved about a couple of things:
> > - we're loosing multiple testing permutations with Travis - there's no
> > meson equivalent
> > - needed/missing bits are impossible to spot as-is
> >
> > Personally, I'd do something like:
> >  - move .travis autotools permutations to meson
> >  - docs changes
> >  - rm Makefile{.*,}.am autogen.sh and configure.ac
> >  - rm Makefile.sources
> >  - .gitignore
>
> I don't think we should block on anything related to travis at this
> point.  I wrote it initially hoping it would let us prevent build
> breakages.  Instead, whenever I try to use travis to prevent build
> breakage, I find that travis has already been broken for a while.
>
You must be really unlucky.

> The CI needs to be integrated with our actual repository host, or it
> doesn't work.  We should just delete .travis.yml and push the gitlab
> stuff forward instead.

If we have anything better in place (say gitlab CI/other) - sure.
Removing something without a replacement in place is quite meh.
That said, I think we agree that this is a topic for another day.

HTH
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] last call for autotools

[Eric Anholt]

Emil Velikov  writes:

> On Mon, 10 Dec 2018 at 23:11, Dylan Baker  wrote:
>>
>> Meson 0.49.0 has been out for a couple of days now, and I'd like to make the
>> final call for autotools. My patch is so massive that it's a huge pain to 
>> send
>> to the list, the latest versions is here:
>> https://gitlab.freedesktop.org/dbaker/mesa/commits/delete-autotools
>>
> Can you split this up a bit? I'm mostly conserved about a couple of things:
> - we're loosing multiple testing permutations with Travis - there's no
> meson equivalent
> - needed/missing bits are impossible to spot as-is
>
> Personally, I'd do something like:
>  - move .travis autotools permutations to meson
>  - docs changes
>  - rm Makefile{.*,}.am autogen.sh and configure.ac
>  - rm Makefile.sources
>  - .gitignore

I don't think we should block on anything related to travis at this
point.  I wrote it initially hoping it would let us prevent build
breakages.  Instead, whenever I try to use travis to prevent build
breakage, I find that travis has already been broken for a while.

The CI needs to be integrated with our actual repository host, or it
doesn't work.  We should just delete .travis.yml and push the gitlab
stuff forward instead.


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] last call for autotools

[Emil Velikov]

On Mon, 10 Dec 2018 at 23:11, Dylan Baker  wrote:
>
> Meson 0.49.0 has been out for a couple of days now, and I'd like to make the
> final call for autotools. My patch is so massive that it's a huge pain to send
> to the list, the latest versions is here:
> https://gitlab.freedesktop.org/dbaker/mesa/commits/delete-autotools
>
Can you split this up a bit? I'm mostly conserved about a couple of things:
- we're loosing multiple testing permutations with Travis - there's no
meson equivalent
- needed/missing bits are impossible to spot as-is

Personally, I'd do something like:
 - move .travis autotools permutations to meson
 - docs changes
 - rm Makefile{.*,}.am autogen.sh and configure.ac
 - rm Makefile.sources
 - .gitignore

git reset and git checkout --patch should make the above split a 5 min job ;-)

Thanks
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] last call for autotools

[Alex Deucher]

No offense, but if someone did bring up a need for autotools would it
really make a difference?  I believe the majority has spoken.

Alex
On Mon, Dec 10, 2018 at 6:11 PM Dylan Baker  wrote:
>
> Meson 0.49.0 has been out for a couple of days now, and I'd like to make the
> final call for autotools. My patch is so massive that it's a huge pain to send
> to the list, the latest versions is here:
> https://gitlab.freedesktop.org/dbaker/mesa/commits/delete-autotools
>
> Dylan
> ___
> 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

[Mesa-dev] last call for autotools

[Dylan Baker]

Meson 0.49.0 has been out for a couple of days now, and I'd like to make the
final call for autotools. My patch is so massive that it's a huge pain to send
to the list, the latest versions is here:
https://gitlab.freedesktop.org/dbaker/mesa/commits/delete-autotools

Dylan


signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev