ament / ament_index

See https://github.com/ament/ament_cmake/blob/master/ament_cmake_core/doc/resource_index.md for documentation on the ament resource index.

See https://github.com/ament/ament_cmake/tree/master/ament_cmake_core/cmake/index for the corresponding CMake implementation of the resource index.

ament_index's Issues

Windows with `--symlink-install` picking up package resource folders as Python packages.

Expected Behavior

The resource marker files in ament_python packages do not interfere with other Python tools.

Actual Behavior

On Windows, if I use colcon build --merge-install --symlink-install to build a workspace with ament_python packages and source the workspace's setup.bat, the package's resource folder is picked up as an importable Python package.

This causes errors in other packages.

(humble) c:\Code\dbgdump\test_ws>python -c "import resource; print(resource.__spec__)"
ModuleSpec(name='resource', loader=<_frozen_importlib_external._NamespaceLoader object at 0x0000020E1B72EC10>, submodule_search_locations=_NamespacePath(['c:\\Code\\dbgdump\\test_ws\\build\\test_pkg\\resource']))

Note that the imported module is in the workspace's build folder:

c:\\Code\\dbgdump\\test_ws\\build\\test_pkg\\resource

The resource package is supposed to be a Unix-specific Python package that I guess is in the standard library.

Several other Python packages test only for an ImportError for the resource package as a test for non-Unix systems. For example:

• https://github.com/jupyter/notebook/blob/v6.4.11/notebook/notebookapp.py#L35
• https://github.com/prometheus/client_python/blob/master/prometheus_client/process_collector.py#L7

However, if there is an importable resource package that isn't https://docs.python.org/3/library/resource.html, it raises an AttributeError instead.

I first encountered this issue because Jupyter notebooks seem to use the resource module, which means I can't properly install and use Jupyter notebooks in a fully-sourced ROS2 environment on Windows ROS2.

See jupyter/notebook#5817 (comment) for earlier details.

Detailed Reproduction

I did a step-by-step reproduction in an otherwise empty workspace below.

The problematic outcome is annotated with ❌... the errors annotated with ✅ represent expected behavior on Windows.

It's specifically the use of --symlink-install that triggers the behavior.

(humble) c:\Code\dbgdump\test_ws>cd src
(humble) c:\Code\dbgdump\test_ws\src>ros2 pkg create test_pkg --build-type ament_python
(humble) c:\Code\dbgdump\test_ws\src>tree /f
Folder PATH listing for volume Windows-SSD
Volume serial number is BC74-9D52
C:.
└───test_pkg
    │   package.xml
    │   setup.cfg
    │   setup.py
    │
    ├───resource
    │       test_pkg
    │
    ├───test
    │       test_copyright.py
    │       test_flake8.py
    │       test_pep257.py
    │
    └───test_pkg
            __init__.py
            
(humble) c:\Code\dbgdump\test_ws\src>cd ..
(humble) c:\Code\dbgdump\test_ws>colcon build --merge-install --symlink-install

# Before we source the workspace, we get a ModuleNotFoundError, which is fine
# This is considered a sign that we're on Windows for other packages looking for the resource module
# like https://github.com/prometheus/client_python
(humble) c:\Code\dbgdump\test_ws>python -c "import resource"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ModuleNotFoundError: No module named 'resource' ✅ 

# however, when we source the workspace, we have an issue 

(humble) c:\Code\dbgdump\test_ws>install\setup.bat
(humble) c:\Code\dbgdump\test_ws>python -c "import resource"

# nothing happens here, because it exists! What is it? The resource folder from test_pkg
(humble) c:\Code\dbgdump\test_ws>python -c "import resource; print(resource.__path__)"
_NamespacePath(['c:\\Code\\dbgdump\\test_ws\\build\\test_pkg\\resource']) 

# Packages that test for ImportError as a platform selector will now fail.
# We get an AttributeError if we use methods that exist in the Unix resource module
(humble) c:\Code\dbgdump\test_ws>python -c "import resource; print(resource.getpagesize())"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
AttributeError: module 'resource' has no attribute 'getpagesize' ❌ 

# We're fine if we just use colcon build
(humble) c:\Code\dbgdump\test_ws>rd /s /q build install log
(humble) c:\Code\dbgdump\test_ws>colcon build 
(humble) c:\Code\dbgdump\test_ws>install\setup.bat
(humble) c:\Code\dbgdump\test_ws>python -c "import resource; print(resource.getpagesize())"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ModuleNotFoundError: No module named 'resource' ✅ 

# It seems like colcon build --merge-install is fine as well
(humble) c:\Code\dbgdump\test_ws>rd /s /q build install log
(humble) c:\Code\dbgdump\test_ws>colcon build --merge-install
(humble) c:\Code\dbgdump\test_ws>install\setup.bat
(humble) c:\Code\dbgdump\test_ws>python -c "import resource; print(resource.getpagesize())"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ModuleNotFoundError: No module named 'resource' ✅ 

Machine Info

I have ROS2 installed via Robostack

Edition	Windows 11 Home
Version	22H2
Installed on	‎5/‎12/‎2022
OS build	22622.601

Python 3.9.13 | packaged by conda-forge | (main, May 27 2022, 16:50:36) [MSC v.1929 64 bit (AMD64)] on win32

(humble) c:\Code\dbgdump\test_ws>mamba list | findstr ament-index
ros-humble-ament-index-cpp 1.4.0            py39he8739fe_1    robostack-humble
ros-humble-ament-index-python 1.4.0            py39h4c0ac80_1    robostack-humble

I'm considering some upstream PRs to fix the tests in the affected packages too, but since resource is a standard library package, it seems pretty valid to presume that no one would shadow its name in Windows unless their intent was to provide the same API for a special case.

I have not reproduced this on all my Windows machines, so I'll report back if I find that this is something peculiar about this machine and ROS2 installation.

Any advice for workarounds is appreciated. For now I'm just going to locally hack the offending Python libraries to test for AttributeError as well.

Problem with compiling ament_index_cpp with x64 architecture

Hi everyone!, thanks a lot for this amazing project!

I have an Issue while compiling this package for ros2 foxy with colcon, where the following error appears:

 C:\ws_new\ros_msft_mrtk_native\tools\src\ament\ament_index\ament_index_cpp\src\get_resources.cpp(74,67): error C2664: 'HANDLE FindFirstFileW(LPCWSTR,LPWIN32_FIND_DATAW)': cannot convert argument 1 from 'const _Elem *' to 'LPCWSTR' [C:\ws_new\ros_msft_mrtk_native\tools\x64_build\ament_index_cpp\ament_index_cpp.vcxproj]
          with
          [
              _Elem=char
          ]
C:\ws_new\ros_msft_mrtk_native\tools\src\ament\ament_index\ament_index_cpp\src\get_resources.cpp(89,10): message : Reason: cannot convert from 'WCHAR [260]' to 'const std::basic_string<char,std::char_traits<char>,std::allocator<char>>' [C:\ws_new\ros_msft_mrtk_native\tools\x64_build\ament_index_cpp\ament_index_cpp.vcxproj]
C:\ws_new\ros_msft_mrtk_native\tools\src\ament\ament_index\ament_index_cpp\src\get_resources.cpp(89,10): message : No constructor could take the source type, or constructor overload resolution was ambiguous [C:\ws_new\ros_msft_mrtk_native\tools\x64_build\ament_index_cpp\ament_index_cpp.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\xtree(1370,25): message : see declaration of 'std::_Tree<std::_Tmap_traits<_Kty,_Ty,_Pr,_Alloc,false>>::find' [C:\ws_new\ros_msft_mrtk_native\tools\x64_build\ament_index_cpp\ament_index_cpp.vcxproj]

By looking into the get_resources.cpp file, I found that the following code is executed when a different architecture than win32 is used:

#else
    std::string pattern = path + "/*";
    WIN32_FIND_DATA find_data;
    HANDLE find_handle = FindFirstFile(pattern.c_str(), &find_data);
    if (find_handle == INVALID_HANDLE_VALUE) {
      continue;
    }
    do {
      // ignore directories
      if ((find_data.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY)) {
        continue;
      }

      // ignore files starting with a dot
      if (find_data.cFileName[0] == '.') {
        continue;
      }

      if (resources.find(find_data.cFileName) == resources.end()) {
        resources[find_data.cFileName] = base_path;
      }
    } while (FindNextFile(find_handle, &find_data));
    FindClose(find_handle);
#endif
  }
  return resources;
}

As the errors says, the problem is that the compiler can't convert the string from char to wchar. By looking some related issues, I added this additional functions to the main file:

std::wstring s2ws(const std::string& str)
{
    using convert_typeX = std::codecvt_utf8<wchar_t>;
    std::wstring_convert<convert_typeX, wchar_t> converterX;

    return converterX.from_bytes(str);
}

std::string ws2s(const std::wstring& wstr)
{
    using convert_typeX = std::codecvt_utf8<wchar_t>;
    std::wstring_convert<convert_typeX, wchar_t> converterX;

    return converterX.to_bytes(wstr);
}

and then, I developed the required conversions to make the compilation works:

#else

    std::string pattern = path + "/*";

    //---> Patch added
    std::wstring wpattern = s2ws(pattern);
    
    WIN32_FIND_DATA find_data;
    HANDLE find_handle = FindFirstFile(wpattern.c_str(), &find_data);
    if (find_handle == INVALID_HANDLE_VALUE) {
      continue;
    }
    do {
      // ignore directories
      if ((find_data.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY)) {
        continue;
      }

      // ignore files starting with a dot
      if (find_data.cFileName[0] == '.') {
        continue;
      }

      //---> Patch added
      if (resources.find(ws2s(find_data.cFileName)) == resources.end())
      {
          resources[ws2s(find_data.cFileName)] = base_path;
      }
       
    } while (FindNextFile(find_handle, &find_data));
    FindClose(find_handle);
#endif
  }
  return resources;
}

In order to skip de error. Nevertheless, despite the package can compile with no problems I am getting an execution error when I create a ros2 node instance. I am not sure if this error is caused by the previous modification, or if I am making a mistake when I try to compile the package. I have a Windows 10 machine with a /x64 architecture, and Visual Studio Community 2019.

Thanks in advance for your response!

Python get_resource will always succeed when resource_name is an absolute path

Python implementation of get_resource function will always succeed, when passing absolute path to file via resource_name argument. It returns content of the file, and first searched path.

ament_index/ament_index_python/ament_index_python/resources.py

Lines 22 to 49 in a563104

	def get_resource(resource_type, resource_name):
	"""
	Get the content of a specific resource and its prefix path.
	:param resource_type: the type of the resource
	:type resource_type: str
	:param resource_names: the name of the resource
	:type resource_name: str
	:returns: a tuple of the content (bytes) of the resource and its prefix path
	:raises: :exc:`EnvironmentError`
	:raises: :exc:`OSError`
	:raises: :exc:`LookupError`
	"""
	assert resource_type, 'The resource type must not be empty'
	assert resource_name, 'The resource name must not be empty'
	for path in get_search_paths():
	resource_path = os.path.join(path, RESOURCE_INDEX_SUBFOLDER, resource_type, resource_name)
	if os.path.isfile(resource_path):
	try:
	with open(resource_path, 'r') as h:
	content = h.read()
	except OSError as e:
	raise OSError(
	"Could not open the resource '%s' of type '%s':\n%s"
	% (resource_name, resource_type, e))
	return content, path
	raise LookupError(
	"Could not find the resource '%s' of type '%s'" % (resource_name, resource_type))

Issue is in line 38, join operation with last absolute path as last argument will return this last argument.

From my point of view in case of such input, code should throw exception as resource is not located in searched path.

New Foxy/Galactic/Rolling Releases

After we close #74, I'd like to get a new new release with all the latest features. I realize the last release was last month, but thought I'd get it on the radar anyway.

Progress toward Quality Level 1

This issue tracks the progression of packages in ament_index that have been deemed necessary for Quality Level 1 and a 1.0 version level. It follows the outline described in REP 2004.

The packages slated for Quality Level 1 for ROS 2 Foxy are:

• ament_index_cpp

Excluded for Quality Level 1 at this time:

• ament_index_python

Progress of ament_index_cpp:

• Version Policy
  • Follows ROS Core Quality Declaration
• Version >= 1.0.0
• Change Control Process
  • Recommended guidelines for ROS Core packages in the ROS 2 Developer Guide
• API and ABI stability within a ROS distribution
• Vulnerability Disclosure Policy

Documentation

• Per-feature documentation.
• Per-item documentation in public API.
  • Docstrings, not hosted in API Docs.
• Declared set of licenses
• Copyright statement in each source file
  • Checked with ament_copyright
• Quality Declaration document

Testing:

• System tests, which cover "features"
• Tests covering public API
• Code Coverage > 95%:
  • • Must have code coverage tracking for the package -> here
  • • Must have and enforce a code coverage policy for new changes Policy
• Performance tests: not currently available.
• Linters and Static Analysis:
  • • Must have a code style and enforce it.
  • • Must use static analysis tools where applicable:
      -- See Linters ROS 2 Developer Guide

Dependencies:

• Runtime "ROS" dependencies are level 1
  • None
• non-ROS dependencies are equivalent level 1
  • None

Platform Support

• Supports all tier 1 platforms as described in REP-2000

Broken documentation

It seems that the generated documentation for this package is broken:

For example: https://docs.ros2.org/galactic/api/ament_index_python/api/packages.html is empty even though the packages.py file itself has docstrings.

Colcon build failed if a package set the requirement of ament_index_cpp

-- Found ament_index_cpp: 1.4.0 (/Users/xxx/Develop/ros2/ros2_humble/install/share/ament_index_cpp/cmake)
CMake Error at /Users/xxx/Develop/ros2/ros2_humble/install/share/ament_index_cpp/cmake/ament_cmake_export_targets-extras.cmake:18 (message):
Failed to find exported target names in
'/Users/xxx/Develop/ros2/ros2_humble/install/share/ament_index_cpp/cmake/export_ament_index_cppExport.cmake'
Call Stack (most recent call first):
/Users/xxx/Develop/ros2/ros2_humble/install/share/ament_index_cpp/cmake/ament_index_cppConfig.cmake:41 (include)
CMakeLists.txt:14 (find_package)

gtest linking error

Testing the install instructions ament_index_cpp failed to build the unit tests. https://github.com/ros2/ros2/wiki/Linux-Development-Setup

The only difference was that I used https://github.com/ros2/ros2/raw/master/ros2.repos instead of the tagged version.

Linking CXX executable ament_index_cpp_utest
/usr/bin/cmake -E cmake_link_script CMakeFiles/ament_index_cpp_utest.dir/link.txt --verbose=1
/usr/bin/c++    -std=c++11 -Wall -Wextra    CMakeFiles/ament_index_cpp_utest.dir/test/utest.cpp.o  -o ament_index_cpp_utest -rdynamic gtest/libgtest.a gtest/libgtest_main.a libament_index_cpp.so -Wl,-rpath,/root/ros2_ws/build/ament_index_cpp 
gtest/libgtest.a(gtest-all.cc.o): In function `testing::internal::ThreadLocal<testing::TestPartResultReporterInterface*>::~ThreadLocal()':
gtest-all.cc:(.text._ZN7testing8internal11ThreadLocalIPNS_31TestPartResultReporterInterfaceEED2Ev[_ZN7testing8internal11ThreadLocalIPNS_31TestPartResultReporterInterfaceEED5Ev]+0x15): undefined reference to `pthread_getspecific'
gtest-all.cc:(.text._ZN7testing8internal11ThreadLocalIPNS_31TestPartResultReporterInterfaceEED2Ev[_ZN7testing8internal11ThreadLocalIPNS_31TestPartResultReporterInterfaceEED5Ev]+0x2a): undefined reference to `pthread_key_delete'
gtest/libgtest.a(gtest-all.cc.o): In function `testing::internal::ThreadLocal<std::vector<testing::internal::TraceInfo, std::allocator<testing::internal::TraceInfo> > >::~ThreadLocal()':
gtest-all.cc:(.text._ZN7testing8internal11ThreadLocalISt6vectorINS0_9TraceInfoESaIS3_EEED2Ev[_ZN7testing8internal11ThreadLocalISt6vectorINS0_9TraceInfoESaIS3_EEED5Ev]+0x15): undefined reference to `pthread_getspecific'
gtest-all.cc:(.text._ZN7testing8internal11ThreadLocalISt6vectorINS0_9TraceInfoESaIS3_EEED2Ev[_ZN7testing8internal11ThreadLocalISt6vectorINS0_9TraceInfoESaIS3_EEED5Ev]+0x2a): undefined reference to `pthread_key_delete'
gtest/libgtest.a(gtest-all.cc.o): In function `testing::internal::ThreadLocal<std::vector<testing::internal::TraceInfo, std::allocator<testing::internal::TraceInfo> > >::GetOrCreateValue() const':
gtest-all.cc:(.text._ZNK7testing8internal11ThreadLocalISt6vectorINS0_9TraceInfoESaIS3_EEE16GetOrCreateValueEv[_ZNK7testing8internal11ThreadLocalISt6vectorINS0_9TraceInfoESaIS3_EEE16GetOrCreateValueEv]+0x18): undefined reference to `pthread_getspecific'
gtest-all.cc:(.text._ZNK7testing8internal11ThreadLocalISt6vectorINS0_9TraceInfoESaIS3_EEE16GetOrCreateValueEv[_ZNK7testing8internal11ThreadLocalISt6vectorINS0_9TraceInfoESaIS3_EEE16GetOrCreateValueEv]+0x7c): undefined reference to `pthread_setspecific'
gtest/libgtest.a(gtest-all.cc.o): In function `testing::internal::ThreadLocal<testing::TestPartResultReporterInterface*>::CreateKey()':
gtest-all.cc:(.text._ZN7testing8internal11ThreadLocalIPNS_31TestPartResultReporterInterfaceEE9CreateKeyEv[_ZN7testing8internal11ThreadLocalIPNS_31TestPartResultReporterInterfaceEE9CreateKeyEv]+0x16): undefined reference to `pthread_key_create'
gtest/libgtest.a(gtest-all.cc.o): In function `testing::internal::ThreadLocal<std::vector<testing::internal::TraceInfo, std::allocator<testing::internal::TraceInfo> > >::CreateKey()':
gtest-all.cc:(.text._ZN7testing8internal11ThreadLocalISt6vectorINS0_9TraceInfoESaIS3_EEE9CreateKeyEv[_ZN7testing8internal11ThreadLocalISt6vectorINS0_9TraceInfoESaIS3_EEE9CreateKeyEv]+0x16): undefined reference to `pthread_key_create'
gtest/libgtest.a(gtest-all.cc.o): In function `testing::internal::ThreadLocal<testing::TestPartResultReporterInterface*>::GetOrCreateValue() const':
gtest-all.cc:(.text._ZNK7testing8internal11ThreadLocalIPNS_31TestPartResultReporterInterfaceEE16GetOrCreateValueEv[_ZNK7testing8internal11ThreadLocalIPNS_31TestPartResultReporterInterfaceEE16GetOrCreateValueEv]+0x16): undefined reference to `pthread_getspecific'
gtest-all.cc:(.text._ZNK7testing8internal11ThreadLocalIPNS_31TestPartResultReporterInterfaceEE16GetOrCreateValueEv[_ZNK7testing8internal11ThreadLocalIPNS_31TestPartResultReporterInterfaceEE16GetOrCreateValueEv]+0x7a): undefined reference to `pthread_setspecific'
collect2: error: ld returned 1 exit status
make[2]: *** [ament_index_cpp_utest] Error 1
make[2]: Leaving directory `/root/ros2_ws/build/ament_index_cpp'
make[1]: *** [CMakeFiles/ament_index_cpp_utest.dir/all] Error 2
make[1]: Leaving directory `/root/ros2_ws/build/ament_index_cpp'
make: *** [all] Error 2


root@8c851524db7e:~/ros2_ws# nm /root/ros2_ws/build/ament_index_cpp/gtest/libgtest.a | grep pthread_key_create
                 w __pthread_key_create
                 U pthread_key_create


root@8c851524db7e:~/ros2_ws# nm /usr/lib/x86_64-linux-gnu/libpthread.a | grep pthread_key_create
                 U pthread_key_create
pthread_key_create.o:
0000000000000000 T __pthread_key_create
0000000000000000 T pthread_key_create



VERBOSE error:

Linking CXX executable ament_index_cpp_utest
/usr/bin/cmake -E cmake_link_script CMakeFiles/ament_index_cpp_utest.dir/link.txt --verbose=1
/usr/bin/c++    -std=c++11 -Wall -Wextra    CMakeFiles/ament_index_cpp_utest.dir/test/utest.cpp.o  -o ament_index_cpp_utest -rdynamic gtest/libgtest.a gtest/libgtest_main.a libament_index_cpp.so -Wl,-rpath,/root/ros2_ws/build/ament_index_cpp 
gtest/libgtest.a(gtest-all.cc.o): In function `testing::internal::ThreadLocal<testing::TestPartResultReporterInterface*>::~ThreadLocal()':
gtest-all.cc:(.text._ZN7testing8internal11ThreadLocalIPNS_31TestPartResultReporterInterfaceEED2Ev[_ZN7testing8internal11ThreadLocalIPNS_31TestPartResultReporterInterfaceEED5Ev]+0x15): undefined reference to `pthread_getspecific'
gtest-all.cc:(.text._ZN7testing8internal11ThreadLocalIPNS_31TestPartResultReporterInterfaceEED2Ev[_ZN7testing8internal11ThreadLocalIPNS_31TestPartResultReporterInterfaceEED5Ev]+0x2a): undefined reference to `pthread_key_delete'
gtest/libgtest.a(gtest-all.cc.o): In function `testing::internal::ThreadLocal<std::vector<testing::internal::TraceInfo, std::allocator<testing::internal::TraceInfo> > >::~ThreadLocal()':
gtest-all.cc:(.text._ZN7testing8internal11ThreadLocalISt6vectorINS0_9TraceInfoESaIS3_EEED2Ev[_ZN7testing8internal11ThreadLocalISt6vectorINS0_9TraceInfoESaIS3_EEED5Ev]+0x15): undefined reference to `pthread_getspecific'
gtest-all.cc:(.text._ZN7testing8internal11ThreadLocalISt6vectorINS0_9TraceInfoESaIS3_EEED2Ev[_ZN7testing8internal11ThreadLocalISt6vectorINS0_9TraceInfoESaIS3_EEED5Ev]+0x2a): undefined reference to `pthread_key_delete'
gtest/libgtest.a(gtest-all.cc.o): In function `testing::internal::ThreadLocal<std::vector<testing::internal::TraceInfo, std::allocator<testing::internal::TraceInfo> > >::GetOrCreateValue() const':
gtest-all.cc:(.text._ZNK7testing8internal11ThreadLocalISt6vectorINS0_9TraceInfoESaIS3_EEE16GetOrCreateValueEv[_ZNK7testing8internal11ThreadLocalISt6vectorINS0_9TraceInfoESaIS3_EEE16GetOrCreateValueEv]+0x18): undefined reference to `pthread_getspecific'
gtest-all.cc:(.text._ZNK7testing8internal11ThreadLocalISt6vectorINS0_9TraceInfoESaIS3_EEE16GetOrCreateValueEv[_ZNK7testing8internal11ThreadLocalISt6vectorINS0_9TraceInfoESaIS3_EEE16GetOrCreateValueEv]+0x7c): undefined reference to `pthread_setspecific'
gtest/libgtest.a(gtest-all.cc.o): In function `testing::internal::ThreadLocal<testing::TestPartResultReporterInterface*>::CreateKey()':
gtest-all.cc:(.text._ZN7testing8internal11ThreadLocalIPNS_31TestPartResultReporterInterfaceEE9CreateKeyEv[_ZN7testing8internal11ThreadLocalIPNS_31TestPartResultReporterInterfaceEE9CreateKeyEv]+0x16): undefined reference to `pthread_key_create'
gtest/libgtest.a(gtest-all.cc.o): In function `testing::internal::ThreadLocal<std::vector<testing::internal::TraceInfo, std::allocator<testing::internal::TraceInfo> > >::CreateKey()':
gtest-all.cc:(.text._ZN7testing8internal11ThreadLocalISt6vectorINS0_9TraceInfoESaIS3_EEE9CreateKeyEv[_ZN7testing8internal11ThreadLocalISt6vectorINS0_9TraceInfoESaIS3_EEE9CreateKeyEv]+0x16): undefined reference to `pthread_key_create'
gtest/libgtest.a(gtest-all.cc.o): In function `testing::internal::ThreadLocal<testing::TestPartResultReporterInterface*>::GetOrCreateValue() const':
gtest-all.cc:(.text._ZNK7testing8internal11ThreadLocalIPNS_31TestPartResultReporterInterfaceEE16GetOrCreateValueEv[_ZNK7testing8internal11ThreadLocalIPNS_31TestPartResultReporterInterfaceEE16GetOrCreateValueEv]+0x16): undefined reference to `pthread_getspecific'
gtest-all.cc:(.text._ZNK7testing8internal11ThreadLocalIPNS_31TestPartResultReporterInterfaceEE16GetOrCreateValueEv[_ZNK7testing8internal11ThreadLocalIPNS_31TestPartResultReporterInterfaceEE16GetOrCreateValueEv]+0x7a): undefined reference to `pthread_setspecific'
collect2: error: ld returned 1 exit status
make[2]: *** [ament_index_cpp_utest] Error 1
make[2]: Leaving directory `/root/ros2_ws/build/ament_index_cpp'
make[1]: *** [CMakeFiles/ament_index_cpp_utest.dir/all] Error 2
make[1]: Leaving directory `/root/ros2_ws/build/ament_index_cpp'
make: *** [all] Error 2

It passes with -lpthread added manually to the failing line. 

ament_index/resource_index/packages files not packaged into debs

This is very likely the wrong place for this ticket but I'm not rightly sure where it should be reported.

Problem:

Local workspace builds correctly install files into ament_index/resource_index/packages so that tools from ros2cli can discover packages correctly. However the same packages when built as debs do not install that file and subsequently require it to be forced via setup.py in the following manner (discovered on inspection of ros2cli/setup.py itself):

    data_files=[
        ('share/ament_index/resource_index/packages', [
            'resources/<name-of-my-package>']),
    ],

Expected:

• Workspace installs / packaged deb installs shouldn't have different requirements
• Processes for packaging debs know how to bring in this file automagically without it being explicitly dictated in setup.py (perhaps it should be explicit for both workspace and deb installs?)

A little surprised that ament index requires other packages to be aware of it.

implement topological order in sh and bat

Then the prefix-level local_setup file doesn't need to call Python anymore.

get_package_share_directory does not return a conventional Windows directory

Running get_package_share_directory in Windows returns C:<path_to_ws>\install/share/.
It should instead be C:<path_to_ws>\install\share\.

My proposed solution is either:
a. Use rcpputil's path
b. Add an #ifdef _WIN32 block which uses the proper backslash

I don't see a maintainer/code owner in the repo so @dirk-thomas @wjwwood if there's no issue I'll open a PR.

Feature Request: Support for std::filesystem::path in ament_index_cpp

Feature Request

Could this library support the use std::filesystem::path? You can also use std::optional to represent optional parameters without a raw pointer. Both are C++17 only.

Example

AMENT_INDEX_CPP_PUBLIC
bool
get_resource(
  const std::string & resource_type,
  const std::string & resource_name,
  std::string & content,
  std::optional<std::filesystem::path> prefix_path = std::nullopt);
  
  
AMENT_INDEX_CPP_PUBLIC
std::filesystem::path
get_package_prefix(const std::string & package_name);

For functions that return std::string currently such as get_package_prefix, an alternative signature may be needed to preserve ABI such as:

AMENT_INDEX_CPP_PUBLIC
void
get_package_prefix(const std::string & package_name, std::filesystem::path & path);

Then, the library could go through a deprecation process of returning std::string paths and slowly convert the ecosystem to using std::filesystem for path-like types.

ament_index_python not being registered in the package ament_index resource

It seems from inspecting the nightly fat archive, that ament_index_python is not being included in the ament_index resource or listing packages. cc @dirk-thomas

$ ls share/ament_index/resource_index/packages/ | grep ament
ament_cmake
ament_cmake_auto
ament_cmake_clang_format
ament_cmake_clang_tidy
ament_cmake_copyright
ament_cmake_core
ament_cmake_cppcheck
ament_cmake_cpplint
ament_cmake_export_definitions
ament_cmake_export_dependencies
ament_cmake_export_include_directories
ament_cmake_export_interfaces
ament_cmake_export_libraries
ament_cmake_export_link_flags
ament_cmake_flake8
ament_cmake_gmock
ament_cmake_gtest
ament_cmake_include_directories
ament_cmake_libraries
ament_cmake_lint_cmake
ament_cmake_mypy
ament_cmake_nose
ament_cmake_pclint
ament_cmake_pep257
ament_cmake_pep8
ament_cmake_pyflakes
ament_cmake_pytest
ament_cmake_python
ament_cmake_ros
ament_cmake_target_dependencies
ament_cmake_test
ament_cmake_uncrustify
ament_cmake_xmllint
ament_index_cpp
ament_lint_auto
ament_lint_common
launch_testing_ament_cmake

get_package_share_directory() should print a warning if it fails

When used from a launch file, get_package_share_directory() should print a warning if it fails.

ament_index_cpp header files may not be installed in the right place

I'm probably doing something wrong, but figure I will raise the issue just in case.

• Fresh binary installation of ROS2 Rolling
• Ubuntu 22.04
• ament_index_cpp header files are installed to /opt/ros/rolling/include/ament_index_cpp/ament_index_cpp
• Previously, the same header filers were installed to /opt/ros/rolling/include/ament_index_cpp/
• I now get this error while building:

/home/andy/.../task_planning/src/task_data_parser.cpp:5:10: fatal error: ament_index_cpp/get_package_share_directory.hpp: No such file or directory
    5 | #include "ament_index_cpp/get_package_share_directory.hpp"

I temporarily "fixed" this by copying all of the header files down one directory.

I do have ament_index_cpp listed in my package.xml and CMakeLists.