Prevents this automake warning about possible forward-incompatibility: $ ./autogen.sh ... cpp/tests/Makefile.am:16: warning: source file '$(top_srcdir)/utils/parseargs.cc' is in a subdirectory, cpp/tests/Makefile.am:16: 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. cpp/tests/Makefile.am:20: warning: source file '$(top_srcdir)/utils/parseargs.cc' is in a subdirectory, cpp/tests/Makefile.am:20: but option 'subdir-objects' is disabled parallel-tests: installing './test-driver' test/Makefile.am:58: warning: source file '../utils/parseargs.cc' is in a subdirectory, test/Makefile.am:58: but option 'subdir-objects' is disabled $ automake --version automake (GNU automake) 1.14.1 ...
Created attachment 106248 [details] [review] Refactor Makefiles to build a noinst library for parsing args
Just enable subdir-objects ? It seems easier than the whole change, no?
(In reply to comment #2) > Just enable subdir-objects ? It seems easier than the whole change, no? The reason automake will change its behaviour in the future is that its developers prefer a 'no subdir-objects' mode of operation. It will be the default. The 'subdir-objects' mode gives the 'old' (=current) behaviour. I am inclined to think the automake developers have good reasons to change automake's behaviour. When it is easy for an existing project like poppler to adopt to the new default behaviour, I think it should choose to do so, instead of working around it by using an option to enable old behaviour. For me it is a lot like the situation with '--enable-xpdf-headers': there might be good reasons to use that option, but I would strongly prefer it if people didn't.
Ok
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.