Display full path to each processed file.

[anakrish]

Displaying full path allows the user to figure out what file is being processed
in case an unintended file is being picked up from the specified search paths.
Add test for printed path.

Add tests to lock down the order in which search paths are processed.

Signed-off-by: Anand Krishnamoorthi [email protected]

[mingweishih]

Shouldn't we make this as optional (i.e., a command-line option)?

[anakrish]

Shouldn't we make this as optional (i.e., a command-line option)?

I am leaning towards not making it an option. oeedger8r always prints messages 'Generating code for Open Enclave SDK', 'Success' (in case of success). Printing the files being processed will add couple more lines to the output; but I don' think most users would care about these additional lines being printed in case of success. On the other hand, those that run into issues would find these lines useful.
What do you think?

[mingweishih]

Shouldn't we make this as optional (i.e., a command-line option)?

I am leaning towards not making it an option. oeedger8r always prints messages 'Generating code for Open Enclave SDK', 'Success' (in case of success). Printing the files being processed will add couple more lines to the output; but I don' think most users would care about these additional lines being printed in case of success. On the other hand, those that run into issues would find these lines useful.
What do you think?

For the current status, I think it's fine. I'm just thinking for the long-term, if we consider this as a compiler-like tool, I think it makes sense to make this feature as a command-line option (and we may have many more). For example, a compiler-like tool typically provides -verbose option to display the detailed log. For more complicated ones like gcc/clang, there are multiple options that allow users to get specific type the logs they're interested in (e.g., in addition to search path, we may have foreign type checks, etc).

Regardless this thought, we can merge this PR (which is super useful) and create an issue for tracking the follow-up steps. What do you think?

[mingweishih]

LGTM. Thank! Just have some non-blocking thoughts (see discussion).

[anakrish]

Shouldn't we make this as optional (i.e., a command-line option)?

I am leaning towards not making it an option. oeedger8r always prints messages 'Generating code for Open Enclave SDK', 'Success' (in case of success). Printing the files being processed will add couple more lines to the output; but I don' think most users would care about these additional lines being printed in case of success. On the other hand, those that run into issues would find these lines useful.
What do you think?

For the current status, I think it's fine. I'm just thinking for the long-term, if we consider this as a compiler-like tool, I think it makes sense to make this feature as a command-line option (and we may have many more). For example, a compiler-like tool typically provides -verbose option to display the detailed log. For more complicated ones like gcc/clang, there are multiple options that allow users to get specific type the logs they're interested in (e.g., in addition to search path, we may have foreign type checks, etc).

Regardless this thought, we can merge this PR (which is super useful) and create an issue for tracking the follow-up steps. What do you think?

Yes, long term it makes sense to add verbose option as oeedger8r evolves with more features. Currently it will just be these messages that would be governed by the option; and thus feels not fully justified.
If users do report that these 'Processing path.edl' messages are annoying, we can always introduce the -verbose option.

[anakrish]

Created issue #15