<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/3.32.2"> </HEAD> <BODY> On Sun, 2011-09-25 at 16:55 -0400, Matt Turner wrote: <BLOCKQUOTE TYPE=CITE> <PRE> On Sun, Sep 25, 2011 at 4:22 PM, Gaetan Nadon <<A HREF="mailto:memsize@videotron.ca">memsize@videotron.ca</A>> 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: <A HREF="http://lists.freedesktop.org/archives/mesa-dev/2010-May/000431.html">http://lists.freedesktop.org/archives/mesa-dev/2010-May/000431.html</A> </PRE> </BLOCKQUOTE> Sure, I was wondering if there were something specific to watch for in mesa. <BLOCKQUOTE TYPE=CITE> <PRE> >> 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? </PRE> </BLOCKQUOTE> Actually preprocessor directives (-I -D) go in AM_CPPFLAGS. Compiler flags go in AM_CFLAGS.<BR> 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.<BR> <BR> 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. <BLOCKQUOTE TYPE=CITE> <PRE> Thanks, Matt </PRE> </BLOCKQUOTE> <BR> </BODY> </HTML>