I would think
add_library( lib1 SHARED lib1/lib1.c )
target_include_directories( lib1 PUBLIC lib1/headers )
is simpler. Are the generator expressions needed for target export
install commands, and is exporting targets at install preferred to
add_subdirectory() ?
On Thu, Dec 10, 2015 at 1:48 AM, Owen Alanzo Hogarth
<gurenc...@gmail.com> wrote:
> my main CMakeLists.txt file already has a few directives that move the libs
> to an output folder so the binaries go to /bin while static and shared
> libraries go to /lib
>
> set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
> set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
> set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)
>
>
> it seems like this line in your reply above
> install( TARGETS lib1 lib2 DESTINATION lib )
>
> moves the shared libraries to the lib folder and this line below moves the
> header files to the newly created include directory.
>
> install( FILES lib1/headers/lib1.h lib2/headers/lib2.h DESTINATION include )
>
> is that right?
>
> On Thu, Dec 10, 2015 at 1:46 PM, Attila Krasznahorkay
> <attila.krasznahor...@gmail.com> wrote:
>>
>> Hi Owen,
>>
>> This seems like a textbook example of using target_include_directories(…)
>> with generator expressions. Let’s take the example where:
>>
>> lib1/headers/lib1.h
>> lib1/lib1.c
>> lib2/headers/lib2.h
>> lib2/lib2.c
>>
>> If you want to be able to include lib1.h and lib2.h with simply
>>
>> #include “lib1.h”
>>
>> and
>>
>> #include “lib2.h”
>>
>> in your user code, and in the library code itself, you’d do something
>> like:
>>
>> add_library( lib1 SHARED lib1/lib1.c )
>> target_include_directories( lib1 PUBLIC
>> $<BUILD_INTERFACE:${CMAKE_SOURCE_DIR}/lib1/headers>
>> $<INSTALL_INTERFACE:include> )
>>
>> add_library( lib2 SHARED lib2/lib2.c )
>> target_include_directories( lib2 PUBLIC
>> $<BUILD_INTERFACE:${CMAKE_SOURCE_DIR}/lib2/headers>
>> $<INSTALL_INTERFACE:include> )
>> target_link_libraries( lib2 lib1 )
>>
>> install( FILES lib1/headers/lib1.h lib2/headers/lib2.h DESTINATION include
>> )
>> install( TARGETS lib1 lib2 DESTINATION lib )
>>
>> In this setup “lib1” should get a -I${CMAKE_SOURCE_DIR}/lib1/headers flag,
>> and “lib2” should get both -I${CMAKE_SOURCE_DIR}/lib1/headers and
>> -I${CMAKE_SOURCE_DIR}/lib2/headers. Finally the headers both get installed
>> into the same include directory, so an outside user will just have to be
>> able to find that one directory. (Or if you export CMake’s targets, the
>> lib1/2 imported targets will know that their header files are in that
>> directory.)
>>
>> Cheers,
>> Attila
>>
>> > On Dec 10, 2015, at 12:07 AM, Owen Alanzo Hogarth <gurenc...@gmail.com>
>> > wrote:
>> >
>> > hi
>> >
>> > I am building a shared library project that's composed of many smaller
>> > shared library files.
>> >
>> > Here's the main shared library project and a list of all the sub
>> > projects.
>> >
>> > SET(HEADER_FILES ${CMAKE_CURRENT_SOURCE_DIR}/headers/main_lib.h)
>> > SET(SRC_FILES ${CMAKE_CURRENT_SOURCE_DIR}/main_lib.c)
>> > SET(TARGET_LIBS core_math point2d line2d quad2d timer_utils)
>> >
>> > ADD_LIBRARY(main_lib SHARED ${SRC_FILES} ${HEADER_FILES})
>> > TARGET_LINK_LIBRARIES(core_engine ${TARGET_LIBS})
>> >
>> > i have each module setup like this.
>> > module
>> > module/headers/module.h
>> > module/module.c
>> >
>> > then the module.c will look like this
>> > #include "headers/module.h"
>> >
>> > the file main_lib.h depends on all those target libs, which makes my
>> > main_lib.h file's include statement look like this
>> >
>> > #include "../../module/headers/module.h"
>> > #include "../../module1/headers/module1.h"
>> > #include "../../module2/headers/module2.h"
>> >
>> >
>> > is there any way that I can clean up these includes?
>> >
>> > For example if I want to use io functions I can just do #include
>> > <stdio.h> or #include <math.h>
>> >
>> > for math functions.
>> >
>> > I would like to make my include statements not relative to the files
>> > actual location, the way it's currently hard coded.
>> > --
>> >
>> > 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:
>> > http://public.kitware.com/mailman/listinfo/cmake
>>
>
>
> --
>
> 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:
> http://public.kitware.com/mailman/listinfo/cmake
--
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:
http://public.kitware.com/mailman/listinfo/cmake
