Prevents this automake warning about possible forward-incompatibility:
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.