Forgive me if this has already been discussed.
I work on projects with different formatting guidelines. For simple cases, it is simple to embed the .clang-format file in the correct (parent) directory, run `clang-format -style=file ...` and everyone's happy. However, it is easy to get into a situation where the wrong format is applied, especially if you accidentally invoke the command from the wrong directory.
Would Clang be opposed to a specification like:
clang-format -style=custom:my-projects-format ...
where a field in the .clang-format file would have the value 'my-projects-format', thus attributing the file to the format name? If a user specified something like -style=custom:my-unsupported-format, and such a format name could not be discovered in the .clang-format file, then it would be a hard failure, not letting a silent error slip by.
Thanks for your input. If it is favorable, then I'm happy to explore implementing it.
Kyle Knoepfel
Software framework group leader, Fermilab
Forgive me if this has already been discussed.
I work on projects with different formatting guidelines. For simple cases, it is simple to embed the .clang-format file in the correct (parent) directory, run `clang-format -style=file ...` and everyone's happy. However, it is easy to get into a situation where the wrong format is applied, especially if you accidentally invoke the command from the wrong directory.
Would Clang be opposed to a command line invocation such as:
clang-format -style=custom:my-projects-format ...
where a field in the .clang-format file would have the value 'my-projects-format', thus attributing the file to the format name? If a user specified something like -style=custom:my-unsupported-format, and such a format name could not be discovered in the .clang-format file, then it would be a hard failure, not letting a silent error slip by.
Thanks for your input. If it is favorable, then I'm happy to explore implementing it.
Kyle Knoepfel
Software framework group leader, Fermilab
"clang-format for each input file will try to find the .clang-format
file located in the closest parent directory of the input file." - so
it shouldn't matter which directory you invoke the command from. If
you have the .clang-format file in the parent of the file you want to
format, it should always get that format.
Perhaps there's something broken in your setup that's causing that
behavior not to work?
David, the current situation I'm faced with is that we're experimenting with different formats, and there is no .clang-format file that resides in the directory hierarchy. Once we settle on a format, I expect the .clang-format to be included in the source-code repository, and this problem can be a non-issue. Until we get there, however, this would be a very helpful safety mechanism.
That said, I'm very cognizant of the XY problem, and do not want to be a perpetrator of it.
Thanks for your response,
Kyle
I've cc'd Sam McCall who might have opinions on the specific feature
you're suggesting. In the mean time I'd like to/be happy to drill down
a bit more into your use case, perhaps there are other solutions or
it'll give Sam more context when he can reply
David, the current situation I'm faced with is that we're experimenting with different formats, and there is no .clang-format file that resides in the directory hierarchy.
What sort of experiments are you running? If it's a matter of using
different formats in different parts of the codebase, that could be
done with more narrowly scoped .clang-format files, for instance. If
the project isn't open to having any .clang-format files checked in
during the experimentation phase, that's trickier - could put one
up/above/outside the project - but couldn't do that and have different
sub directories running different experimental formats.
David, see my response below.
I've cc'd Sam McCall who might have opinions on the specific feature
you're suggesting. In the mean time I'd like to/be happy to drill down
a bit more into your use case, perhaps there are other solutions or
it'll give Sam more context when he can reply
David, the current situation I'm faced with is that we're experimenting with different formats, and there is no .clang-format file that resides in the directory hierarchy.
What sort of experiments are you running? If it's a matter of using
different formats in different parts of the codebase, that could be
done with more narrowly scoped .clang-format files, for instance. If
the project isn't open to having any .clang-format files checked in
during the experimentation phase, that's trickier - could put one
up/above/outside the project - but couldn't do that and have different
sub directories running different experimental formats
Yes, that is what I've settled on--placing the .clang-format file outside of the source-code tree, and doing something like:
sourcecode/...
option-a/.clang-format
option-b/.clang-format
option-c/.clang-format
Somebody then asked me to send them the 'option-c' format so they could run it on their code base. Unfortunately, he placed the '.clang-format' file in the wrong place, ran clang-format, and received an output they thought was 'option-c' but really wasn't. If instead he could have run something like:
clang-format -style=custom:option-c ...
then a hard failure stating "option-c format not found" (or something similar) would have been helpful.
Thanks,
Kyle
David, see my response below.
>
> I've cc'd Sam McCall who might have opinions on the specific feature
> you're suggesting. In the mean time I'd like to/be happy to drill down
> a bit more into your use case, perhaps there are other solutions or
> it'll give Sam more context when he can reply
>
>>
>> David, the current situation I'm faced with is that we're experimenting with different formats, and there is no .clang-format file that resides in the directory hierarchy.
>
> What sort of experiments are you running? If it's a matter of using
> different formats in different parts of the codebase, that could be
> done with more narrowly scoped .clang-format files, for instance. If
> the project isn't open to having any .clang-format files checked in
> during the experimentation phase, that's trickier - could put one
> up/above/outside the project - but couldn't do that and have different
> sub directories running different experimental formats
Yes, that is what I've settled on--placing the .clang-format file outside of the source-code tree, and doing something like:
sourcecode/...
option-a/.clang-format
option-b/.clang-format
option-c/.clang-format
Somebody then asked me to send them the 'option-c' format so they could run it on their code base. Unfortunately, he placed the '.clang-format' file in the wrong place, ran clang-format, and received an output they thought was 'option-c' but really wasn't. If instead he could have run something like:
clang-format -style=custom:option-c ...
then a hard failure stating "option-c format not found" (or something similar) would have been helpful.
In this case, even a "no .clang_format file found" message would've
been adequate, yes? Or did they have some other .clang_format file?
Perhaps in verbose mode clang-format could print which .clang_format
file it used?
Yes, that is what I’ve settled on–placing the .clang-format file outside of the source-code tree, and doing something like:
sourcecode/…
option-a/.clang-format
option-b/.clang-format
option-c/.clang-format
Somebody then asked me to send them the ‘option-c’ format so they could run it on their code base. Unfortunately, he placed the ‘.clang-format’ file in the wrong place, ran clang-format, and received an output they thought was ‘option-c’ but really wasn’t. If instead he could have run something like:
clang-format -style=custom:option-c …
then a hard failure stating “option-c format not found” (or something similar) would have been helpful.
In this case, even a “no .clang_format file found” message would’ve
been adequate, yes? Or did they have some other .clang_format file?
Perhaps in verbose mode clang-format could print which .clang_format
file it used?
I am not certain what his particular failure mode was, but providing an error message a la your proposal and/or a verbose mode that prints the path of the .clang-format file would be quite welcome and would meet the need.
Kyle
Hi Kyle,
A similar feature has been proposed: allowing -style to refer to a filename. Could be style=file: which is pretty close…
I guess it’s a little clumsier for the user (and a little less work for the style authors) than what you propose. But it’s simple, which is worth something - I don’t like the idea of adding things to the format file itself to facilitate this.
And it would satisfy your goal around error-reporting: -style=foobar fails with “Invalid value for -style” and a nonexistent file could do the same.
The patch https://reviews.llvm.org/D50147 got stalled over whether the files should be searched for relative to some predefined search path. I think a version that handled absolute or working-dir-relative paths would be uncontroversial. Would this work for you?
cc Typz who wrote that patch and Mydeveloperday who is the most active clang-format maintainer.
Cheers, Sam
Sam thanks for the response. Yes, a version of Typz’s patch with only absolute- and relative-path support is uncontroversial (from my POV) and it would address the complications I have encountered. Please let me know if there may be a way I could contribute to the progress of the patch…not that I would have the time to work on it. 
Best,
Kyle