[cairo] [PATCH 2/4] configure.ac: Explicitly enable subject-objects for automake 1.11
Bryce W. Harrington
b.harrington at samsung.com
Thu Jul 10 00:02:07 PDT 2014
On Wed, Jul 09, 2014 at 11:22:08AM +0200, Uli Schlachter wrote:
> On 09.07.2014 03:13, Bryce W. Harrington wrote:
> > This fixes this build issue on Ubuntu 14.04 with gcc 4.8:
> > perf/Makefile.sources:7: warning: source file '../src/cairo-time.c' is in a subdirectory,
> > perf/Makefile.sources:7: but option 'subdir-objects' is disabled
> > perf/Makefile.am:3: 'perf/Makefile.sources' included from here
> > automake: warning: possible forward-incompatibility.
> > automake: At least a source file is in a subdirectory, but the 'subdir-objects'
> > automake: automake option hasn't been enabled. For now, the corresponding output
> > automake: object file(s) will be placed in the top-level directory. However,
> > automake: this behaviour will change in future Automake versions: they will
> > automake: unconditionally cause object files to be placed in the same subdirectory
> > automake: of the corresponding sources.
> > automake: You are advised to start using 'subdir-objects' option throughout your
> > automake: project, to avoid future incompatibilities.
> So far, that's just a warning.
It's just a warning, but it spews a good 300 lines of warning text into
the build log.
(I'm noticing a lot of misc. new warnings building with gcc 4.8,
particularly with --enable-qt as g++ seems fussier about things. But
I've only given attention to a couple of the really noisy warnings so
A number of other projects have encountered this; here's a bug
against mesa that got some good debate:
And a stackoverflow discussion about it:
Apparently subdir-objects will be switched on by default in automate
2.0. They're issuing the warnings to help projects prepare for the
transition. IOW if we hit problems when we enable this option, then we
need to get them sorted before automake 2.0 hits.
> However, I wonder if we really want this. Doesn't
> this mean that both src/Makefile and perf/Makefile will try to create
> src/cairo-time.lo (and the corresponding files in src/.libs/) and isn't it, in
> theory, possible that one of them overwrites the files while the other is trying
> to read it?
> I guess that this is only a theoretical issue since perf/ depends on src/ in the
> top-level Makefile (right?).
$ find . -name cairo-time.lo
$ find . -name cairo-time.lo
So yeah, looks like you're right. I'll withdraw this patch.
> > Signed-off-by: Bryce Harrington <b.harrington at samsung.com>
> > ---
> > configure.ac | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> > diff --git a/configure.ac b/configure.ac
> > index 66a8558..fca6fc5 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -13,7 +13,7 @@ AC_CONFIG_HEADERS(config.h)
> > AC_CHECK_HEADERS([unistd.h sys/ioctl.h])
> > -AM_INIT_AUTOMAKE([1.11 foreign -Wall no-define no-dist-gzip dist-xz])
> > +AM_INIT_AUTOMAKE([1.11 foreign -Wall no-define no-dist-gzip dist-xz subdir-objects])
> > AM_SILENT_RULES([yes])
> > m4_ifdef([AM_PROG_AR], [AM_PROG_AR]) dnl Workaround for Automake 1.11
> "Why make things difficult, when it is possible to make them cryptic
> and totally illogical, with just a little bit more effort?" -- A. P. J.
> cairo mailing list
> cairo at cairographics.org
More information about the cairo