First of all, I don't know what I should call it, module, component, or library are all fitting for me, but gave all mixed results trying to figure this out.
Problem
I am working on a project in C, where the amount of files grew quite large, so I wanted to split it up a bit, both for ordering and make it look less cluttered.
I want a file structure that looks something like this:
root
├modules
│├module_foo
││├include
│││├module_foo_a.h
││││...
│││└module_foo_z.h
││├private_include
│││├a.h
││││...
│││└z.h
││├source
│││├module_foo_a.c
││││...
│││└module_foo_z.c
││└module_foo.h
│└module_bar
│ ├include
│ │├module_bar_a.h
│ ││...
│ │└module_bar_z.h
│ ├private_include
│ │├a.h
│ ││...
│ │└z.h
│ ├source
│ │├module_bar_a.c
│ ││...
│ │└module_bar_z.c
│ └module_bar.h
├main.c
├main.h
└CMakeLists.txt
Clarification
The goal of this would be that the private_include folders would be inaccessible by other modules and main, and the different modules would need to work (fairly) independent. Modules can include other modules, but this would need to be defined explicitly.
I also would like the CMake to be easy to modify, ideally only a single/couple line(s) to change for the modules used.
Pre research
As mentioned above, I have searched already, but the CMake documentation isn't meant for the people who just want to do some C coding.
When I searched for modules, almost all results were about the C++ modules and how to integrate them into CMake.
Components mostly gave results about the COMPONENTS keyword.
Library had the most results, however it still requires me to use #include "modules/module_foo/include/module_foo_a.h" from main, or #include "../../module_bar/include/module_bar_a.h" from module foo. The goal would be to have in both instances #include "module_foo_a.h".
Subdirectory isn't what I am looking for I believe, because that still makes it part of the root project. This is not what I want.
For the modules I currently have
project(foo)
add_library(${PROJECT_NAME} STATIC source/module_foo_a.c include/module_foo_a.h)
include_directories(private_include include)
link_libraries(bar)
target_include_directories(${PROJECT_NAME} INTERFACE include)
target_link_libraries(${PROJECT_NAME} PRIVATE bar)
I have included the header files in the add_library because one source I found said it helped with IDE's.
I don't remember why I made the target_include_directories interface, or the target_link_libraries private.
For my main CMake I have
project(foobar)
include_directories(include)
add_executable(${PROJECT_NAME} source/main.c)
target_link_libraries(${PROJECT_NAME} foo bar)
I believe I need to include bar again because of the private link in the module.
I don't even know if what I am searching for is actually possible, but I would really like to work with it this way, or close to this.
edit
Before I tried to add modules the folder structure looked something like this:
root
├include
│├foo_a.h
││...
│├foo_z.h
│├bar_a.h
││...
│├bar_z.h
│└main.h
└source
├foo_a.c
│...
├foo_z.c
├bar_a.c
│...
├bar_z.c
└main.c
This got very cluttered very quickly, hence why I want to change to modules.
As stated in my comment, the part that I have put above is what I have now. This does not make the modules easy to work with, as they don't provide short include names, both from outside the modules (main) and other modules (bar).
The little bits that I understand from CMake is that the functions have a 'normal' variant and a 'target' variant.
'Normal' is just for the current project, and 'target' is meant to also allow other CMakes to use those specified files/folders. This should however not work for the private_include folders, as they are only to be known to the module itself.
If I understand it correctly, including private_include in the 'target' variant would make it possible that you would do #include "a.h" or #include "private_include/a.h" in main, which is not what I want.
Related
I have a CMake project for cross compiling executables for the STM32. The project structure includes folders for the various dependencies required, where the sources and header files are included in those folders. The CMakeLists.txt file to build the project is as easy as setting up for cross compilation and then globing together the sources from each dependency and user code, followed by setting the locations of all the headers with include_directories. Finally, add_executable is used to combine everything and build the binary.
I realize, this is probably not the most optimal way to do this (should probably build the deps as libraries), but it does work for now.
The issue comes in with a dep that has many layers of subdirs (lwIP), and the source and header files contain include statements that are references to levels of subdirs in that dep. For example, the lwIP file structure looks like:
> LwIP
| include
| lwip
| err.h
| netif
An lwIP source file (or header file!) might include "lwip/err.h". Of course, the preproc cannot find this file because the relative path makes no sense to it.
How should I configure this project such that these includes can be used without modifying source or header files?
The usual way to get around this issue is to create your own find module i.e. FindXXX.cmake (in your case it is FindLwIP.cmake) so that you can create LwIP_INCLUDE_DIRS variable within the package.
set(LwIP_INCLUDE_DIRS
${CMAKE_CURRENT_LIST_DIR}/../LwIP/include
${CMAKE_CURRENT_LIST_DIR}/../LwIP
${CMAKE_CURRENT_LIST_DIR}/../LwIP/include/XXX)
.
.
(omitted..)
.
.
include(FindPackageHandleStandardArgs)
find_package_handle_standard_args(LwIP DEFAULT_MSG LwIP_INCLUDE_DIRS LwIP_SOURCES LwIP_HEADERS)
With the above find module, your application can cleanly include the package and use the variables that are created by the find the module.
find_package(LwIP REQUIRED)
.
.
(omitted...)
.
.
include_directories(LwIP_INCLUDE_DIRS)
add_executable(${PROJECT_NAME}.elf ${SOURCES})
Since your work is related to STM32 & cmake, let me give you a great reference which will be a nice starting point for your work as well.
https://github.com/ObKo/stm32-cmake.git
Hope this helps.
I have a source tree:
/bootloader
/firmware
/system
and want to manage two separate builds for firmware and bootloader, each of them using common system sources but compiles them differently (i.e. with its own set of options).
Builds must be out-of-tree.
Obvious "repository" feature of makepp is not a solution here, because it breaks this principle. Symbolic links are not solution too, because it must work on Windows.
The problem actually is in shared system sources, whose relative path structure differs from others, causing common pattern rules not work for them:
BUILD_PATH = $(relative_to $(PROJECT_PATH), .)/BUILD/$(relative_to ., $(PROJECT_PATH)) # trick to be able to extend rules for specific files at different subtree levels (if we use Makeppfile for each level)
...
$(BUILD_PATH)/%.o : %.c
...
Approach with single RootMakeppfile and include *.mk files (instead loading them) also doesn't allow me to do something like that:
$(BUILD_ROOT_PATH)/*/%.o : %.c
I've tried a lot of totally different approaches. It's not such trivial, as it seems to be at first glance. Please, help.
I finally managed how to solve problem.
Solution is to divide Rootmakeppfile project to two Rootmakeppfile subprojects (both loading ../system makeppfile in its own way), and perform build separately for each subproject (in its own build directory). Project structure with makefiles:
/bootloader/
...
BUILD/
Rootmakeppfile
/firmware/
...
BUILD/
Rootmakeppfile
/system/
...
Makeppfile
/project.mk
Common definitions .mk file should contain following lines:
BUILD_ROOT_DIR = $(relative_to $(SUBPROJECT_PATH), .)/BUILD
BUILD_OBJ_REL_PATH = $(BUILD_ROOT_DIR)/$(relative_to ., $(BUILD_OBJ_REL_DIR))
BUILD_OBJ_REL_DIR ?= $(SUBPROJECT_PATH)
Each subproject should include system as follows:
load_makefile BUILD_OBJ_REL_DIR="$(SUBPROJECT_PATH)/.." ../system
and define:
global SUBPROJECT_PATH := $(abspath .)
This approach makes possible to define pattern rules as follows:
$(BUILD_OBJ_REL_PATH)/%.o : %.c
Hope, it helps someone!
In trying to setup auto completion for C using clang complete in vim, and so far, when I'm inside a .c file, I kind of get auto completion when I hit ctrl+x,u. However it only displays some symbols.
None of the functions that's in the included headers appear in the auto complete popup box. It appears that only typedefs are showing?
The project structure is very simple:
$ tree -ap
.
├── [-rwxrw-r--] .clang_complete
├── [-rwxrw-r--] makefile
└── [drwxrw-r--] src
└── [-rwxrw-r--] FlightControl.c
1 directory, 3 files
I tried creating the .clang_complete file inside the project folder, that contains the following:
-I/.../Libraries/xpSDK/CHeaders/XPLM
I double checked the path to the XPLM headers, and it is correct.
Any ideas whats wrong?
During completion libclang tries to do its best by ignoring errors to present a user with the longest list of matches. I guess that you don't have XPLM_API macro defined. As it is used to declare every function in headers, you won't see any functions in completion list. Looking at defines in XPLMDefs.h I think that libclang gets Platform not defined! error (maybe even several times).
It should work if you define your platform for completion, I did this by adding -DLIN to .clang_complete file and completion works now.
So it doesn't seem to be an issue of vim or clang_complete, though it'd be nice to have a warning in such case.
I'm an autotools beginner, and I can't seem to figure out how to use an external library correctly with autotools.
Here is my directory hierarchy.
.
├── configure.ac
├── Makefile.am
├── README
└── src
(source files)
└── Makefile.am
The library's name is acml_mp and is, by default, installed in /opt/acml5.3.1/gfortran64/lib. There is also a directory called /opt/acml5.3.1/gfortran64/include to include. When I compile without autotools, including the usual compiler flags works fine:
g++ ... -L/opt/acml5.3.1/gfortran64_mp/lib -I/opt/acml5.3.1/gfortran64_mp/include -lacml_mp ...
In configure.ac, I put the command AC_LIB_LINKFLAGS([acml_mp]) which I think only deals with the -lacml_mp flag.
Basically, the end goal is to have autoconf search for this library, and have the makefile generated by automake include the correct link/include paths when compiling. Finally, when compiling by hand, I always need to modify the environment variable LD_LIBRARY_PATH using the command
Export LD_LIBRARY_PATH=/opt/acml5.3.1/gfortran64_mp/lib:$LD_LIBRARY_PATH
which, ideally, I would like to avoid having the user do. Apologies if this information exists already, I looked through SO and Google for a few hours to no avail.
The problem with searching is that /opt/acml5.3.1/gfortran is never going to be a standard (search) location for libraries (and headers) like /usr/lib, /usr/local/lib etc. Probably the best bet is to supply this location explicitly via --with-acml to configure.
The AC_ARG_WITH macro is described here. Assuming test "x$with_acml" != xno, you can try linking a program with AC_LINK_IFELSE.
AC_LANG_PUSH([C]) # or [Fortran]
ac_save_acml_CPPFLAGS="$CPPFLAGS" # or FCFLAGS instead of CPPFLAGS.
ac_save_acml_LIBS="$LIBS"
ac_acml_CPPFLAGS="-I${with_acml}/include"
ac_acml_LIBS="-L${with_acml}/libs -lacml_mp"
CPPFLAGS+="$ac_acml_CPPFLAGS"
LIBS+="$ac_acml_LIBS"
AC_LINK_IFELSE([AC_LANG_PROGRAM( ... some C or Fortran program ... )],,
AC_MSG_FAILURE([couldn't link with acml]))
AC_LANG_POP
# we *could* stop here... but we might need the original values later.
CPPFLAGS="$ac_save_acml_CPPFLAGS"
LIBS="$ac_save_acml_LIBS"
AC_SUBST(ACML_CPPFLAGS, $ac_acml_CPPFLAGS)
AC_SUBST(ACML_LIBFLAGS, $ac_acml_LIBS)
Assuming you've initialized libtool support with LT_INIT, you can add the acml library with $(ACML_LIBFLAGS) to your own libraries in src/Makefile.am via the LIBADD variable, or to executables with the LDADD variable. or <lib>_la_LIBADD, <prog>_LDADD respectively.
To compile sources with the $(ACML_CPPFLAGS) include path, add it to the AM_CPPFLAGS variable. Or the <prog>_CPPFLAGS variable.
It's difficult to be specific without knowing how your Makefile.am is already set up. I know it looks complicated - but it's better to get the infrastructure right the first time. I'll add to the answer if you have further questions.
I have a C project that has the following structure
Main/
Makefile.am
bin/
src/
Makefile.am
main.c
SomeLibrarySource/
SomeFuncs.c
SomeFuncs.h
The main.c contains the main function that uses functions defined in the SomeFuncs.{h/c} files.
I want to use autotools for this project. I read a couple of resources on autotools. But, I was only able to manage using autotools for a single level project where all source, object and other files reside in the same directory.
Then I got some links that talked about using autotools for deep projects like this one and then I got confused.
Right now I have two Makefile.am as follows
Makefile.am
SUBDIRS=src
src/Makefile.am
mainprgdir=../
mainprg_PROGRAMS=main
main_SOURCES=main.c
I am pretty sure that these files should not be as I have them now :P
How do I use autotools for the above project structure? (At least what should be there in those Makefile.am(s) and where should I place them.
EDIT:
One more thing! At the end I would like to have the object files created in the bin directory.
Thanks
mainprogdir=../ does not make a whole lot of sense (you don't know what it is relative to on installation). Probably intended:
# Main/Makefile.am
# .━━ target for `make install`
# |
# ↓ ↓━━ target for compilation
bin_PROGRAMS = bin/main
# ↓━━ based upon compilation target name
bin_main_SOURCES = src/main.c
There are two main approaches. If the functions in SomeLibrarySource are used only by main, then there's no need to build a separate library and you can simply specify the source files in src/Makefile.am
main_SOURCES = main.c SomeLibrarySource/SomeFuncs.c
However, if you actually want to use the functions in other code in your tree, you do not want to compile SomeFuncs.c multiple times but should use a convenience library.
# Assigning main_SOURCES is redundant
main_SOURCES = main.c
main_LDADD = SomeLibrarySource/libSomeFuncs.a
noinst_LIBRARIES = SomeLibrarySource/libSomeFuncs.a
AM_CPPFLAGS = -I$(srcdir)/SomeLibrarySource
(You'll need AC_PROG_RANLIB in configure.ac to use convenience libraries.)
If the source file is named SomeFuncs.c, automake will not need Makefile.am to specify SomeLibrarySource_libSomeFuncs_a_SOURCES, but if the name of the source code file does not match the name specified in noinst_LIBRARIES, SomeLibrarySource_libSomeFuncs_a_SOURCES should be set to the list of files used to build the library. Note that you do not need to specify main_SOURCES, since main.c is the default value if left unspecified (but it's not a bad idea to be explicit.) (In all of this, I am not comfortable use CamlCase names, but the system I'm using uses a case insensitive file system (biggest mistake apple ever made) and the examples I give here are working for me. YMMV)
You could of course do a recursive make, or build the library as a separate project and install it. (I like the final option. Libraries with useful features should exist on their own.)