CMAKE_PREFIX_PATH and /usr/local

[Gleb Popov]

On Sat, Jan 16, 2021 at 12:17 AM Tomasz CEDRO <tomek at cedro.info> wrote:

> On Fri, Jan 15, 2021 at 10:05 AM Gleb Popov wrote:
> > On Fri, Jan 15, 2021 at 12:50 AM Tomasz CEDRO wrote:
> >> Hello world :-)
> >> I am porting LimeSuite to FreeBSD. Local patch fixes missing
> >> "/usr/local/" path in CMakeLists.txt so the package now builds fine on
> >> FreeBSD. On Linux probably most of the libraries and includes are
> >> located in /usr/ do problem does not exist.
> >> Upstream has some objections to accept this patch and considers
> >> "/usr/local" a non-standard path [1]. But they propose to use
> >> CMAKE_PREFIX_PATH to add "/usr/local". This however does not seem to
> >> be supported in Ports (yet?).
> >> The question is how to tell CMake about "/usr/local/include" without
> >> source code modification? :-)
> >> Below is the proposed patch:
> >> > @@ -171,6 +171,11 @@ if (ENABLE_NEW_GAIN_BEHAVIOUR)
> >>      add_definitions(-DNEW_GAIN_BEHAVIOUR)
> >>  endif()
> >> +if (CMAKE_SYSTEM_NAME MATCHES "BSD")
> >> +    include_directories("/usr/local/include")
> >
> > This is most certainly a wrong thing to do. Instead of simply adding
> -I/usr/local/include everywhere, you should fix problems for each
> dependency that the software requires.
> >
> > What error do you get without your patch?
>
> Hello Gleb :-) This seems the LimeSuite CMake issue not to use
> /usr/local/include where some GL includes are located. Without it
> there is a build problem as GL.h (something like this) is not found. I
> am not sure it this is the only occurrence of this symptom. Simply
> adding /usr/local/include solves the problem.
>

The correct fix is to call find_package(OpenGL) and then use variables it
sets.