Re: [Mesa-dev] [RFC PATCH] automake: add support to src/glsl/

2011-10-01 Thread Miles Bader 
2011/9/30 Jeremy Huddleston jerem...@freedesktop.org:
 Er, sure, but that brings up my second point:  the GPL restricts
 redistribution, not use, so you are not required to accept it to use
 GPL tools.

 Again, mirroring Alan's comment.  IANAL.  I just do what the Lawyers
 say.  I am told not to touch GLPv3 with a 10 foot poll while I have my
 Apple hat on, so I go beyond that and stay 10 miles away from GPLv3
 while I have my Apple hat on.

Vague statements like touch with a 10 foot pole are not meaningful.
[See below for more details]

 So the original complaint, that he is forced to accept the GPLv3
 to use autoconf seems a little confused.

 From the 2.62 release notes at 
 http://lists.gnu.org/archive/html/autotools-announce/2008-04/msg2.html:

 
 Meanwhile, several source files within the Autoconf project are under
 GPLv3+, as described in COPYINGv3; these files are used for building
 and installing Autoconf, but are not present in the installed
 programs.  The entire Autoconf project will move to GPLv3+ when the
 exception statements have been reformulated in terms of the Additional
 Permissions as described in section 7 of GPLv3.
 

 That alone means no 2.62 for me while I'm doing Apple-fu.

The GPL only applies to redistribution, not use.

_Users_ of autoconf (like you, as a Mesa dev), _projects_ that use
autoconf (like Mesa), _restributors_ of autoconf-using projects, and
_end-users_ of such projects do not need to accept the GPL at all,
v3 or otherwise, and are not affected by its terms.

So unless you're sending copies of autoconf _itself_ (not Mesa) to
other people, the version of GPL used in autoconf simply does not
apply to you.  [Again, see below for more detail]

 As the GPLv3 is widely used, I think this is an issue that will
 come up again, so it's worth some discussion.

 It's not that simple.  We should not thrust acceptance of a new
 license down our users throats.  The existence of GPLv3 is what
 prompted Gentoo to add support to portage to allow users to block
 installing packages based on license.  Clearly it's not just one or
 two companies that are afraid of it.

Again, using autoconf _does not require users to accept the GPLv3,
nor does it place them under any restrictions due to the GPL[v3]_.

autoconf-generated files and autoconf boilerplate in Mesa itself are
_under the Mesa license_, so one can happily restribute Mesa without
having to accept the GPL[v3] or incur any restrictions from it..

There is no forcing down the throat, as they simply aren't affected by it.

Here's my argument:

  (1) Mesa should try to respect corporate restrictions that are based
  on actual potential harm/consequence to the developer

  (2) However Mesa should _not_ feel beholden to follow those which
  have no valid basis (e.g. those based merely on dislike)
 
  (3) There are real negative consequences to not using newer version
  of autoconf, so it's not something that should be done lightly

  (4) Merely _using_ autoconf does not imply acceptance of the
  GPL[v3] or incur any restrictions from it (the GPL is about
  restribution, not use; a user is _not affected_)

  (5) for autoconf-related files distributed with Mesa itself (which
  Mesa contributors presumably do want to redistribute), there are
  three types:

 (5.1) autoconf-generated files:  these are not under the GPL but
   rather an extremely liberal license:

 # This file is free software; the Free Software Foundation
 # gives unlimited permission to copy and/or distribute it,
 # with or without modifications, as long as this notice is preserved.

 (5.2) autoconf boilerplate:  these use the GPL[v3], but contain a
   term which allows them to be restributed under the Mesa
   license as well:

 # As a special exception to the GNU General Public License, if you
 # distribute this file as part of a program that contains a
 # configuration script generated by Autoconf, you may include it under
 # the same distribution terms that you use for the rest of that 
program.

 (5.3) autoconf input files:  these are obviously purely Mesa, and
   are under the Mesa license, and not affected by the license
   of autoconf

 = So users, developers, and redistributors of Mesa do not need
to accept the GPL[v3], nor incur any restrictions from it,
based on autoconf-related files in Mesa.

   (6) Therefore, Mesa developers/users/redistributors are _not
   affected_ by the GPLv3, even if GPLv3'd versions of autoconf
   are used.

   (7) Thus while companies like Apple may not like the GPLv3, they
   are not actually affected by the use of GPLv3'd autoconf in
   Mesa, so there's no rational basis for their trying to restrict
   projects like Mesa from using such tools.

   (8) ... and therefore, Mesa should judge the harm from avoiding
   newer versions of autoconf as greater

Re: [Mesa-dev] [RFC PATCH] automake: add support to src/glsl/

2011-09-30 Thread Dan Nicholson 
Hi Matt,

On Sat, Sep 24, 2011 at 6:06 PM, Matt Turner matts...@gmail.com wrote:
 Signed-off-by: Matt Turner matts...@gmail.com
 ---
 The last discussion about using automake ([RFC] Convert mesa to 
 automake/libtool)
 ended without anything happening, probably because the branch wasn't ready.

 This patch is an attempt to get the ball rolling again. Without ripping out
 the entire existing build system in one swat, it attempts to gradually replace
 it directory by directory with automake.

 The patch has a few problems currently, and a few things that can possibly be
 done better:
        - Mainly, that building libmesa.a currently fails.
        - Not sure how to handle shared/static dricore options.
        - libtool defines VERSION (-DVERSION=...), which screws up the VERSION
          token in glsl_lexer.ll and glsl_parser.yy. I trivially renamed it.
        - libralloc.la can probably be combined into libglslcore.la, and not
          have to be added to every _LDADD line.
        - The rules for flex and bison can probably be eliminated by using
          YFLAGS and LFLAGS. I tried, but ylwrap gave me some error.

 I also killed off what looks to be a stray autogen.sh in src/glsl/.

 Please give it a test.

Sorry for not replying sooner. I've been too busy to attend to my
rapidly growing inbox.

I agree wholeheartedly with the change to automake, although I think
eventually you need Brian's buy in. Despite its flaws, the custom
Makefile system has worked for a lot of years. That said, I think some
of the issues can be conquered with documentation and education. I
also think the best feature of the current system, the static
configuration templates in configs/, can be emulated under autotools.

Anyway, I haven't looked closely at the patch, but I would echo
Gaetan's sentiment to start at the root Makefile.am and work down. I
did some work on this before I got busy. The commits are not really
clean, but you can get them in the automake branch in ~dbn/mesa.git on
annarchy. I think there's definitely a way to move along piecemeal
with a few suggestions:

- Don't feel the need to completely transform a whole Makefile in one
shot. This patch works on a fairly standalone piece, but once you get
into the intertwined parts you either end up with a megacommit or find
a way to work with smaller pieces. You can use the -local automake
targets to point to the existing rules instead of changing to the
automatic rules immediately.

- Some of the current make variables are constructed in
configs/default and configs/autoconf right now. You'll either need to
expand those in each Makefile you convert or just continue to source
$(top_builddir)/configs/current for a while.

- The default targets in the old Makefiles need to be changed to all
so the the root automaked Makefile calls the right thing when
descending.

I'm sure there's a ton of other gotchas. Anyway, I hope to get back to
this sometime.

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

Re: [Mesa-dev] [RFC PATCH] automake: add support to src/glsl/

2011-09-30 Thread Dan Nicholson 
On Sat, Sep 24, 2011 at 6:06 PM, Matt Turner matts...@gmail.com wrote:
 Signed-off-by: Matt Turner matts...@gmail.com
 ---
 The last discussion about using automake ([RFC] Convert mesa to 
 automake/libtool)
 ended without anything happening, probably because the branch wasn't ready.

 This patch is an attempt to get the ball rolling again. Without ripping out
 the entire existing build system in one swat, it attempts to gradually replace
 it directory by directory with automake.

 The patch has a few problems currently, and a few things that can possibly be
 done better:
        - Mainly, that building libmesa.a currently fails.
        - Not sure how to handle shared/static dricore options.
        - libtool defines VERSION (-DVERSION=...), which screws up the VERSION
          token in glsl_lexer.ll and glsl_parser.yy. I trivially renamed it.
        - libralloc.la can probably be combined into libglslcore.la, and not
          have to be added to every _LDADD line.
        - The rules for flex and bison can probably be eliminated by using
          YFLAGS and LFLAGS. I tried, but ylwrap gave me some error.

 I also killed off what looks to be a stray autogen.sh in src/glsl/.

 Please give it a test.

 Thanks,
 Matt

  configure.ac            |   10 ++
  src/glsl/Makefile       |  235 
 ---
  src/glsl/Makefile.am    |  146 +
  src/glsl/autogen.sh     |   12 ---
  src/glsl/glsl_lexer.ll  |    4 +-
  src/glsl/glsl_parser.yy |    6 +-
  6 files changed, 161 insertions(+), 252 deletions(-)
  delete mode 100644 src/glsl/Makefile
  create mode 100644 src/glsl/Makefile.am
  delete mode 100755 src/glsl/autogen.sh

 diff --git a/configure.ac b/configure.ac
 index b2606bf..fd1082d 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -17,6 +17,13 @@ AC_INIT([Mesa],[mesa_version],
  AC_CONFIG_AUX_DIR([bin])
  AC_CANONICAL_HOST

 +# Initialize Automake
 +AM_INIT_AUTOMAKE([foreign dist-bzip2])
 +AM_MAINTAINER_MODE
 +
 +# Initialize libtool
 +AC_PROG_LIBTOOL
 +
  dnl Save user CFLAGS and CXXFLAGS so one can override the default ones
  USER_CFLAGS=$CFLAGS
  USER_CXXFLAGS=$CXXFLAGS
 @@ -2010,3 +2017,6 @@ echo         PYTHON2:         $PYTHON2
  echo 
  echo         Run '${MAKE-make}' to build Mesa
  echo 
 +
 +AC_CONFIG_FILES([src/glsl/Makefile])
 +AC_OUTPUT

Just a quick note that there are already AC_CONFIG_FILES and AC_OUTPUT
calls in configure.ac, so you should be able to use those.

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

Re: [Mesa-dev] [RFC PATCH] automake: add support to src/glsl/

2011-09-30 Thread Dan Nicholson 
On Sun, Sep 25, 2011 at 12:06 PM, Gaetan Nadon mems...@videotron.ca wrote:
 On Sat, 2011-09-24 at 21:06 -0400, Matt Turner wrote:

 The patch has a few problems currently, and a few things that can possibly
 be
 done better:
 - Mainly, that building libmesa.a currently fails.
 - Not sure how to handle shared/static dricore options.
 - libtool defines VERSION (-DVERSION=...), which screws up the
 VERSION
   token in glsl_lexer.ll and glsl_parser.yy. I trivially renamed it.
 - libralloc.la can probably be combined into libglslcore.la, and not
   have to be added to every _LDADD line.
 - The rules for flex and bison can probably be eliminated by using
   YFLAGS and LFLAGS. I tried, but ylwrap gave me some error.

 I had a quick look, configure.ac is huge and has a big impact on Makefiles.
 I think it should be reviewed and cleaned-up to understand how it affects
 makefiles.

 Just a few examples of statements to investigate. Not that they are bad, but
 they may be needed because there was no automake and they could possibly
 conflict.

 AC_CHECK_PROGS([MAKE], [gmake make])

 AC_PATH_PROG([MKDEP], [makedepend])
     Can 'makedepend' impact the dependencies automake generates?

 AC_PATH_PROG([FLEX], [flex])
 AC_PATH_PROG([BISON], [bison])
     Some platforms have different names. The rules in the automake make file
 may not work if configure.ac does not use AC_PROG_YACC and AC_PROG_LEX
 This is the configuration in xorg:

 AC_PROG_YACC
 AC_PATH_PROG([YACC_INST], $YACC)
 if test ! -f $srcdir/gram.c; then
    if test -z $YACC_INST; then
   AC_MSG_ERROR([yacc not found - unable to compile gram.y])
    fi
 fi
 AC_PROG_LEX

 test x$INSTALL = x$ac_install_sh  INSTALL='$(MINSTALL)'
     On some platforms, this may result in a different install program being
 used whether the makefile is from mesa or automake.

 There is a 'configuration' file. How will the automake makefiles take that
 into account.

 It looks like there are 'conflicts' between mesa makefiles and automake
 which is expected due to the size of the project. Some preparation work
 should be done upfront to make both system coexist and then have automake
 gradually replace mesa makefiles. This would be useful work anyway.

Just a quick note that there are a lot of custom things in the current
configure.ac to make things work better with the current system. Until
that system is completely gone, a lot of the hacks in here need to
remain. So, I'd suggest leaving configure.ac mostly as is unless
there's a specific thing that's breaking automake. You can certainly
clean up a lot of things in there if automake is used through the
whole tree, but that's a ways off.

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

Re: [Mesa-dev] [RFC PATCH] automake: add support to src/glsl/

2011-09-30 Thread Jeremy Huddleston 
 So the original complaint, that he is forced to accept the GPLv3
 to use autoconf seems a little confused.
 
 From the 2.62 release notes at 
 http://lists.gnu.org/archive/html/autotools-announce/2008-04/msg2.html:
 
 
 Meanwhile, several source files within the Autoconf project are under
 GPLv3+, as described in COPYINGv3; these files are used for building
 and installing Autoconf, but are not present in the installed
 programs.  The entire Autoconf project will move to GPLv3+ when the
 exception statements have been reformulated in terms of the Additional
 Permissions as described in section 7 of GPLv3.
 
 
 That alone means no 2.62 for me while I'm doing Apple-fu.
 
 The GPL only applies to redistribution, not use.
 
 _Users_ of autoconf (like you, as a Mesa dev), _projects_ that use
 autoconf (like Mesa), _restributors_ of autoconf-using projects, and
 _end-users_ of such projects do not need to accept the GPL at all,
 v3 or otherwise, and are not affected by its terms.

In order for me to *use* autoconf in our build system, I need to *use* the 
version that we build/ship.

 So unless you're sending copies of autoconf _itself_ (not Mesa) to
 other people,

We are distributing autoconf.  Apple's autoconf is stuck at 2.61 and not able 
to go up.  When building mesa in our build system, we use our autoconf.  
Furthermore, as stated before by Alan, I'm restricted from *using* GPLv3 
software.  I direct you to public statements from Apple by people who are paid 
to make public statements.  I just do what the lawyers say and no amount of 
arguing about the license will change it.

With my personal hat on, I use GPLv3 software, I contribute patches to GPLv3 
projects, but I will never release software as GPLv3 because of the headaches 
it causes.

 the version of GPL used in autoconf simply does not
 apply to you.  [Again, see below for more detail]

It applies to us in what version of autoconf we can redistribute and thus which 
version we can use.

 As the GPLv3 is widely used, I think this is an issue that will
 come up again, so it's worth some discussion.
 
 It's not that simple.  We should not thrust acceptance of a new
 license down our users throats.  The existence of GPLv3 is what
 prompted Gentoo to add support to portage to allow users to block
 installing packages based on license.  Clearly it's not just one or
 two companies that are afraid of it.
 
 Again, using autoconf _does not require users to accept the GPLv3,
 nor does it place them under any restrictions due to the GPL[v3]_.
 
 ...

 Maybe I'm wrong somewhere, but _please_ point out _where_, rather than
 using vague handwaving.


I'm not trying to handwave.  I'm just repeating to you what I've been told 
and the reasons for it.  I understand that you disagree with those reasons, but 
IANAL and am not qualified to respond to these points in detail on behalf of 
Apple.  I wish I could give you the answers you seek, but that kind of 
statement is well above my pay grade.

--Jeremy

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

Re: [Mesa-dev] [RFC PATCH] automake: add support to src/glsl/

2011-09-29 Thread Jeremy Huddleston 

On Sep 28, 2011, at 23:28, Miles Bader wrote:

 2011/9/29 Alan Coopersmith alan.coopersm...@oracle.com:
 _Why_ is the GPLv3 not acceptable, when the GPLv2 was?
 
 Note his employer, which is well known as not accepting the GPLv3,
 possibly due to it being a mobile phone manufacturer, and the GPLv3's
 free patent license grant not fitting well with the current mobile phone
 environment in which every manufacturer is involved in more patent
 infringement lawsuits  countersuits than anyone wants to consider.
 
 Er, sure, but that brings up my second point:  the GPL restricts
 redistribution, not use, so you are not required to accept it to use
 GPL tools.

Again, mirroring Alan's comment.  IANAL.  I just do what the Lawyers say.  I am 
told not to touch GLPv3 with a 10 foot poll while I have my Apple hat on, so I 
go beyond that and stay 10 miles away from GPLv3 while I have my Apple hat on.

 So the original complaint, that he is forced to accept the GPLv3 to
 use autoconf seems a little confused.  [of course certainly it's
 possible that _I'm_ confused, or there's a subtlety I'm missing.]

From the 2.62 release notes at 
http://lists.gnu.org/archive/html/autotools-announce/2008-04/msg2.html:


Meanwhile, several source files within the Autoconf project are under
GPLv3+, as described in COPYINGv3; these files are used for building
and installing Autoconf, but are not present in the installed
programs.  The entire Autoconf project will move to GPLv3+ when the
exception statements have been reformulated in terms of the Additional
Permissions as described in section 7 of GPLv3.


That alone means no 2.62 for me while I'm doing Apple-fu.

 Since most developers on the X  Mesa projects are doing it as part of
 our paid employment, we are subject to the constraints of the licenses
 our employers are willing to accept, and no amount of logic or arguments
 from outsiders can trump company policy.
 
 As the GPLv3 is widely used, I think this is an issue that will come
 up again, so it's worth some discussion.

It's not that simple.  We should not thrust acceptance of a new license down 
our users throats.  The existence of GPLv3 is what prompted Gentoo to add 
support to portage to allow users to block installing packages based on 
license.  Clearly it's not just one or two companies that are afraid of it.

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

Re: [Mesa-dev] [RFC PATCH] automake: add support to src/glsl/

2011-09-28 Thread Gaetan Nadon 
On Sat, 2011-09-24 at 21:06 -0400, Matt Turner wrote:

 The last discussion about using automake ([RFC] Convert mesa to
 automake/libtool)
 ended without anything happening, probably because the branch wasn't
 ready.
 
 This patch is an attempt to get the ball rolling again. Without
 ripping out
 the entire existing build system in one swat, it attempts to gradually
 replace
 it directory by directory with automake. 


Some thoughts here, fresh from the oven, not analyzed:

- I would start from the root makefile and work my way down, invoking
the mesa makefile in the subdirs. It is intuitive, but I don't know if
it is feasible.

- The minimum autoconf version should be 2.60. Features above 2.60
should not be used. Starting v 2.62 there is a license controversy and
some platforms x.org support cannot use anything produce with 2.62 or
above.

- Minimum automake is 1.10. features above 1.10 must be avoided. 

- Decide if mesa is ok depending on util-macros. Lots of things are
taken for granted by x.org developers which won't be there in
automake-mesa. 

There should be some useful info in:
http://wiki.x.org/wiki/ModularDevelopersGuide
http://wiki.x.org/wiki/NewModuleGuidelines
Both are up to date.

Automake has considered coexistence with custome makefile:
http://www.gnu.org/software/automake/manual/automake.html#Third_002dParty-Makefiles
This may help crafting a conversion strategy.

Suggestion:

- Do not use the pair AM_MAINTAINER_MODE and --enable-maintainer-mode in
autogen.sh. They will eventually be removed in x.org. These were created
by Automake as a CVS time stamp workaround. But it's a long story. it's
a noop for git builds.






signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC PATCH] automake: add support to src/glsl/

2011-09-28 Thread Gaetan Nadon 
On Sat, 2011-09-24 at 21:06 -0400, Matt Turner wrote:

 The patch has a few problems currently, and a few things that can
 possibly be
 done better:
 - Mainly, that building libmesa.a currently fails.
 - Not sure how to handle shared/static dricore options.
 - libtool defines VERSION (-DVERSION=...), which screws up the
 VERSION
   token in glsl_lexer.ll and glsl_parser.yy. I trivially
 renamed it.
 - libralloc.la can probably be combined into libglslcore.la,
 and not
   have to be added to every _LDADD line.
 - The rules for flex and bison can probably be eliminated by
 using
   YFLAGS and LFLAGS. I tried, but ylwrap gave me some error.
 

I had a quick look, configure.ac is huge and has a big impact on
Makefiles. I think it should be reviewed and cleaned-up to understand
how it affects makefiles.

Just a few examples of statements to investigate. Not that they are bad,
but they may be needed because there was no automake and they could
possibly conflict.

AC_CHECK_PROGS([MAKE], [gmake make])

AC_PATH_PROG([MKDEP], [makedepend])
Can 'makedepend' impact the dependencies automake generates?

AC_PATH_PROG([FLEX], [flex])
AC_PATH_PROG([BISON], [bison])
Some platforms have different names. The rules in the
automake make file may not work if configure.ac does not use
AC_PROG_YACC and AC_PROG_LEX
This is the configuration in xorg:

AC_PROG_YACC
AC_PATH_PROG([YACC_INST], $YACC)
if test ! -f $srcdir/gram.c; then
   if test -z $YACC_INST; then
  AC_MSG_ERROR([yacc not found - unable to compile gram.y])
   fi
fi
AC_PROG_LEX

test x$INSTALL = x$ac_install_sh  INSTALL='$(MINSTALL)'
On some platforms, this may result in a different install
program being used whether the makefile is from mesa or
automake. 

There is a 'configuration' file. How will the automake makefiles
take that into account.

It looks like there are 'conflicts' between mesa makefiles and automake
which is expected due to the size of the project. Some preparation work
should be done upfront to make both system coexist and then have
automake gradually replace mesa makefiles. This would be useful work
anyway.






signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC PATCH] automake: add support to src/glsl/

2011-09-28 Thread Gaetan Nadon 
On Sun, 2011-09-25 at 15:41 -0400, Matt Turner wrote:

 On Sun, Sep 25, 2011 at 3:06 PM, Gaetan Nadon mems...@videotron.ca wrote:
  I had a quick look, configure.ac is huge and has a big impact on Makefiles.
  I think it should be reviewed and cleaned-up to understand how it affects
  makefiles.
 
  Just a few examples of statements to investigate. Not that they are bad, but
  they may be needed because there was no automake and they could possibly
  conflict.
 
  AC_CHECK_PROGS([MAKE], [gmake make])
 
  AC_PATH_PROG([MKDEP], [makedepend])
  Can 'makedepend' impact the dependencies automake generates?
 
 It doesn't look like it affects anything in src/glsl/, at least.

Good. I did not know, so that's why I asked :-) Thanks.

 
  AC_PATH_PROG([FLEX], [flex])
  AC_PATH_PROG([BISON], [bison])
  Some platforms have different names. The rules in the automake make file
  may not work if configure.ac does not use AC_PROG_YACC and AC_PROG_LEX
  This is the configuration in xorg:
 
  AC_PROG_YACC
  AC_PATH_PROG([YACC_INST], $YACC)
  if test ! -f $srcdir/gram.c; then
 if test -z $YACC_INST; then
AC_MSG_ERROR([yacc not found - unable to compile gram.y])
 fi
  fi
  AC_PROG_LEX
 
 Probably a good idea. Should the same thing done for $YACC be done for $LEX?

Not required. Unfortunately for YACC, the macro sets the variable to
yacc if it cannot find any program. So you will never know if it was
found or not
The test is to support tarball builds when yacc is not available. If you
don't have the generated C code and don't have yacc, you are out of
luck.

 
  test x$INSTALL = x$ac_install_sh  INSTALL='$(MINSTALL)'
  On some platforms, this may result in a different install program being
  used whether the makefile is from mesa or automake.
 
 Maybe you understand the reason for that better than I do:
 http://cgit.freedesktop.org/mesa/mesa/commit/?id=bc302b2a33ceffe454bcf443daa0ac1edc118e9b

With automake, the fallback (no 'install' O/S executable) is the
install-sh script. Without automake, no install-sh. The minstall is a
replacement for install-sh that is intended to work as /usr/bin/install
does.

What I was pointing out is that, on platforms not
having /usr/bin/install,  the mesa makefile will use minstall while the
automake makefile would normally use install-sh. If the automake
makefiles are coerced into using minstall that would be a noop.

If you are moving towards a non-hacked automake world, the INSTALL
variable should not be used for mesa makefiles. It all depends on the
end goals and the motivation behind the conversion to automake which has
not been explained yet.

One wildcard here is that install-sh has never been tested for the mesa
libs. I don't suspect there are problems as we would have heard about it
in xorg. 


  There is a 'configuration' file. How will the automake makefiles take that
  into account.
 
 I would think the configs/autoconf file is something we'd kill off
 after the last static Makefile is gone.
 
  It looks like there are 'conflicts' between mesa makefiles and automake
  which is expected due to the size of the project. Some preparation work
  should be done upfront to make both system coexist and then have automake
  gradually replace mesa makefiles. This would be useful work anyway.
 
 There's definitely some clean ups to be done, that's for sure.


Regarding Makefile.am: Use $(VAR) rather than @VAR@ Automake has an
explanation for that.

You will need AC_CONFIG_HEADERS, there will too many -D on the command
line.


-I../../include can be $(top_srcdir/include) Easy to read, easy to copy 
even across makefiles at any depth

 
 Matt




signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC PATCH] automake: add support to src/glsl/

2011-09-28 Thread Gaetan Nadon 
On Sun, 2011-09-25 at 16:55 -0400, Matt Turner wrote:

 On Sun, Sep 25, 2011 at 4:22 PM, Gaetan Nadon mems...@videotron.ca wrote:
  If you are moving towards a non-hacked automake world, the INSTALL variable
  should not be used for mesa makefiles. It all depends on the end goals and
  the motivation behind the conversion to automake which has not been
  explained yet.
 
 Personally, being able to do out-of-tree builds is a big improvement
 by switching to automake.
 
 Dan lists a number of other benefits in his first email here:
 http://lists.freedesktop.org/archives/mesa-dev/2010-May/000431.html
 

Sure, I was wondering if there were something specific to watch for in
mesa.

  There is a 'configuration' file. How will the automake makefiles take that
  into account.
 
  I would think the configs/autoconf file is something we'd kill off
  after the last static Makefile is gone.
 
  It looks like there are 'conflicts' between mesa makefiles and automake
  which is expected due to the size of the project. Some preparation work
  should be done upfront to make both system coexist and then have automake
  gradually replace mesa makefiles. This would be useful work anyway.
 
  There's definitely some clean ups to be done, that's for sure.
 
  Regarding Makefile.am: Use $(VAR) rather than @VAR@ Automake has an
  explanation for that.
 
  You will need AC_CONFIG_HEADERS, there will too many -D on the command line.
 
  -I../../include can be $(top_srcdir/include) Easy to read, easy to copy
  even across makefiles at any depth
 
 Good, I'll make those two changes. Similarly, we have a lot of -D
 flags like -DFEATURE_GL=1. I suppose they are best left in CPPFLAGS?

Actually preprocessor directives (-I -D) go in AM_CPPFLAGS. Compiler
flags go in AM_CFLAGS.
Neither CPPFLAGS nor CFLAGS should be set in configure.ac or in the
makefile, except for a configuration test (in configure.ac) where they
are saved and restored. This allows builder to have the final say in the
compiler flags to use for the build as per Automake.

A reminder to use AM_CONDITIONAL in makefile rather than plain
variables. It takes care of doing a correct tarball with 'make dist'.
Saves having to maintain two lists of SUBDIRS to traverse.

 
 Thanks,
 Matt




signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC PATCH] automake: add support to src/glsl/

2011-09-28 Thread Miles Bader 
On , Matt Turner matts...@gmail.com wrote:
 In short, 2.62 is the first version that includes GPLv3 tools to build
 autoconf, even though what is installed is GPLv2.

 [1] http://lists.x.org/archives/xorg-devel/2011-June/022724.html

Thanks, that explains the significance of 2.62 -- but it doesn't
actually explain the problem; it just says In order to build it, I
would have to accept GPLv3 (which is not acceptable).

_Why_ is the GPLv3 not acceptable, when the GPLv2 was?

What does I would have to accept the GPLv3 [to build it] even mean?
The GPL applies to redistribution, not use.

I'm still mystified.

Thanks,

-Miles

-- 
Cat is power.  Cat is peace.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC PATCH] automake: add support to src/glsl/

2011-09-28 Thread Alan Coopersmith 

On 09/28/11 09:58 AM, Miles Bader wrote:

On , Matt Turnermatts...@gmail.com  wrote:

[1] http://lists.x.org/archives/xorg-devel/2011-June/022724.html


Thanks, that explains the significance of 2.62 -- but it doesn't
actually explain the problem; it just says In order to build it, I
would have to accept GPLv3 (which is not acceptable).

_Why_ is the GPLv3 not acceptable, when the GPLv2 was?


Note his employer, which is well known as not accepting the GPLv3,
possibly due to it being a mobile phone manufacturer, and the GPLv3's
free patent license grant not fitting well with the current mobile phone
environment in which every manufacturer is involved in more patent
infringement lawsuits  countersuits than anyone wants to consider.

Since most developers on the X  Mesa projects are doing it as part of
our paid employment, we are subject to the constraints of the licenses
our employers are willing to accept, and no amount of logic or arguments
from outsiders can trump company policy.

--
-Alan Coopersmith-alan.coopersm...@oracle.com
 Oracle Solaris Platform Engineering: X Window System

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

Re: [Mesa-dev] [RFC PATCH] automake: add support to src/glsl/

2011-09-27 Thread Ian Romanick 

On 09/26/2011 03:05 PM, Eric Anholt wrote:

On Mon, 26 Sep 2011 11:38:10 -0400, Matt Turnermatts...@gmail.com  wrote:

On Mon, Sep 26, 2011 at 11:29 AM, Eric Anholte...@anholt.net  wrote:

On Sun, 25 Sep 2011 15:36:02 -0400, Matt Turnermatts...@gmail.com  wrote:

diff --git a/src/glsl/glsl_lexer.ll b/src/glsl/glsl_lexer.ll
index cfd8926..dd7c68c 100644
--- a/src/glsl/glsl_lexer.ll
+++ b/src/glsl/glsl_lexer.ll
@@ -104,8 +104,8 @@ HASH  ^{SPC}#{SPC}

  /* Preprocessor tokens. */
  ^[ \t]*#[ \t]*$  ;
-^[ \t]*#[ \t]*version{ BEGIN PP; return VERSION; }
-^[ \t]*#[ \t]*extension  { BEGIN PP; return EXTENSION; }
+^[ \t]*#[ \t]*version{ BEGIN PP; return GLSL_VERS; }
+^[ \t]*#[ \t]*extension  { BEGIN PP; return GLSL_EXTENSION; }
  {HASH}line{SPCP}{INT}{SPCP}{INT}{SPC}$ {
  /* Eat characters until the first digit is
   * encountered
diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy
index 25d02fb..831f72a 100644
--- a/src/glsl/glsl_parser.yy
+++ b/src/glsl/glsl_parser.yy
@@ -106,7 +106,7 @@
  %token INVARIANT
  %token LOWP MEDIUMP HIGHP SUPERP PRECISION

-%token VERSION EXTENSION LINE COLON EOL INTERFACE OUTPUT
+%token GLSL_VERS GLSL_EXTENSION LINE COLON EOL INTERFACE OUTPUT
  %token PRAGMA_DEBUG_ON PRAGMA_DEBUG_OFF
  %token PRAGMA_OPTIMIZE_ON PRAGMA_OPTIMIZE_OFF
  %token PRAGMA_INVARIANT_ALL
@@ -228,7 +228,7 @@ translation_unit:

  version_statement:
   /* blank - no #version specified: defaults are already set */
- | VERSION INTCONSTANT EOL
+ | GLSL_VERS INTCONSTANT EOL
   {
  bool supported = false;

@@ -296,7 +296,7 @@ any_identifier:
   ;

  extension_statement:
- EXTENSION any_identifier COLON any_identifier EOL
+ GLSL_EXTENSION any_identifier COLON any_identifier EOL
   {
  if (!_mesa_glsl_process_extension($2,  @2, $4,  @4, state)) {
 YYERROR;
--
1.7.3.4



I'd prefer VERSION to be fully spelled out, and it's probably worth
being in a separate commit.


Yeah, will do. I feel like there's a better way to deal with this anyway.


For the other tokens with conflicts, we appended _TOK.  (INLINE_TOK,
PUBLIC_TOK), so probably just use that convention.


I was just going to say the same thing.  EXTENSION_TOK and VERSION_TOK 
are much preferred names.

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

Re: [Mesa-dev] [RFC PATCH] automake: add support to src/glsl/

2011-09-26 Thread Eric Anholt 
On Sun, 25 Sep 2011 15:36:02 -0400, Matt Turner matts...@gmail.com wrote:
Non-text part: multipart/mixed
 On Sat, Sep 24, 2011 at 9:06 PM, Matt Turner matts...@gmail.com wrote:
  Signed-off-by: Matt Turner matts...@gmail.com
  ---
  The last discussion about using automake ([RFC] Convert mesa to 
  automake/libtool)
  ended without anything happening, probably because the branch wasn't ready.
 
  This patch is an attempt to get the ball rolling again. Without ripping out
  the entire existing build system in one swat, it attempts to gradually 
  replace
  it directory by directory with automake.
 
  The patch has a few problems currently, and a few things that can possibly 
  be
  done better:
         - Mainly, that building libmesa.a currently fails.
         - Not sure how to handle shared/static dricore options.
         - libtool defines VERSION (-DVERSION=...), which screws up the 
  VERSION
           token in glsl_lexer.ll and glsl_parser.yy. I trivially renamed it.
         - libralloc.la can probably be combined into libglslcore.la, and not
           have to be added to every _LDADD line.
         - The rules for flex and bison can probably be eliminated by using
           YFLAGS and LFLAGS. I tried, but ylwrap gave me some error.

I'd like to add other libs (hash table) at the src/ level, too, so a
single helper lib that is mesa's shared, non-mtypes-using stuff but not
things that are really Mesa like the glsl compiler would be nice.

I do want to see dricore continue.  It's a really nice feature for
development, by shortening build times, and it seems like distros want
it.  However, it was pretty broken as-is.  You had to build every helper
lib into a separate installed .so, because the build system was lame,
and dependencies were even more screwed up than usual.  I'd say go ahead
even if dricore isn't fixed.  I don't think we'll have any big problem
recovering it for automake once core Mesa is converted.

 diff --git a/src/glsl/Makefile.am b/src/glsl/Makefile.am
 new file mode 100644
 index 000..a31d845
 --- /dev/null
 +++ b/src/glsl/Makefile.am
 @@ -0,0 +1,152 @@
 +LEX = @FLEX@
 +YACC = @BISON@
 +
 +noinst_LTLIBRARIES = \
 + libhash_table.la \
 + libstandalone_scaffolding.la \
 + libsymbol_table.la \
 + libmain.la \
 + libglcpp.la \
 + libglslcore.la
 +lib_LTLIBRARIES = libglsl.la
 +noinst_PROGRAMS = glcpp/glcpp builtin_compiler glsl_test
 +bin_PROGRAMS = glsl_compiler
 +
 +INCLUDES = \
 +-I. \
 + -I../mesa \
 + -I../mapi \
 + -Iglcpp \
 + -I../../include
 +
 +BUILT_SOURCES = \
 + glcpp/glcpp-lex.c \
 + glcpp/glcpp-parse.c \
 + glsl_lexer.cpp \
 + glsl_parser.cpp \
 + builtin_function.cpp
 +
 +libhash_table_la_SOURCES = ../mesa/program/hash_table.c
 +libstandalone_scaffolding_la_SOURCES = standalone_scaffolding.cpp
 +libsymbol_table_la_SOURCES = ../mesa/program/symbol_table.c
 +libmain_la_SOURCES = main.cpp
 +
 +libglcpp_la_SOURCES = \
 + glcpp/glcpp-lex.c \
 + glcpp/glcpp-parse.c \
 + glcpp/pp.c \
 + ralloc.c
 +
 +glcpp_glcpp_SOURCES = glcpp/glcpp.c
 +glcpp_glcpp_LDADD = libglcpp.la libhash_table.la
 +
 +libglslcore_la_SOURCES = \
 + strtod.c \
 + ast_expr.cpp \
 + ast_function.cpp \
 + ast_to_hir.cpp \
 + ast_type.cpp \
 + glsl_lexer.cpp \
 + glsl_parser.cpp \
 + glsl_parser_extras.cpp \
 + glsl_types.cpp \
 + glsl_symbol_table.cpp \
 + hir_field_selection.cpp \
 + ir_basic_block.cpp \
 + ir_clone.cpp \
 + ir_constant_expression.cpp \
 + ir.cpp \
 + ir_expression_flattening.cpp \
 + ir_function_can_inline.cpp \
 + ir_function_detect_recursion.cpp \
 + ir_function.cpp \
 + ir_hierarchical_visitor.cpp \
 + ir_hv_accept.cpp \
 + ir_import_prototypes.cpp \
 + ir_print_visitor.cpp \
 + ir_reader.cpp \
 + ir_rvalue_visitor.cpp \
 + ir_set_program_inouts.cpp \
 + ir_validate.cpp \
 + ir_variable.cpp \
 + ir_variable_refcount.cpp \
 + linker.cpp \
 + link_functions.cpp \
 + loop_analysis.cpp \
 + loop_controls.cpp \
 + loop_unroll.cpp \
 + lower_clip_distance.cpp \
 + lower_discard.cpp \
 + lower_if_to_cond_assign.cpp \
 + lower_instructions.cpp \
 + lower_jumps.cpp \
 + lower_mat_op_to_vec.cpp \
 + lower_noise.cpp \
 + lower_texture_projection.cpp \
 + lower_variable_index_to_cond_assign.cpp \
 + lower_vec_index_to_cond_assign.cpp \
 + lower_vec_index_to_swizzle.cpp \
 + lower_vector.cpp \
 + opt_algebraic.cpp \
 + opt_constant_folding.cpp \
 + opt_constant_propagation.cpp \
 + opt_constant_variable.cpp \
 + opt_copy_propagation.cpp \
 + opt_copy_propagation_elements.cpp \
 + opt_dead_code.cpp \
 + opt_dead_code_local.cpp \
 + opt_dead_functions.cpp \
 + opt_discard_simplification.cpp \
 + opt_function_inlining.cpp \
 + opt_if_simplification.cpp \
 + opt_noop_swizzle.cpp \
 +

Re: [Mesa-dev] [RFC PATCH] automake: add support to src/glsl/

2011-09-26 Thread Matt Turner 
On Mon, Sep 26, 2011 at 11:29 AM, Eric Anholt e...@anholt.net wrote:
 On Sun, 25 Sep 2011 15:36:02 -0400, Matt Turner matts...@gmail.com wrote:
 Non-text part: multipart/mixed
 On Sat, Sep 24, 2011 at 9:06 PM, Matt Turner matts...@gmail.com wrote:
  Signed-off-by: Matt Turner matts...@gmail.com
  ---
  The last discussion about using automake ([RFC] Convert mesa to 
  automake/libtool)
  ended without anything happening, probably because the branch wasn't ready.
 
  This patch is an attempt to get the ball rolling again. Without ripping out
  the entire existing build system in one swat, it attempts to gradually 
  replace
  it directory by directory with automake.
 
  The patch has a few problems currently, and a few things that can possibly 
  be
  done better:
         - Mainly, that building libmesa.a currently fails.
         - Not sure how to handle shared/static dricore options.
         - libtool defines VERSION (-DVERSION=...), which screws up the 
  VERSION
           token in glsl_lexer.ll and glsl_parser.yy. I trivially renamed it.
         - libralloc.la can probably be combined into libglslcore.la, and not
           have to be added to every _LDADD line.
         - The rules for flex and bison can probably be eliminated by using
           YFLAGS and LFLAGS. I tried, but ylwrap gave me some error.

 I'd like to add other libs (hash table) at the src/ level, too, so a
 single helper lib that is mesa's shared, non-mtypes-using stuff but not
 things that are really Mesa like the glsl compiler would be nice.

 I do want to see dricore continue.  It's a really nice feature for
 development, by shortening build times, and it seems like distros want
 it.  However, it was pretty broken as-is.  You had to build every helper
 lib into a separate installed .so, because the build system was lame,
 and dependencies were even more screwed up than usual.  I'd say go ahead
 even if dricore isn't fixed.  I don't think we'll have any big problem
 recovering it for automake once core Mesa is converted.

I definitely want dricore as well.

If you've got a few minutes, it'd be very helpful if you could try the
patch and see if you can see why libmesa.a fails to compile with it.

 diff --git a/src/glsl/Makefile.am b/src/glsl/Makefile.am
 new file mode 100644
 index 000..a31d845
 --- /dev/null
 +++ b/src/glsl/Makefile.am
 @@ -0,0 +1,152 @@
 +LEX = @FLEX@
 +YACC = @BISON@
 +
 +noinst_LTLIBRARIES = \
 +     libhash_table.la \
 +     libstandalone_scaffolding.la \
 +     libsymbol_table.la \
 +     libmain.la \
 +     libglcpp.la \
 +     libglslcore.la
 +lib_LTLIBRARIES = libglsl.la
 +noinst_PROGRAMS = glcpp/glcpp builtin_compiler glsl_test
 +bin_PROGRAMS = glsl_compiler
 +
 +INCLUDES = \
 +        -I. \
 +     -I../mesa \
 +     -I../mapi \
 +     -Iglcpp \
 +     -I../../include
 +
 +BUILT_SOURCES = \
 +     glcpp/glcpp-lex.c \
 +     glcpp/glcpp-parse.c \
 +     glsl_lexer.cpp \
 +     glsl_parser.cpp \
 +     builtin_function.cpp
 +
 +libhash_table_la_SOURCES = ../mesa/program/hash_table.c
 +libstandalone_scaffolding_la_SOURCES = standalone_scaffolding.cpp
 +libsymbol_table_la_SOURCES = ../mesa/program/symbol_table.c
 +libmain_la_SOURCES = main.cpp
 +
 +libglcpp_la_SOURCES = \
 +     glcpp/glcpp-lex.c \
 +     glcpp/glcpp-parse.c \
 +     glcpp/pp.c \
 +     ralloc.c
 +
 +glcpp_glcpp_SOURCES = glcpp/glcpp.c
 +glcpp_glcpp_LDADD = libglcpp.la libhash_table.la
 +
 +libglslcore_la_SOURCES = \
 +     strtod.c \
 +     ast_expr.cpp \
 +     ast_function.cpp \
 +     ast_to_hir.cpp \
 +     ast_type.cpp \
 +     glsl_lexer.cpp \
 +     glsl_parser.cpp \
 +     glsl_parser_extras.cpp \
 +     glsl_types.cpp \
 +     glsl_symbol_table.cpp \
 +     hir_field_selection.cpp \
 +     ir_basic_block.cpp \
 +     ir_clone.cpp \
 +     ir_constant_expression.cpp \
 +     ir.cpp \
 +     ir_expression_flattening.cpp \
 +     ir_function_can_inline.cpp \
 +     ir_function_detect_recursion.cpp \
 +     ir_function.cpp \
 +     ir_hierarchical_visitor.cpp \
 +     ir_hv_accept.cpp \
 +     ir_import_prototypes.cpp \
 +     ir_print_visitor.cpp \
 +     ir_reader.cpp \
 +     ir_rvalue_visitor.cpp \
 +     ir_set_program_inouts.cpp \
 +     ir_validate.cpp \
 +     ir_variable.cpp \
 +     ir_variable_refcount.cpp \
 +     linker.cpp \
 +     link_functions.cpp \
 +     loop_analysis.cpp \
 +     loop_controls.cpp \
 +     loop_unroll.cpp \
 +     lower_clip_distance.cpp \
 +     lower_discard.cpp \
 +     lower_if_to_cond_assign.cpp \
 +     lower_instructions.cpp \
 +     lower_jumps.cpp \
 +     lower_mat_op_to_vec.cpp \
 +     lower_noise.cpp \
 +     lower_texture_projection.cpp \
 +     lower_variable_index_to_cond_assign.cpp \
 +     lower_vec_index_to_cond_assign.cpp \
 +     lower_vec_index_to_swizzle.cpp \
 +     lower_vector.cpp \
 +     opt_algebraic.cpp \
 +     opt_constant_folding.cpp \
 +     opt_constant_propagation.cpp \
 +     opt_constant_variable.cpp \
 +     opt_copy_propagation.cpp \
 +    

Re: [Mesa-dev] [RFC PATCH] automake: add support to src/glsl/

2011-09-26 Thread Kenneth Graunke 
On 09/26/2011 08:29 AM, Eric Anholt wrote:
 I'd like to add other libs (hash table) at the src/ level, too, so a
 single helper lib that is mesa's shared, non-mtypes-using stuff but not
 things that are really Mesa like the glsl compiler would be nice.

Yeah, we really could use a src/util folder.  In particular, ralloc
really ought to live there.  hash_table and symbol_table too.

Right now, hash_table and symbol_table live in mesa/program/, but are
used in glsl/, so you want to build mesa/ before you can build glsl/,
but you have to build glsl/ before you can build mesa/...oops.  Moving
the common, non-mtypes stuff out into a convenience library would
probably make that cleaner/simpler.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC PATCH] automake: add support to src/glsl/

2011-09-26 Thread Eric Anholt 
On Mon, 26 Sep 2011 11:38:10 -0400, Matt Turner matts...@gmail.com wrote:
 On Mon, Sep 26, 2011 at 11:29 AM, Eric Anholt e...@anholt.net wrote:
  On Sun, 25 Sep 2011 15:36:02 -0400, Matt Turner matts...@gmail.com wrote:
  diff --git a/src/glsl/glsl_lexer.ll b/src/glsl/glsl_lexer.ll
  index cfd8926..dd7c68c 100644
  --- a/src/glsl/glsl_lexer.ll
  +++ b/src/glsl/glsl_lexer.ll
  @@ -104,8 +104,8 @@ HASH              ^{SPC}#{SPC}
 
       /* Preprocessor tokens. */
   ^[ \t]*#[ \t]*$                      ;
  -^[ \t]*#[ \t]*version                { BEGIN PP; return VERSION; }
  -^[ \t]*#[ \t]*extension              { BEGIN PP; return EXTENSION; }
  +^[ \t]*#[ \t]*version                { BEGIN PP; return GLSL_VERS; }
  +^[ \t]*#[ \t]*extension              { BEGIN PP; return GLSL_EXTENSION; }
   {HASH}line{SPCP}{INT}{SPCP}{INT}{SPC}$ {
                                   /* Eat characters until the first digit is
                                    * encountered
  diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy
  index 25d02fb..831f72a 100644
  --- a/src/glsl/glsl_parser.yy
  +++ b/src/glsl/glsl_parser.yy
  @@ -106,7 +106,7 @@
   %token INVARIANT
   %token LOWP MEDIUMP HIGHP SUPERP PRECISION
 
  -%token VERSION EXTENSION LINE COLON EOL INTERFACE OUTPUT
  +%token GLSL_VERS GLSL_EXTENSION LINE COLON EOL INTERFACE OUTPUT
   %token PRAGMA_DEBUG_ON PRAGMA_DEBUG_OFF
   %token PRAGMA_OPTIMIZE_ON PRAGMA_OPTIMIZE_OFF
   %token PRAGMA_INVARIANT_ALL
  @@ -228,7 +228,7 @@ translation_unit:
 
   version_statement:
        /* blank - no #version specified: defaults are already set */
  -     | VERSION INTCONSTANT EOL
  +     | GLSL_VERS INTCONSTANT EOL
        {
           bool supported = false;
 
  @@ -296,7 +296,7 @@ any_identifier:
        ;
 
   extension_statement:
  -     EXTENSION any_identifier COLON any_identifier EOL
  +     GLSL_EXTENSION any_identifier COLON any_identifier EOL
        {
           if (!_mesa_glsl_process_extension($2,  @2, $4,  @4, state)) {
              YYERROR;
  --
  1.7.3.4
 
 
  I'd prefer VERSION to be fully spelled out, and it's probably worth
  being in a separate commit.
 
 Yeah, will do. I feel like there's a better way to deal with this anyway.

For the other tokens with conflicts, we appended _TOK.  (INLINE_TOK,
PUBLIC_TOK), so probably just use that convention.



pgpx52nZlDLJn.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC PATCH] automake: add support to src/glsl/

2011-09-25 Thread Matt Turner 
On Sat, Sep 24, 2011 at 9:06 PM, Matt Turner matts...@gmail.com wrote:
 Signed-off-by: Matt Turner matts...@gmail.com
 ---
 The last discussion about using automake ([RFC] Convert mesa to 
 automake/libtool)
 ended without anything happening, probably because the branch wasn't ready.

 This patch is an attempt to get the ball rolling again. Without ripping out
 the entire existing build system in one swat, it attempts to gradually replace
 it directory by directory with automake.

 The patch has a few problems currently, and a few things that can possibly be
 done better:
        - Mainly, that building libmesa.a currently fails.
        - Not sure how to handle shared/static dricore options.
        - libtool defines VERSION (-DVERSION=...), which screws up the VERSION
          token in glsl_lexer.ll and glsl_parser.yy. I trivially renamed it.
        - libralloc.la can probably be combined into libglslcore.la, and not
          have to be added to every _LDADD line.
        - The rules for flex and bison can probably be eliminated by using
          YFLAGS and LFLAGS. I tried, but ylwrap gave me some error.

v2:
- hoisted ralloc up into libglcpp.la so it doesn't need to be included
anywhere else.
- set AC_PREREQ([2.60])
- removed AM_MAINTAINER_MODE
- added YACC = @BISON@ and LEX = @FLEX@ to src/glsl/Makefile.am to
ensure they're defined properly by autoconf
- added BUILT_SOURCES for the generated files

Matt
From 96c79cca0291cd06a7a0aa8c8e1d043595d77587 Mon Sep 17 00:00:00 2001
From: Matt Turner matts...@gmail.com
Date: Sun, 25 Sep 2011 15:32:29 -0400
Subject: [PATCH] automake: add support to src/glsl/

Signed-off-by: Matt Turner matts...@gmail.com
---
 configure.ac|   11 ++-
 src/glsl/Makefile   |  235 ---
 src/glsl/Makefile.am|  152 ++
 src/glsl/autogen.sh |   12 ---
 src/glsl/glsl_lexer.ll  |4 +-
 src/glsl/glsl_parser.yy |6 +-
 6 files changed, 167 insertions(+), 253 deletions(-)
 delete mode 100644 src/glsl/Makefile
 create mode 100644 src/glsl/Makefile.am
 delete mode 100755 src/glsl/autogen.sh

diff --git a/configure.ac b/configure.ac
index b2606bf..6b5d5c2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,6 +1,6 @@
 dnl Process this file with autoconf to create configure.
 
-AC_PREREQ([2.59])
+AC_PREREQ([2.60])
 
 dnl Versioning - scrape the version from configs/default
 m4_define([mesa_version],
@@ -17,6 +17,12 @@ AC_INIT([Mesa],[mesa_version],
 AC_CONFIG_AUX_DIR([bin])
 AC_CANONICAL_HOST
 
+# Initialize Automake
+AM_INIT_AUTOMAKE([foreign dist-bzip2])
+
+# Initialize libtool
+AC_PROG_LIBTOOL
+
 dnl Save user CFLAGS and CXXFLAGS so one can override the default ones
 USER_CFLAGS=$CFLAGS
 USER_CXXFLAGS=$CXXFLAGS
@@ -2010,3 +2016,6 @@ echo PYTHON2: $PYTHON2
 echo 
 echo Run '${MAKE-make}' to build Mesa
 echo 
+
+AC_CONFIG_FILES([src/glsl/Makefile])
+AC_OUTPUT
diff --git a/src/glsl/Makefile b/src/glsl/Makefile
deleted file mode 100644
index b2efb2a..000
--- a/src/glsl/Makefile
+++ /dev/null
@@ -1,235 +0,0 @@
-
-#src/glsl/pp/Makefile
-
-TOP = ../..
-
-include $(TOP)/configs/current
-
-LIBNAME = glsl
-
-LIBGLCPP_SOURCES = \
-	glcpp/glcpp-lex.c \
-	glcpp/glcpp-parse.c \
-	glcpp/pp.c
-
-GLCPP_SOURCES = \
-	$(LIBGLCPP_SOURCES) \
-	ralloc.c \
-	glcpp/glcpp.c
-
-C_SOURCES = \
-	strtod.c \
-	ralloc.c \
-	$(LIBGLCPP_SOURCES)
-
-CXX_SOURCES = \
-	ast_expr.cpp \
-	ast_function.cpp \
-	ast_to_hir.cpp \
-	ast_type.cpp \
-	glsl_lexer.cpp \
-	glsl_parser.cpp \
-	glsl_parser_extras.cpp \
-	glsl_types.cpp \
-	glsl_symbol_table.cpp \
-	hir_field_selection.cpp \
-	ir_basic_block.cpp \
-	ir_clone.cpp \
-	ir_constant_expression.cpp \
-	ir.cpp \
-	ir_expression_flattening.cpp \
-	ir_function_can_inline.cpp \
-	ir_function_detect_recursion.cpp \
-	ir_function.cpp \
-	ir_hierarchical_visitor.cpp \
-	ir_hv_accept.cpp \
-	ir_import_prototypes.cpp \
-	ir_print_visitor.cpp \
-	ir_reader.cpp \
-	ir_rvalue_visitor.cpp \
-	ir_set_program_inouts.cpp \
-	ir_validate.cpp \
-	ir_variable.cpp \
-	ir_variable_refcount.cpp \
-	linker.cpp \
-	link_functions.cpp \
-	loop_analysis.cpp \
-	loop_controls.cpp \
-	loop_unroll.cpp \
-	lower_clip_distance.cpp \
-	lower_discard.cpp \
-	lower_if_to_cond_assign.cpp \
-	lower_instructions.cpp \
-	lower_jumps.cpp \
-	lower_mat_op_to_vec.cpp \
-	lower_noise.cpp \
-	lower_texture_projection.cpp \
-	lower_variable_index_to_cond_assign.cpp \
-	lower_vec_index_to_cond_assign.cpp \
-	lower_vec_index_to_swizzle.cpp \
-	lower_vector.cpp \
-	opt_algebraic.cpp \
-	opt_constant_folding.cpp \
-	opt_constant_propagation.cpp \
-	opt_constant_variable.cpp \
-	opt_copy_propagation.cpp \
-	opt_copy_propagation_elements.cpp \
-	opt_dead_code.cpp \
-	opt_dead_code_local.cpp \
-	opt_dead_functions.cpp \
-	opt_discard_simplification.cpp \
-	opt_function_inlining.cpp \
-	opt_if_simplification.cpp \
-	opt_noop_swizzle.cpp \
-	opt_redundant_jumps.cpp \
-	opt_structure_splitting.cpp \
-

Re: [Mesa-dev] [RFC PATCH] automake: add support to src/glsl/

2011-09-25 Thread Matt Turner 
On Sun, Sep 25, 2011 at 3:06 PM, Gaetan Nadon mems...@videotron.ca wrote:
 I had a quick look, configure.ac is huge and has a big impact on Makefiles.
 I think it should be reviewed and cleaned-up to understand how it affects
 makefiles.

 Just a few examples of statements to investigate. Not that they are bad, but
 they may be needed because there was no automake and they could possibly
 conflict.

 AC_CHECK_PROGS([MAKE], [gmake make])

 AC_PATH_PROG([MKDEP], [makedepend])
     Can 'makedepend' impact the dependencies automake generates?

It doesn't look like it affects anything in src/glsl/, at least.

 AC_PATH_PROG([FLEX], [flex])
 AC_PATH_PROG([BISON], [bison])
     Some platforms have different names. The rules in the automake make file
 may not work if configure.ac does not use AC_PROG_YACC and AC_PROG_LEX
 This is the configuration in xorg:

 AC_PROG_YACC
 AC_PATH_PROG([YACC_INST], $YACC)
 if test ! -f $srcdir/gram.c; then
    if test -z $YACC_INST; then
   AC_MSG_ERROR([yacc not found - unable to compile gram.y])
    fi
 fi
 AC_PROG_LEX

Probably a good idea. Should the same thing done for $YACC be done for $LEX?

 test x$INSTALL = x$ac_install_sh  INSTALL='$(MINSTALL)'
     On some platforms, this may result in a different install program being
 used whether the makefile is from mesa or automake.

Maybe you understand the reason for that better than I do:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=bc302b2a33ceffe454bcf443daa0ac1edc118e9b

 There is a 'configuration' file. How will the automake makefiles take that
 into account.

I would think the configs/autoconf file is something we'd kill off
after the last static Makefile is gone.

 It looks like there are 'conflicts' between mesa makefiles and automake
 which is expected due to the size of the project. Some preparation work
 should be done upfront to make both system coexist and then have automake
 gradually replace mesa makefiles. This would be useful work anyway.

There's definitely some clean ups to be done, that's for sure.

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

Re: [Mesa-dev] [RFC PATCH] automake: add support to src/glsl/

2011-09-25 Thread Matt Turner 
On Sun, Sep 25, 2011 at 4:22 PM, Gaetan Nadon mems...@videotron.ca wrote:
 If you are moving towards a non-hacked automake world, the INSTALL variable
 should not be used for mesa makefiles. It all depends on the end goals and
 the motivation behind the conversion to automake which has not been
 explained yet.

Personally, being able to do out-of-tree builds is a big improvement
by switching to automake.

Dan lists a number of other benefits in his first email here:
http://lists.freedesktop.org/archives/mesa-dev/2010-May/000431.html

 There is a 'configuration' file. How will the automake makefiles take that
 into account.

 I would think the configs/autoconf file is something we'd kill off
 after the last static Makefile is gone.

 It looks like there are 'conflicts' between mesa makefiles and automake
 which is expected due to the size of the project. Some preparation work
 should be done upfront to make both system coexist and then have automake
 gradually replace mesa makefiles. This would be useful work anyway.

 There's definitely some clean ups to be done, that's for sure.

 Regarding Makefile.am: Use $(VAR) rather than @VAR@ Automake has an
 explanation for that.

 You will need AC_CONFIG_HEADERS, there will too many -D on the command line.

   -I../../include can be $(top_srcdir/include) Easy to read, easy to copy
 even across makefiles at any depth

Good, I'll make those two changes. Similarly, we have a lot of -D
flags like -DFEATURE_GL=1. I suppose they are best left in CPPFLAGS?

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