Bug 69874 - Automake throws a lot of "[...] option 'subdir-objects' is disabled"
Summary: Automake throws a lot of "[...] option 'subdir-objects' is disabled"
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Mesa core (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: mesa-dev
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-09-27 07:53 UTC by Kai
Modified: 2015-07-06 12:25 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Excerpt from the build log showing the warnings. (254.80 KB, text/plain)
2013-09-27 07:53 UTC, Kai
Details
hal failure to build log (16.70 KB, text/plain)
2014-01-15 04:04 UTC, David C. Rankin
Details

Description Kai 2013-09-27 07:53:25 UTC
Created attachment 86709 [details]
Excerpt from the build log showing the warnings.

Running autoreconf on Mesa's source tree results in a long list of Automake warnings about "option 'subdir-objects' is disabled" with the longer explanation
> 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.

I'm using Automake 1.14 (Debian Sid).
Comment 1 Kenneth Graunke 2013-09-27 16:28:59 UTC
Note that this is new with Automake 1.14.

I think everything /works/ with 1.14, it's just grumbly.
Comment 2 Emil Velikov 2013-09-27 17:12:26 UTC
New in 1.14:
...

  - The next major Automake version (2.0) will unconditionally activate
    the 'subdir-objects' option.  In order to smooth out the transition,
    we now give a warning (in the category 'unsupported') whenever a
    source file is present in a subdirectory but the 'subdir-object' is
    not enabled.  For example, the following usage will trigger such a
    warning:

        bin_PROGRAMS = sub/foo
        sub_foo_SOURCES = sub/main.c sub/bar.c

Long story short, we can ignore it until 2.0 is out, or unconditionally set it in configure.ac. The latter one may be preffered in order for us to test and make sure that mesa builds correctly, otherwise we'll be badly surprised as automake 2.0 comes out (think bleeding edge distros/packagers reporting a dozen of bugs)

It would require a bit of tinkering, which I'm going through as we speak.
Comment 3 Eric Anholt 2013-09-27 18:13:41 UTC
Yeah.  And subdir-objects is broken for the way we have our build set up at the moment (libdricore built from a separate directory, on the same .c files as core).  Once we megadrivers, we can revisit subdir-objects, though I seem to recall there being a problem with dependencies when moving files, as well.
Comment 4 Kai 2013-09-29 14:24:36 UTC
(In reply to comment #1)
> Note that this is new with Automake 1.14.
> 
> I think everything /works/ with 1.14, it's just grumbly.

Yes, that's correct. AFAICT everything works fine. I just thought I give you an heads-up.
Comment 5 Emil Velikov 2013-09-30 18:02:27 UTC
(In reply to comment #3)
> Yeah.  And subdir-objects is broken for the way we have our build set up at
> the moment (libdricore built from a separate directory, on the same .c files
> as core).  Once we megadrivers, we can revisit subdir-objects, though I seem
> to recall there being a problem with dependencies when moving files, as well.
>
Yes libdricore is "fun" :)

With libdricore aside I've managed to clear out the build systems a bit, and silence most of the automake warnings.

Some of it you can check out in the subdir-objects (often rebased) branch at https://github.com/evelikov/Mesa

I'm planning to revisit it once the megadriver work has landed.

P.S. Here is a list of the odd bits left
src/gallium/drivers/r300/
src/glsl/
src/mapi/
src/mapi/
src/mapi/*api/
src/mesa/
Comment 6 Shriram V 2013-10-30 16:38:54 UTC
bin_PROGRAMS = abc
abc_SOURCES  = sub/main.c sub/abc.c

When you set subdir-objects, it always creates object files in the same dir as the source file. E.g: sub/main.o, sub/abc.o

So, its working as expected, however this is BROKEN when I configure under a different directory. Eg: mkdir config1; cd config1; ../configure. I expect all *.o in a parallel hierarchy under config1, but with subdir-objects it is still creating object files alongside the source. Effectively then we can't anymore have multiple coexisting configurations.

Let me know if this has some workaround, (or if my understanding is wrong).
Comment 7 Emil Velikov 2013-10-30 18:14:15 UTC
(In reply to comment #6)
> bin_PROGRAMS = abc
> abc_SOURCES  = sub/main.c sub/abc.c
> 
> When you set subdir-objects, it always creates object files in the same dir
> as the source file. E.g: sub/main.o, sub/abc.o
> 
AFAICS slapping subdir-objects within configure.ac is not an option(at least not currently)

> So, its working as expected, however this is BROKEN when I configure under a
> different directory. Eg: mkdir config1; cd config1; ../configure. I expect
> all *.o in a parallel hierarchy under config1, but with subdir-objects it is
> still creating object files alongside the source.
Something seems to be broken in your setup. subdir-object should work with out of tree builds, and it seems to work great on my system (recent(ish) master + subdir-object branch)

$ cd mesa && mkdir automake-build && cd automake-build
$ ../autogen.sh && make
$ cd ../
$ find . -name "*.so" -or -name "*.la" -or -name "*.a" -or -name "*.o" | grep -v automake\-build | wc -l
0
$ git clean -nxd | grep -v Makefile\.in
Would remove aclocal.m4
Would remove autom4te.cache/
Would remove automake-build/
Would remove bin/*
Would remove configure
Would remove m4/*
Would remove src/gallium/auxiliary/util/*.pyc
Would remove src/mapi/glapi/gen/*.pyc
Would remove src/mesa/main/get_hash_params.pyc

With dricore gone I can revisit/update my branch and get some of the autoconf/automake spam out of the way :)
Comment 8 David C. Rankin 2014-01-15 04:02:38 UTC
Help automake 1.14.1-1 HAL Fails to Build from Source.

  It appears this may be more than a warning for hal. How do I fix this? As soon as the build starts:

configure.in:1046: the top level
automake: warning: autoconf input should be named 'configure.ac', not 'configure.in'
doc/man/Makefile.am:19: warning: '%'-style pattern rules are a GNU make extension
parallel-tests: error: required file './test-driver' not found
parallel-tests:   'automake --add-missing' can install 'test-driver'
hald/linux/addons/Makefile.am:80: warning: source file '../../logger.c' is in a subdirectory,
hald/linux/addons/Makefile.am:80: but option 'subdir-objects' is disabled
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.
hald/linux/addons/Makefile.am:80: warning: source file '../../util_helper.c' is in a subdirectory,
hald/linux/addons/Makefile.am:80: but option 'subdir-objects' is disabled
hald/linux/addons/Makefile.am:84: warning: source file '../../logger.c' is in a subdirectory,
hald/linux/addons/Makefile.am:84: but option 'subdir-objects' is disabled
hald/linux/addons/Makefile.am:84: warning: source file '../../util_helper.c' is in a subdirectory,
hald/linux/addons/Makefile.am:84: but option 'subdir-objects' is disabled
<snip>
hald/solaris/probing/Makefile.am:19: warning: source file '../../logger.c' is in a subdirectory,
hald/solaris/probing/Makefile.am:19: but option 'subdir-objects' is disabled
partutil/Makefile.am:7: warning: source file '../hald/logger.c' is in a subdirectory,
partutil/Makefile.am:7: but option 'subdir-objects' is disabled
policy/Makefile.am:27: warning: whitespace following trailing backslash
==> ERROR: A failure occurred in build().
    Aborting...

I will attach the build log as hal-makefile.err.txt
Comment 9 David C. Rankin 2014-01-15 04:04:10 UTC
Created attachment 92110 [details]
hal failure to build log

This is the build log for the automake/makefile errors building hal with automake 1.14.1-1 on Archlinux
Comment 10 Alan Coopersmith 2014-01-15 05:21:25 UTC
(In reply to comment #9)
> Created attachment 92110 [details]
> hal failure to build log
> 
> This is the build log for the automake/makefile errors building hal with
> automake 1.14.1-1 on Archlinux

Mesa has nothing to do with hal - you need to file a new bug with hal
developers about that (who will likely tell you hal was deprecated years ago).
Comment 11 David C. Rankin 2014-01-15 19:13:02 UTC
Correct. Sorry for the noise. While deprecated log ago, it is still needed for distributions packaging the trinity desktop. The actual problem was obsolete macros which autoupdate was able to handle. Thanks.
Comment 12 Kai 2015-01-25 08:46:57 UTC
Just to note the progress here: my latest build of Mesa (d2811c29da) shows this warning for only one directory. Seems like Mesa is almost there to be Automake 1.14 ready. ;-)
Comment 13 Emil Velikov 2015-07-06 12:25:56 UTC
The final piece has been resolved and subdir-object has been enabled globally as per
commit 404a90b82786080564fe32716f83ce055b9a934f
Author: Matt Turner <mattst88@gmail.com>
Date:   Wed Jun 10 16:30:56 2015 -0700

    mesa: Enable subdir-objects globally.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.