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
