<!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 15:41 -0400, Matt Turner wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
On Sun, Sep 25, 2011 at 3:06 PM, Gaetan Nadon &lt;<A HREF="mailto:memsize@videotron.ca">memsize@videotron.ca</A>&gt; wrote:
&gt; I had a quick look, configure.ac is huge and has a big impact on Makefiles.
&gt; I think it should be reviewed and cleaned-up to understand how it affects
&gt; makefiles.
&gt;
&gt; Just a few examples of statements to investigate. Not that they are bad, but
&gt; they may be needed because there was no automake and they could possibly
&gt; conflict.
&gt;
&gt; AC_CHECK_PROGS([MAKE], [gmake make])
&gt;
&gt; AC_PATH_PROG([MKDEP], [makedepend])
&gt; &nbsp;&nbsp;&nbsp; Can 'makedepend' impact the dependencies automake generates?

It doesn't look like it affects anything in src/glsl/, at least.
</PRE>
</BLOCKQUOTE>
Good. I did not know, so that's why I asked :-) Thanks.
<BLOCKQUOTE TYPE=CITE>
<PRE>

&gt; AC_PATH_PROG([FLEX], [flex])
&gt; AC_PATH_PROG([BISON], [bison])
&gt; &nbsp;&nbsp;&nbsp; Some platforms have different names. The rules in the automake make file
&gt; may not work if configure.ac does not use AC_PROG_YACC and AC_PROG_LEX
&gt; This is the configuration in xorg:
&gt;
&gt; AC_PROG_YACC
&gt; AC_PATH_PROG([YACC_INST], $YACC)
&gt; if test ! -f &quot;$srcdir/gram.c&quot;; then
&gt; &nbsp;&nbsp; if test -z &quot;$YACC_INST&quot;; then
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AC_MSG_ERROR([yacc not found - unable to compile gram.y])
&gt; &nbsp;&nbsp; fi
&gt; fi
&gt; AC_PROG_LEX

Probably a good idea. Should the same thing done for $YACC be done for $LEX?
</PRE>
</BLOCKQUOTE>
Not required. Unfortunately for YACC, the macro sets the variable to &quot;yacc&quot; if it cannot find any program. So you will never know if it was found or not<BR>
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.
<BLOCKQUOTE TYPE=CITE>
<PRE>

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

Maybe you understand the reason for that better than I do:
<A HREF="http://cgit.freedesktop.org/mesa/mesa/commit/?id=bc302b2a33ceffe454bcf443daa0ac1edc118e9b">http://cgit.freedesktop.org/mesa/mesa/commit/?id=bc302b2a33ceffe454bcf443daa0ac1edc118e9b</A>
</PRE>
</BLOCKQUOTE>
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.<BR>
<BR>
What I was pointing out is that, on platforms not having /usr/bin/install,&nbsp; 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.<BR>
<BR>
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.<BR>
<BR>
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. <BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
&gt; There is a 'configuration' file. How will the automake makefiles take that
&gt; into account.

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

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

There's definitely some clean ups to be done, that's for sure.
</PRE>
</BLOCKQUOTE>
<BR>
Regarding Makefile.am: Use $(VAR) rather than @VAR@ Automake has an explanation for that.<BR>
<BR>
You will need AC_CONFIG_HEADERS, there will too many -D on the command line.<BR>
<BR>
<PRE>
        -I../../include can be $(top_srcdir/include) Easy to read, easy to copy even across makefiles at any depth
</PRE>
<BLOCKQUOTE TYPE=CITE>
<PRE>

Matt
</PRE>
</BLOCKQUOTE>
<BR>
</BODY>
</HTML>