Unfortunately the edit above takes away a lot of what I wanted to know. This particular library is only an example, I am hoping to gather advice that will be useful in a more general case.
I have a partial answer, but not a satisfactory one.
As far as I can tell, a piece of code that is already built with CMake will be built by the ros2 build system colcon build simply by placing it under the src directory of a workspace.
In order for other packages in the same workspace to depend on that library, it must generate ${PACKAGE}Config.cmake in the directory ${prefix}/share/${PROJECT}/cmake/. The link to the Kitware documentation in my question above gives an example of this, though it may require substantial modification of the existing CMakeLists.txt to get working. In order to be used as a library with the ament_target_dependencies macro, the Config.camke file needs to set at least the variables ${PROJECT}_INCLUDE_DIRS, ${PROJECT}_LIBRARY_DIRS, and ${PROJECT}_LIBRARIES. With these conditions, find_package succeeds and ament_target_dependencies creates the necessary include and link directives.
In order to enforce a build order dependency that ensures the library is built before any package that depends on it, the project name of the library must be added as a <depend> tag in the appropriate packge.xml. Unfortunately, this breaks rosdep install since now that tool attempts to find a rosdep key matching the library name, which does not exist, and probably shouldn't.
For now, I have a modified version of the EIPScanner library here with the changes to CMakeLists.txt needed to generate the Config file. The rosdep issue can be mitigated with the --skip-keys argument, though this seems difficult to maintain. The -i argument does not work since the library is not a catkin or ament package.
A better answer than this would 1) require fewer modifications to the existing library and 2) not break rosdep.
I've updated the title to better reflect your specific question @contradict.
"dependency management" is a bit broader than configuring your package to state a dependency on a specific library or other package.
And a comment on this:
please don't "package external libraries for ROS".
There is rarely a need, and it just makes maintenance harder.
Treat such libraries as all your other programs treat them: part of the OS, and discovered by something like CMake.
There isn't really anything ROS specific in how that's done.
I still believe your title and question are too broad, and this has also been discussed before, but if you feel it's better to revert to the older title: I've reverted to it.