Closed ta0kira closed 4 years ago
This won't work without removing the Namespace
in category deps (in object_files
) that come from other modules, because recompiling a dep will invalidate its namespaces.
For example, non-local category deps should be changed to NoNamespace
in resolveObjectDeps
, and getObjectFileResolver
should replace NoNamespace
with the owning module's public_namespace
.
I take that back: Linking fails because compiled .cpp
sources depend on an outdated C++ namespace
. So, this isn't feasible at the moment.
Actually, it should be fine to make the public namespace deterministically based on absolute path and compiler hash.
If making the public namespace deterministic is necessary, then that obviates clearing/setting the Namespace
in object_files
.
Rather than assuming the public namespace is deterministic, the freshness check could check that the Namespace
in object_files
matches the public namespace of the dep.
Currently, if a dependency isn't out of date, but it's
compile-metadata
is newer than the module depending on it, the latter will be considered out of date. But, it should be fine if the public.0rp
sources from the dependency aren't newer than the module depending on them.Here is an example situation:
lib/file
depends onlib/util
.foo
depends onlib/file
.lib/util
and recompiles just that module withzeolite -r
.lib/util
itself isn't considered out of date, but nowlib/file
is, thereby preventing compilation offoo
.It would be helpful if the freshness check for
foo
used a simplified freshness check forlib/file
that only includes the.0rp
files, since recompilinglib/file
inincremental
mode won't be affected by implementation changes tolib/util
.So, to check a module's freshness:
.0rp
file against the modification time of the depending module'scompile-metadata
. (The freshness check of the dependency will ensure that all.0rp
files are listed in itscompile-metadata
.)