From b0e4d4047b2f8c9b2056a6f2585fd793f8ba0914 Mon Sep 17 00:00:00 2001 From: Xavier Claessens Date: Fri, 13 Apr 2018 15:21:57 -0400 Subject: Fix using object extracted from a unity build - determine_ext_objs: What matters is if extobj.target is a unity build, not if the target using those objects is a unity build. - determine_ext_objs: Return one object file per compiler, taking into account generated sources. - object_filename_from_source: No need to special-case unity build, it does the same thing in both code paths. - check_unity_compatible: For each compiler we must extract either none or all its sources, taking into account generated sources. --- mesonbuild/backend/ninjabackend.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'mesonbuild/backend/ninjabackend.py') diff --git a/mesonbuild/backend/ninjabackend.py b/mesonbuild/backend/ninjabackend.py index bc3a8ef..cbb3e5e 100644 --- a/mesonbuild/backend/ninjabackend.py +++ b/mesonbuild/backend/ninjabackend.py @@ -2203,7 +2203,7 @@ rule FORTRAN_DEP_HACK raise AssertionError('BUG: broken generated source file handling for {!r}'.format(src)) else: raise InvalidArguments('Invalid source type: {!r}'.format(src)) - obj_basename = self.object_filename_from_source(target, src, self.is_unity(target)) + obj_basename = self.object_filename_from_source(target, src) rel_obj = os.path.join(self.get_target_private_dir(target), obj_basename) dep_file = compiler.depfile_for_object(rel_obj) -- cgit v1.1