Closed r-barnes closed 2 months ago
@r-barnes How are you including? Those files are supposed to be placed by a make install
via these lines:
https://github.com/Project-OSRM/osrm-backend/blob/master/CMakeLists.txt#L757-L765
The example/examples.cpp
pulls in osrm/match_parameters.hpp
, and expects you to do -I/usr/local/include
, and it builds cleanly for me outside the source tree.
We definitely haven't put any thought into using OSRM as a subproject library, so a PR that makes it work that way would be welcome, I can't see a reason not to do it.
I'm doing add_subdirectory(osrm)
, which is usually enough. I'll see if I can put something together.
Yeah, that won't work if you're using the public headers (the ones in include/osrm/*
) - those aren't usable until they're placed by the make install
step.
As things stand, if you want to use add_subdirectory
, you'd need to directly include the internal headers, bypassing the public interfaces defined in include/osrm/*
.
This issue seems to be stale. It will be closed in 30 days if no further activity occurs.
I've noticed some oddities about OSRM's build system and wanted to ask whether you'd be amenable to a pull request fixing some of them. It would require some restructuring of the project.
I notice that OSRM's header and source files use includes like the following:
The result of this is that when I try to include OSRM and compile, I get errors like this:
A more standard structure would be to include files like so:
and structure the project such the current contents of
include/
are instead insideinclude/osrm
.Perhaps relatedly,
CMakeLists.txt
usesinclude_directories
to pull OSRM's API. But this information isn't propagated up to other projects using cmake to include OSRM as a dependency. Iftarget_include_directories
were used instead, then this information would be propagated appropriately, making it much easier to use OSRM as a subproject.