GNOME Bugzilla – Bug 740948
Remove subdir-objects automake forward-compatibility warnings
Last modified: 2015-02-17 16:05:59 UTC
Created attachment 291859 [details] Warning generated by automake Hi, When building 0.2.1 on Debian Jessie with latest automake, I have some warnings about a missing subdir-objects flag that will be needed for forward-compatibility (see attached log file). The patch is very simple: ------------------------- --- a/configure.ac +++ b/configure.ac @@ -23,7 +23,7 @@ AC_CONFIG_HEADERS([config.h]) AC_CONFIG_MACRO_DIR([m4]) -AM_INIT_AUTOMAKE([-Wno-portability no-dist-gzip dist-xz]) +AM_INIT_AUTOMAKE([-Wno-portability no-dist-gzip dist-xz subdir-objects]) m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES([yes])]) AS_AM_REALLY_SILENT ------------------------- Best, Joseph
Patch looks good, I had to do the same in a library of mine (using Gom, incidentally :) ). Can you reattach a patch made with « git format-patch » ? This makes it much easier to apply it while preserving credit for your work. Also, when attaching the log file you set the MIME type to « application/octet-stream » which makes it harder to view than it should be. I can't change it myself, maybe as the reporter you can? In any case, just try to get it right for future attachments. :) (especially marking them as patches when appropriate)
Sorry for that. Adding the patch with correct MIME
Created attachment 293586 [details] [review] Removing subdir-objects automake forward-compatibility warnings result of the git format-patch
Committed after fixing the commit message and subject.
This patch causes error now: Makefile:805: gom/.deps/libgom_1_0_la-gom-adapter.Plo: No such file or directory Makefile:806: gom/.deps/libgom_1_0_la-gom-command-builder.Plo: No such file or directory Makefile:807: gom/.deps/libgom_1_0_la-gom-command.Plo: No such file or directory Makefile:808: gom/.deps/libgom_1_0_la-gom-cursor.Plo: No such file or directory Makefile:809: gom/.deps/libgom_1_0_la-gom-error.Plo: No such file or directory Makefile:810: gom/.deps/libgom_1_0_la-gom-filter.Plo: No such file or directory Makefile:811: gom/.deps/libgom_1_0_la-gom-repository.Plo: No such file or directory Makefile:812: gom/.deps/libgom_1_0_la-gom-resource-group.Plo: No such file or directory Makefile:813: gom/.deps/libgom_1_0_la-gom-resource.Plo: No such file or directory Makefile:814: tests/.deps/test_gom_adapter-test-gom-adapter.Po: No such file or directory Makefile:815: tests/.deps/test_gom_constraints-test-gom-constraints.Po: No such file or directory Makefile:816: tests/.deps/test_gom_find-test-gom-find.Po: No such file or directory Makefile:817: tests/.deps/test_gom_find_specific-test-gom-find-specific.Po: No such file or directory Makefile:818: tests/.deps/test_gom_insert-test-gom-insert.Po: No such file or directory Makefile:819: tests/.deps/test_gom_migration-test-gom-migration.Po: No such file or directory Makefile:820: tests/.deps/test_gom_repository-test-gom-repository.Po: No such file or directory Makefile:821: tests/.deps/test_gom_stress-test-gom-stress.Po: No such file or directory Makefile:822: tests/.deps/test_gom_transform-test-gom-transform.Po: No such file or directory gmake: *** No rule to make target 'tests/.deps/test_gom_transform-test-gom-transform.Po'. Stop.
commit 11fab3f99d03d2ae707657ed6833cf6182b6bd7b Author: Bastien Nocera <hadess@hadess.net> Date: Wed Jan 7 13:58:47 2015 +0100 Revert "build: Use "subdir-objects" for newer autotools" This reverts commit 03f516d729dff0a557408dcebf1945c04e0d3feb. This commit caused build failures. See https://bugzilla.gnome.org/show_bug.cgi?id=740948#c5
Should we try to fix the problem instead of just reverting it?
> Should we try to fix the problem instead of just reverting it? The original patch was fixing a harmless warning, but caused a fatal failure. Reverting it ASAP seems like the right thing to do as a first step. Sending a second patch that fixes the original warning without causing a new failure would be the second one. I have a feeling that's the reason Bastien reopened the bug when he reverted the patch: to show that the original problem still needs to be fixed. If you have a patch, of course... ;)
(In reply to comment #7) > Should we try to fix the problem instead of just reverting it? I don't have time to hunt down what the problem is. Seeing as the code before the patch compiled, I'm reverting. You can submit a new patch that doesn't fail to build...
Hum. That's weird, it worked like a charm when I tested it on the latest tagged version. Will check what's wrong. Thanks for the heads up.
Seems it was working for me because I was building using the Debian tools which build in a separate directory. Seems the issue is dure to this bug: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13928 Disabling dependency tracking fixes the build error but I'm not sure it is really acceptable. ./autogen.sh --disable-dependency-tracking I'll dig a little more to see if I can just bypass this issue from the Makefile.* files
Created attachment 297029 [details] [review] 4-patch patch series fixing this issue (2 first patches) but 2 more automake warnings
Thanks Christophe!