Thank you for your answer!
> > How do I resolve something like this? Right now CMake evaluates the
> > compiler includes in the order that subdirectories are added. This
> > gives me an compilation error in uart.c that terminal.h cannot be
> > found.
>
> This is not a cmake-problem, but seems to be a code-structure-issue.
>
> I'm guessing here: if terminal needs the uart-code shouldn't it be the
> uart-code filling in a terminal-function. Interface vs. implementation?
> Could you elaborate more on how terminal and uart are linked?
The terminal code implements a "printf()" equivalent function to log debug and
state information. All input is then directly written to the UART.
The UART driver now wants to use this terminal logging function. It doesn't
care how printf() works.
In the end, this is necessary because there is no file system to store the log
information to. I would like to have this:
uart_write(uart2) -> syslog(prio, errormsg) -> syslog.txt on file system.
But I have:
uart_write(uart2) -> printf(errormsg) -> uart_write(uart1) -> PC with running
terminal software
>
> Regarding cmake: I suggest you stop using include_directories() and
> start using target_include_directories() and
> target_compile_definitions() instead of add_definitions().
I will have a look at this.
>
> Limiting yourself to this way of doing libraries and targets, cmake will
> force you to structure your code in a more standard way - and will
> provide you with clean visibility between different targets.
>
> Could you provide a working, stripped down example to show the problem
> provided via github (in an example repo).
I will try to do this within a few days...
>
> More comments below.
>
> > Some excerpt of my project. I've tried to keep the example as simple
> > as possible.
> >
> > My directory structure looks something like that:
> > /
> > CMakeLists.txt
> > src +
> > +CMakeLists.txt (1)
> > +drivers+
> > | +uart.c
> > | +uart.h
> > | +...
> > | +CMakeLists.txt (2)
> > +os-----+
> > | +terminal.c
> > | +terminal.h
> > | +...
> > | +CMakeLists.txt (3)
> >
> >
> > (1):
> >
> > SET(drivers "drivers")
> > SET(terminal "terminal")
> >
> > SET(drivers_lib ${drivers})
> > SET(terminal_lib ${terminal})
> >
> > SET(ARCHIVE_INSTALL_DIR lib)
> > SET(INCLUDE_INSTALL_DIR include)
> >
> > SET(headers_private "_headers_private") # internal headers
> > SET(headers_public "_headers_public") # public headers go into
> > package
> >
> > ADD_SUBDIRECTORY(${drivers})
> > ADD_SUBDIRECTORY(${terminal})
>
> I think it is common practice now to use lower-case for cmake-commands
> now.
OK.
>
> > ## drivers
> >
> > ## ---- Sources
> > -------------------------------------------------------------------
> > SET(sources "uart.c"
> > )
> >
> > ## ---- Header includes
> > -----------------------------------------------------------
> > SET(headers "${CMAKE_CURRENT_SOURCE_DIR}/"
> > )
> > SET(${drivers}${headers_public} ${headers} PARENT_SCOPE)
> >
> > INCLUDE_DIRECTORIES(${headers}
> > ${${terminal}${headers_public}}
> > )
>
> While the ${${var}${var2}} (seems to) work, it is error-prone, IMHO.
>
> Standard cmake-commands can work with relative paths and are evaluating
> them correctly taking into account ${CMAKE_CURRENT_SOURCE_DIR} (most of
> the time. So you could use ../uart in terminal/
This is what I did to continue working...
> - but it would be better
> if it comes indirectly via target_include_directories() and
> target_link_libraries()
...and this is why I asked the list :-)
>
> >[..]
> >
> > And finally this creates the package in root directory CMakeLists.txt:
> >
> > SET(CPACK_PROJECT_CONFIG_FILE ${CMAKE_BINARY_DIR}/CPackOptions.cmake)
> > # CPackOptions.cmake contains package file name SET(CPACK_GENERATOR
> > "TBZ2") INCLUDE(CPack)
>
> Due to the circular header-dependency the binaries of terminal and uart
> should have the same mutual dependency. In this case you could build
> them in within one target.
Yes, I could do that. But I wanted to get away from one single, monolithic
makefile...
This is why I created one CMake file for every functional unit of my source
code (drivers, RTOS, terminal and so on).
regards,
Martin
--
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
