On 11/30/20 7:05 AM, Henri Verbeet wrote:
On Fri, 27 Nov 2020 at 20:01, Zebediah Figura (she/her) zfigura@codeweavers.com wrote:
On 11/27/20 7:03 AM, Henri Verbeet wrote:
On Thu, 26 Nov 2020 at 21:25, Zebediah Figura zfigura@codeweavers.com wrote:
- if (!options.output_filename && get_target_type_info(options.target_type)->is_binary
&& isatty(fileno(output)))
- if (!options.output_filename && options.target_type != VKD3D_SHADER_TARGET_NONE
&& get_target_type_info(options.target_type)->is_binary && isatty(fileno(output)))Perhaps we should test whether the source format is binary here with -E. Although it may not end up being very useful in practice, I don't think there's an inherent reason that vkd3d_shader_preprocess() couldn't be used with binary formats.
Maybe if it were something like m4, yeah, but the HLSL preprocessor is very whitespace-sensitive. Although we could introduce a custom m4-like preprocessor for other formats...
Sure, we could have different preprocessors for different formats. (Or even different preprocessors for the same format, if it came to that.) As far as vkd3d-compiler is concerned though, none of that should really matter; if "options.preprocess_only" is set, the format of the output is determined by "options.source_type".
Sorry, I managed to completely misunderstand what you were saying at first. Now this comment makes sense, and I agree, we should check the input format here instead.
[Perhaps we should also add something like vkd3d_shader_get_supported_preprocessor_types()?]
Possibly, although at least initially we could probably get away with simply returning a copy of the input for source formats that do not have an inherent associated preprocessor.
That's a good idea, actually; I hadn't thought of that. That does mean that for backwards compatibility's sake there's not a lot of point in later adding vkd3d_shader_get_supported_preprocessor_types().