While the find modules that CMake provide don't use
include_directories some externally written find module you are using
could.
You really need to provide a standalone reproduction of the problem,
as currently people can only speculate on what is occurring.
On Thu, Aug 2, 2018 at 7:58 AM Mario Emmenlauer <ma...@emmenlauer.de> wrote:
>
>
> Dear Robert,
>
> On 31.07.2018 15:04, Robert Maynard wrote:
> > The BEFORE keyword places the includes before any other paths such as
> > ones from other target_include_directories statements or from
> > transitive propagation from targets you linked too.
> >
> > As to why `CMAKE_PREFIX_PATH` is being added, I expect that some find
> > call is bring it in as an include directory.
> > On Mon, Jul 30, 2018 at 5:43 PM Mario Emmenlauer <ma...@emmenlauer.de>
> > wrote:
>
> I would like to understand why `CMAKE_PREFIX_PATH` is in second position
> of includes. I add ${CMAKE_CURRENT_SOURCE_DIR}/include before. Are you
> saying that find_package() is modifying the includes directly, like by
> calling include_directories()? That would be pretty bad!
>
> I am rather under the assumption that target_link_libraries() is changing
> the order of includes.
>
> All the best,
>
> Mario
>
>
>
> >>
> >> Should I report this as a bug or am I just doing something wrong?
> >> Help would be greatly appreciated!
> >>
> >> All the best,
> >>
> >> Mario
> >>
> >>
> >> On 26.07.2018 11:58, Mario Emmenlauer wrote:
> >>>
> >>> Dear CMake users and developers,
> >>>
> >>> I've just discovered a build problem that comes from a wrong order of
> >>> includes. I would know the correct order, but I am unable to instruct
> >>> CMake to use the order I need.
> >>>
> >>> Here is a toy example that I tested with cmake 3.12.0:
> >>>
> >>>
> >>> ----
> >>> cmake_minimum_required(VERSION 3.8)
> >>> project(MyLib VERSION 1.0.0)
> >>> find_package(XXX REQUIRED)
> >>> find_package(YYY REQUIRED)
> >>> add_library(${PROJECT_NAME} include/MyLib.hh src/MyLib.cc)
> >>> target_include_directories(${PROJECT_NAME}
> >>> PRIVATE
> >>> ${CMAKE_CURRENT_SOURCE_DIR}/src
> >>> ${CMAKE_CURRENT_BINARY_DIR}
> >>> PUBLIC
> >>> $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/include>
> >>> $<INSTALL_INTERFACE:include>
> >>> ${XXX_INCLUDE_DIRS} ${YYY_INCLUDE_DIRS})
> >>> target_link_libraries(MyLib PUBLIC ${XXX_LIBRARIES} ${YYY_LIBRARIES})
> >>> # here come more commands for build flags etc.
> >>>
> >>> enable_testing()
> >>> add_executable(MyTest test/src/MyTest.cc test/src/MyTest.hh)
> >>> target_include_directories(MyTest PRIVATE
> >>> ${CMAKE_CURRENT_SOURCE_DIR}/include
> >>> ${CMAKE_CURRENT_SOURCE_DIR}/test/src
> >>> ${CMAKE_CURRENT_SOURCE_DIR}/src
> >>> ${CMAKE_CURRENT_BINARY_DIR}
> >>> ${GTEST_INCLUDE_DIRS})
> >>> target_link_libraries(MyTest PRIVATE MyLib ${GTEST_MAIN_LIBRARIES})
> >>> # here come more commands for build flags etc.
> >>> ----
> >>>
> >>>
> >>> I configure cmake with -DCMAKE_PREFIX_PATH=${MY_PREFIX_PATH}. When
> >>> I build the project, the order of includes for MyLib is fine. But
> >>> for MyTest, the following are the first two includes:
> >>> -IMyTest_autogen/include
> >>> -I${MY_PREFIX_PATH}/include
> >>>
> >>> I think the second include should come much later, only *after*
> >>> ${CMAKE_CURRENT_SOURCE_DIR}/include, but it comes before. Therefore,
> >>> if older headers exists in ${MY_PREFIX_PATH}/include, they will be
> >>> used instead of ${CMAKE_CURRENT_SOURCE_DIR}/include!
> >>>
> >>> I found that I can fix the problem by adding 'BEFORE' to all
> >>> target_include_directories(). However I'm puzzled why this helps.
> >>> Before anything I call target_include_directories(), and before other
> >>> includes I have ${CMAKE_CURRENT_SOURCE_DIR}/src,
> >>> ${CMAKE_CURRENT_BINARY_DIR} and ${CMAKE_CURRENT_SOURCE_DIR}/include.
> >>> So what does 'BEFORE' mean in this case? Aren't these the first
> >>> includes any ways?
> >>>
> >>> Thanks for any help, and Cheers,
> >>>
> >>> Mario Emmenlauer
> >>
> >>
> >>
> >> Viele Gruesse,
> >>
> >> Mario Emmenlauer
> >>
> >>
> >> --
> >> BioDataAnalysis GmbH, Mario Emmenlauer Tel. Buero: +49-89-74677203
> >> Balanstr. 43 mailto: memmenlauer * biodataanalysis.de
> >> D-81669 München http://www.biodataanalysis.de/
> >> --
> >>
> >> Powered by www.kitware.com
> >>
> >> Please keep messages on-topic and check the CMake FAQ at:
> >> http://www.cmake.org/Wiki/CMake_FAQ
> >>
> >> Kitware offers various services to support the CMake community. For more
> >> information on each offering, please visit:
> >>
> >> CMake Support: http://cmake.org/cmake/help/support.html
> >> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> >> CMake Training Courses: http://cmake.org/cmake/help/training.html
> >>
> >> Visit other Kitware open-source projects at
> >> http://www.kitware.com/opensource/opensource.html
> >>
> >> Follow this link to subscribe/unsubscribe:
> >> https://cmake.org/mailman/listinfo/cmake
> >
>
>
>
> Viele Gruesse,
>
> Mario Emmenlauer
>
>
> --
> BioDataAnalysis GmbH, Mario Emmenlauer Tel. Buero: +49-89-74677203
> Balanstr. 43 mailto: memmenlauer * biodataanalysis.de
> D-81669 München http://www.biodataanalysis.de/
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
