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

Gaetan Nadon memsize at videotron.ca
Sun Sep 25 13:22:24 PDT 2011


On Sun, 2011-09-25 at 15:41 -0400, Matt Turner wrote:

> On Sun, Sep 25, 2011 at 3:06 PM, Gaetan Nadon <memsize at 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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20110925/1c9d477e/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20110925/1c9d477e/attachment-0001.pgp>


More information about the mesa-dev mailing list