Thanks @Mousius I am not suggesting a decision on solutions, but just want to broadly discuss the implication, of the engineering solutions. For example, to build on what you said
> Which leads me to believe we should default to a `Config` level tag which is > the highest level available? If we add in-between layers then this still > holds? For the same reason I wouldn’t want to use `Target` to define > everything, I can see the error in trying to explain a `Target` tag and a > `Config` tag and leading to confusion as to what a tag is - which I think > we’re agreeing on This would results in two UX concepts. A target tag and config tag, and in the case of system implementations, possible two similar impls. > This RFC doesn’t aim to address how you use the configuration so much as > define the fact the configuration will be there for you to use and rely on I understand the original intention was to scope it as "top-level config". However, because config itself is a data structure(just like target) that involves "constraint settings throughout compilation", we naturally would to ask the following questions: - Does the top-level config have to remain as in its most general form, e.g. can it be a `Union[Target,MultiTarget]`, as the most common case remains to be TargetWithHost - We might have need to propagate some of the multi-target constraint info in the future to function level, at that time point, which data structure to use(if there is both config and target). - The consistency of single device function's target attr and multi-device function's config attr. > Are you suggesting something as simple as `configuration.to_json()` or > `configuration.serialize_targets()` which would return the array of JSON > represented `Target` ? Re-using the already defined schema for `Target` and > providing some way to extract it seems to function here? Right, this would result in two concepts, target and config. Both of which are really similar to each other and both can appear in the same automation logs. We might need to build two set of mechanisms for both if they end up as drastically different data structure without a common base. --- [Visit Topic](https://discuss.tvm.apache.org/t/pre-rfc-compilation-configuration-representation/11372/29) to respond. You are receiving this because you enabled mailing list mode. To unsubscribe from these emails, [click here](https://discuss.tvm.apache.org/email/unsubscribe/2ef6b123c86621f3fc20ad5de5704f36ea46ace576f121f46fadd8a94c532ed8).
