I think in the end I'll replace my ADD_SUBDIRECTORY+macros[1] method for a simpler INCLUDE based ones. The INCLUDE based one isn't ideal (and really, it seems like an abuse of INCLUDE for something ADD_SUBDIRECTORY or EXPORT should do), but its less code and more natural to cmake users.
Thanks for your help. [1] here's an example of my I_* macros... I'll be switching this over to INCLUDEs though: http://labs.wexussoftware.com/cgi-bin/git.cgi?p=scopira.git;a=blob;h=35a96306ca05a4415d1caf06067cd33660cbd471;hb=abb1d7823969b4104e3bdf8ac4d9853b041cc14f;f=scopira.src/CMakeLists.txt On Tue, Sep 23, 2008 at 12:15 PM, Mike Jackson <[EMAIL PROTECTED]> wrote: > That is basically what I do. Until someone tells me a better way. > > Take a look at the following link: > > http://www.bluequartz.net/viewvc/CTMD/MXATools/CMakeLists.txt?view=markup > for an example of how I am doing things. > > mike > > Aleksander Demko wrote: >> >> I guess I'm looking for a way to automatically "relay" information >> between the main project B and one or more library projects A, etc. My >> projects tend to involve lots of sub libraries, so I need a way for >> this to work in a scalable manner. >> >> If I try to simply INCLUDE A in B, then all the relative source paths >> in the add_library call do not work. Is there a nice work around for >> this? >> >> My current solution involves that I, in executable B, do an >> ADD_SUBDIRECTORY on A. I then have a few (gross) macros that help me >> propagate the include dirs and defines in A up to B. The macros >> inspect and manipulate the COMPILE_FLAGS properties of the targets. >> Here is a short example (my macros are named I_*): >> >> ... >> ADD_SUBDIRECTORY(${DBA_SRC_PATH} dba) >> ... >> ADD_LIBRARY(wxdba wxdba/colour_fi... >> I_ADD_RELATIVE_INCLUDE(wxdba .) >> I_TARGET_LINK_LIBRARY(wxdba dba) >> I_ADD_COMPILE_FLAGS(wxdba /DwxUSE_UNICODE) >> >> Then sub executables can use wxdba and include all the cflags, include >> directories needed for both wxdba and its dependent project dba. The >> wxdba project also inherited any cflags/include directories that dba >> had via the I_TARGET... call. >> >> I was hoping for a more mainstream approach that requires less >> specialized macros. >> >> On Mon, Sep 22, 2008 at 7:41 PM, Mike Jackson >> <[EMAIL PROTECTED]> wrote: >> >>> >>> Not totally sure what you are after BUT one possible implementation is >>> something like the following. >>> >>> If you have a Library A that you want to include in Executable B and Both >>> are there own projects based on CMake then there is "some" integration >>> that >>> can happen. >>> >>> So for library A you have a normal CMakeLists.txt file for that project. >>> Then for the executable project you simply "include" the CMakeLists.txt >>> file >>> from library A. >>> >>> If the "Library A" project you have: >>> add_library (A SHARED ${sources}) >>> >>> Then in the executable project you have something like: >>> >>> add_executable (myexec ${sources} ) >>> target_link_libraries(myexec A) >>> >>> When you build the executable project CMake will automatically build the >>> "A" >>> library first. This is one way to achieve this. ( I do this in a few of >>> my >>> projects ). >>> >>> >>> >>> Some helper code that might be handy: >>> # This code goes in the Executable projects CMakeLists.txt file >>> # --- Get the LibA Project by looking for a folder called "src" in the >>> LibraryA folder >>> GET_FILENAME_COMPONENT(CURRENT_SOURCE_PARENT ${CMAKE_CURRENT_SOURCE_DIR} >>> PATH) >>> FIND_PATH(A_SOURCE_DIR src >>> "${CURRENT_SOURCE_PARENT}/LibraryA" >>> ) >>> IF (NOT A_SOURCE_DIR) >>> MESSAGE(FATAL_ERROR "Could not find LibraryA Directory. Please set the >>> directory") >>> ENDIF(NOT MXA_SOURCE_DIR) >>> >>> Now. if you can not do something like the above or you don't want to tie >>> the >>> projects together like that then you can "configure" a header file from >>> LibraryA that can be used in the executable project to "relay" >>> information >>> about the library, like if it was built as a shared or static library. >>> Again, this is also done in lots of projects. >>> >>> The last way to "relay" information would be to have CMake write the >>> information into a simple text file that the executable project can then >>> parse. >>> >>> Keep asking.. we'll help as much as we can. >>> --- >>> Mike Jackson - Principal Software Engineer >>> www.bluequartz.net >>> >>> >>> >>> >>> On Sep 22, 2008, at 5:46 PM, Aleksander Demko wrote: >>> >>> >>>> >>>> Dang, that won't work for me. I'm in effect trying to make my own >>>> EXPORT like command (export doesn't maintain C flags or other stuff I >>>> need) so I need to be able to gleam a bunch of info from the library >>>> targets dynamically. >>>> >>>> Basically I want to quickly build one library in one cmake session, >>>> than import it in another (without have to write custom Find-.cmake >>>> files etc). Maybe this exists already in cmake, but I can't seem to >>>> find it. >>>> >>>> >>>> On Mon, Sep 22, 2008 at 4:32 PM, Mike Jackson >>>> <[EMAIL PROTECTED]> wrote: >>>> >>>>> >>>>> You will probably have to set your own variable into the cache and then >>>>> check that variable later on in your scripts >>>>> >>>>> >>>>> >>>>> On Sep 22, 2008, at 5:23 PM, Aleksander Demko wrote: >>>>> >>>>> >>>>>> >>>>>> On Mon, Sep 22, 2008 at 4:15 PM, Mike Jackson >>>>>> <[EMAIL PROTECTED]> wrote: >>>>>> >>>>>>> >>>>>>> Assuming you mean a library that you are creating the default is >>>>>>> static. >>>>>>> If >>>>>>> you want a dynamic library then use the "SHARED" keyword: >>>>>>> >>>>>>> add_library (mylib SHARED libsource.cpp) >>>>>>> >>>>>>> >>>>>> >>>>>> I understand that. But later in my script I want to check if mylib is >>>>>> shared or static with an IF command. I want the command to know if the >>>>>> add_library was the default static, shared or shared because >>>>>> BUILD_SHARE_LIBS is true. >>>>>> >>>> > > _______________________________________________ > CMake mailing list > [email protected] > http://www.cmake.org/mailman/listinfo/cmake > _______________________________________________ CMake mailing list [email protected] http://www.cmake.org/mailman/listinfo/cmake
