Date: Mon, 27 Nov 2023 13:37:36 +0200
Chuanqi Xu via SG15 <sg15_at_[hidden]> writes:
> Feedbacks or concerns are highly appreciated.
My understanding is that the first approach essentially creates distinct
sets of prerequisites for the BMI and for the object file, even though
they are produced with the same compiler invocation. I think this will
be a pretty hard thing to handle for most build systems, including build2,
where we model the BMI+OBJ pair as a target group with a single set of
prerequisites.
While the second approach feels like it will be easier to support, it is
still quite a bit of housekeeping (and a separate process invocation just
for an up-to-date check). But an interesting idea, nevertheless. I think
if this is merged into Clang and doesn't require a separate tool for
querying (clang-named-modules-querier), I can try to support it in build2.
I also wonder whether you have considered a third approach, which is to
provide a hash of the module interface. Essentially:
clang-named-modules-querier a.pcm --all | sha256sum
This approach should be pretty easy to handle for build systems that
don't hard-code mtime-based out-of-date checking semantics. Quite a few
build systems these days also (or instead) support content hashing as
a more accurate (but more expensive) mechanism. For such build systems
supporting this approach should be pretty painless: instead of calling
sha256sum to get the hash, simply call the compiler (or another special
tool) to get the interface hash.
I think the only catch here is that the compiler (or the special tool)
must make sure the hash tracks the relevant changes accurately. In
particular, I believe that if any exported declaration's location changes,
the hash must change as well (since it may affect the diagnostics the user
sees). I think this may make the whole idea a lot less appealing, at least
for certain use-case. Using the example from your paper:
export module a;
export int a() {
return 43;
}
namespace nn {
export int a(int x, int y) {
return x + y;
}
}
If I change the implementation of a() by adding another line:
export int a() {
// TODO
return 43;
}
The hash will have to change because the exported a(int,int) is now
declared on a different line.
> Feedbacks or concerns are highly appreciated.
My understanding is that the first approach essentially creates distinct
sets of prerequisites for the BMI and for the object file, even though
they are produced with the same compiler invocation. I think this will
be a pretty hard thing to handle for most build systems, including build2,
where we model the BMI+OBJ pair as a target group with a single set of
prerequisites.
While the second approach feels like it will be easier to support, it is
still quite a bit of housekeeping (and a separate process invocation just
for an up-to-date check). But an interesting idea, nevertheless. I think
if this is merged into Clang and doesn't require a separate tool for
querying (clang-named-modules-querier), I can try to support it in build2.
I also wonder whether you have considered a third approach, which is to
provide a hash of the module interface. Essentially:
clang-named-modules-querier a.pcm --all | sha256sum
This approach should be pretty easy to handle for build systems that
don't hard-code mtime-based out-of-date checking semantics. Quite a few
build systems these days also (or instead) support content hashing as
a more accurate (but more expensive) mechanism. For such build systems
supporting this approach should be pretty painless: instead of calling
sha256sum to get the hash, simply call the compiler (or another special
tool) to get the interface hash.
I think the only catch here is that the compiler (or the special tool)
must make sure the hash tracks the relevant changes accurately. In
particular, I believe that if any exported declaration's location changes,
the hash must change as well (since it may affect the diagnostics the user
sees). I think this may make the whole idea a lot less appealing, at least
for certain use-case. Using the example from your paper:
export module a;
export int a() {
return 43;
}
namespace nn {
export int a(int x, int y) {
return x + y;
}
}
If I change the implementation of a() by adding another line:
export int a() {
// TODO
return 43;
}
The hash will have to change because the exported a(int,int) is now
declared on a different line.
Received on 2023-11-27 11:37:35