[PATCH 5/9] Introduce selftest::locate_file (v4)
David Malcolm
dmalcolm@redhat.com
Thu Dec 8 21:47:00 GMT 2016
On Thu, 2016-12-01 at 14:29 +0100, Bernd Schmidt wrote:
> On 11/11/2016 10:15 PM, David Malcolm wrote:
> > + /* Makefile.in has -fself-test=$(srcdir)/testsuite/selftests, so
> > that
> > + flag_self_test contains the path to the selftest subdirectory
> > of the
> > + source tree (without a trailing slash). Copy it up to
> > + path_to_selftest_files, to avoid selftest.c depending on
> > + option-handling. */
> > + path_to_selftest_files = flag_self_test;
> > +
>
> What kind of dependency are you avoiding? If it's just one include
> I'd
> prefer to get rid of the extraneous variable.
>
> Otherwise ok.
I attempted to eliminate the global, and include "options.h" from
selftest.c, and to use flag_self_test directly (implicitly accessing
the global_options global).
The *code* changes were relatively simple, with only one extra
#include.
However, from a linker perspective, it's more awkward. selftest.o is
used by (amongst other things) OBJS-libcommon: libcommon.a currently
has selftest.o, but doesn't have options.o. Various things in
libcommon.a use selftest.o for selftests and thus libcommon.a needs
selftest.o.
Hence doing so brings in a dependency on the option-handling objects
into libcommon.a, which seems wrong to me.
It seems simplest to go with either:
(A) the approach in the patch, with an extra global, keeping the
selftest code independent from gcc's option-handling code (both at
compile time and link time) or
(B) add the path as an extra param, passing it in at all callsites,
so that every
locate_file (some_path)
in the kit becomes
locate_file (flag_self_test, some_path)
Is (A) OK, or would you prefer (B)? (I prefer (A) fwiw)
Thanks
Dave
More information about the Gcc-patches
mailing list