Enable custom uncrustify configuration with ament_lint_auto

[ralph-lange]

Problem

I failed to use a custom configuration for uncrustify when using it from ament_lint_auto:

• There seems to be no possibility to pass a custom configuration file directly via an argument to ament_lint_auto.
• Disabling uncrustify from ament_lint_auto by set(ament_cmake_uncrustify_FOUND TRUE) works as usual ,but when invoking ament_uncrustify explicitly (with our without a different test-name), it is actually invoked two times, once with the custom configuration and once with the default configuration.

I tried various modifications of the following snippet. All either ended up in uncrustify being not invoked at all or being invoked two times, as just described:

if(BUILD_TESTING)
  find_package(ament_cmake_uncrustify REQUIRED)
  ament_uncrustify(CONFIG_FILE "./code_style.cfg" TESTNAME "custom_uncrustify")

  find_package(ament_lint_auto REQUIRED)
  set(ament_cmake_uncrustify_FOUND TRUE)
  ament_lint_auto_find_test_dependencies()
endif()

Desired behavior

Uncrustify should be invoked only once.

• Either provide a possibility to pass the path to the custom configuration file via an environment variable
• or even auto-discover the presence of a custom configuration file in the root of the repo or package.

[audrow]

Hi @ralph-lange, thanks for the issue. If you'd like to open a PR for this issue, feel free to ask me any questions or @ me for a review.

[RFRIEDM-Trimble]

I want a similar behavior to turn off settings in cpplint that my project doesn't follow. I am happy to help for this, but could use a recommendation on what the desired behavior is. Since ament_lint_auto removes the need to call the linters directly, I don't see where you would pass in the filepath to a config file.

I don't see how auto discovery would scale considering there might be config files for every single linter, unless you want to assume certain filenames/extensions and they just happen to be unique.

Here's my proposal: Say you have a project structure like this, where you have a project level config file ament_lint.cfg, and then lower level configs named the same, just in different directories.

my_package
  package.xml
  CMakeLists.txt
  ament_lint.cfg
  include
    my_file.hpp
  src
    ament_lint.cfg
    my_file.cpp

When invoking ament_lint, it could find the nearest config file in either the directory of the file, or any parent. The first one found is what is used, with a limit of hitting the package.xml file directory.

The requirement is they are all named the same thing, and you require the same standards at a directory level. This scales with other linters because each linter has its own name. Finally, it accomplishes my goal of allowing relaxed standards for private scope files. Sure, make sure my headers follow the strictest code, but in some private source directory where I copied some subproject's utility in, I don't want to enforce google style on it because they used something else.