subject:"\[CMake\] organizing includes statements"

Re: [CMake] organizing includes statements

2015-12-10 Thread Owen Alanzo Hogarth

oh cool
adding target_include_directories(lib1 PUBLIC
${CMAKE_CURRENT_SOURCE_DIR}/headers)

and then I can just use #include "lib1" where needed. No more of those very
static paths!

Thank you very much!

On Thu, Dec 10, 2015 at 4:08 PM, iosif neitzke <
iosif.neitzke+cm...@gmail.com> wrote:

> 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
>  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
> >  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
> >>$
> >>$ )
> >>
> >> add_library( lib2 SHARED lib2/lib2.c )
> >> target_include_directories( lib2 PUBLIC
> >>$
> >>$ )
> >> 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
> >> >  or #include 
> >> >
> >> > 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
>

Re: [CMake] organizing includes statements

2015-12-10 Thread Owen Alanzo Hogarth

that's actually a good point. Currently as I am developing this i am doing
an out of source build and just testing it from there but eventually what I
want is a shared library that can be used by other programs.

currently though my other programs is just a simple main.c that includes
the main library which includes all the sub libraries.

One of the reasons why I chose to just set the paths as I did was that I
couldn't get the install command to work, not sure why exactly at that time
I was just getting started with cmake so most likely user error. It's been
working so far and the main concern right now is to get this c program
working then refine the cmake build as I go.

I just moved the bin directory to my desktop for testing, that seemed to
work but this is something to keep in mind.

On Thu, Dec 10, 2015 at 4:20 PM, Raymond Wan  wrote:

> Hi Owen,
>
> Sorry to jump into the discussion, but what you're talking is
> something I was thinking of just recently...
>
> I think the choice between this:
>
>
> On Thu, Dec 10, 2015 at 3:48 PM, Owen Alanzo Hogarth
>  wrote:
> > 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)
>
>
> and this:
>
>
> > it seems like this line in your reply above
> > install( TARGETS lib1 lib2 DESTINATION lib )
> > install( FILES lib1/headers/lib1.h lib2/headers/lib2.h DESTINATION
> include )
>
>
> comes down to whether you want to compile other programs with these
> libraries.  If you will not, then you can set the paths to
> CMAKE_BINARY_DIR, which is the path to the top of the build tree.  As
> far as I know, after you compile your program, you can/should delete
> the build tree (i.e., assuming an out-of-source build).
>
> So, most likely, you'd want to pick the second option if you need the
> header files and archives to build something else.  This is because
> when you run cmake, you can set the prefix to install files to (i.e.,
> using "make install").  In my case, I only need header files and
> archives to build something within a single build (i.e., various
> inter-related subdirectories, all under one CMakeLists.txt).  So, I do
> something similar to the first option.
>
> I did toy with the second option a bit but, in the end, realized that
> much of what I wrote won't be reused by another project of mine.  At
> least, that's my understanding of the two options above...
>
> Ray
>
-- 

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

Re: [CMake] organizing includes statements

2015-12-10 Thread iosif neitzke

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
 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
>  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
>>$
>>$ )
>>
>> add_library( lib2 SHARED lib2/lib2.c )
>> target_include_directories( lib2 PUBLIC
>>$
>>$ )
>> 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 
>> > 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
>> >  or #include 
>> >
>> > 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:

Re: [CMake] organizing includes statements

2015-12-10 Thread Raymond Wan

Hi Owen,

Sorry to jump into the discussion, but what you're talking is
something I was thinking of just recently...

I think the choice between this:

On Thu, Dec 10, 2015 at 3:48 PM, Owen Alanzo Hogarth
 wrote:
> 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)

and this:

> it seems like this line in your reply above
> install( TARGETS lib1 lib2 DESTINATION lib )
> install( FILES lib1/headers/lib1.h lib2/headers/lib2.h DESTINATION include )

comes down to whether you want to compile other programs with these
libraries.  If you will not, then you can set the paths to
CMAKE_BINARY_DIR, which is the path to the top of the build tree.  As
far as I know, after you compile your program, you can/should delete
the build tree (i.e., assuming an out-of-source build).

So, most likely, you'd want to pick the second option if you need the
header files and archives to build something else.  This is because
when you run cmake, you can set the prefix to install files to (i.e.,
using "make install").  In my case, I only need header files and
archives to build something within a single build (i.e., various
inter-related subdirectories, all under one CMakeLists.txt).  So, I do
something similar to the first option.

I did toy with the second option a bit but, in the end, realized that
much of what I wrote won't be reused by another project of mine.  At
least, that's my understanding of the two options above...

Ray
-- 

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

[CMake] organizing includes statements

2015-12-09 Thread Owen Alanzo Hogarth

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 
or #include 

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

Re: [CMake] organizing includes statements

2015-12-09 Thread Attila Krasznahorkay

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
   $
   $ )

add_library( lib2 SHARED lib2/lib2.c )
target_include_directories( lib2 PUBLIC
   $
   $ )
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  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  or 
> #include 
> 
> 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

Re: [CMake] organizing includes statements

2015-12-09 Thread Owen Alanzo Hogarth

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
>$
>$ )
>
> add_library( lib2 SHARED lib2/lib2.c )
> target_include_directories( lib2 PUBLIC
>$
>$ )
> 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 
> 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
>  or #include 
> >
> > 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

Re: [CMake] organizing includes statements

Re: [CMake] organizing includes statements

Re: [CMake] organizing includes statements

Re: [CMake] organizing includes statements

[CMake] organizing includes statements

Re: [CMake] organizing includes statements

Re: [CMake] organizing includes statements

7 matches

Site Navigation

Mail list logo

Footer information