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.
Related
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.
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'm trying to build the linux kernel and would like to understand a few things:
I have added a new file (b.c) to a certain directory with the intention of having the file compiled in. The Makefile has been updated accordingly. While compiling the file, an error is thrown saying that a certain header (a.h) is not found. However, other files in the same directory use a.h without any issues.
I have observed that .o.cmd file get created for all files except b.c. Is this a prerequisite for the headers to be correctly included? Does this file have any significance to the issue I'm facing?
For eg: I added 'async_infra.o' to this line in the Makefile:
uml_gre-objs := uml_gre_kern.o uml_gre_user.o async_infra.o
uml_gre_user.c includes the header that I'd like to be included in async_infra.c
Any suggestions on what's missing and how to address the issue will be appreciated.
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 am trying to use a C library in an Objective-C Xcode project.
The libraries directory structure is as follows:
-- include/
|-- config.h
|-- lib/
| |-- file1.h
| |-- file2.h
| |-- file3.h
The library's docs say to include file1.h, and file1.h includes file2.h and file3.h.
I am getting "file not found" errors for the includes of file2.h and file3.h`.
They are included by file1.h in the following manner:
#include <lib/file1.h>
#include <lib/file2.h>
I read here that these angle-brackets instruct the preprocessor to search for include files along the path specified by the INCLUDE environment variable, as opposed to searching in the same directory as the file that contains the #include.
So I added the INCLUDE environment variable in Xcode by going to Product->Edit Scheme.. and set it to /the-whole-path-to/include/ however, I am still getting the file not found errors.
The files are successfully included if I change file1.h to include them like this:
#include "file2.h"
but I'd rather not do that for every file in the library.
How can I fix this?
In version 5.0.2 of XCode, the best way to accomplish this is probably to add it to the target's "Search Paths" pane. Locating this was (for me) incredibly unintuitive. Here's how I got to it, for those as confused as I:
In the left column, click on the Project Navigator icon (looks like a folder). Then, click on the project entry. This should show a bunch of settings in the main pane. At the top of this pane, click on "Build Settings. This shows a bunch of entries... including one called Search Paths... but you can't add a search path here! This made me gnash my teeth for quite a while, until I figured out that the name of the project at the top of this pane was a pull-down; choose the target from this pull-down, and you should now be able to double click on "Header Search Paths" and perform the needed edit.
Oh, the joy of crazy GUIs.
Figured it out.
All you have to do is add the -I flag to your build setting under "Other C Flags"
So in your target's build setting search for "Other C Flags" and add -I/path-to-include/
Here's a screenshot:
Try this:
1 - select your project file in the left Xcode pane
2 - make sure your project is selected in the middle Xcode pane
3 - select "Build Settings" at the top of the middle Xcode pane
4 - be sure "All" & "Combined" are selected just beneath "Build Settings"
5 - type header in the search field just below "Build Settings"
You should see the search path fields ready for editing in the middle pane.
I solved this in Xcode 5.0.1 using the project Build Settings (as John and Ian noted above, but I cannot comment due to <50 rep).
New info:
When adding includes to User Header Search Paths, I also had to change Always Search User Paths to Yes.
When adding includes to (non-User) Header Search Paths, Always Search User Paths is not required.
Although this works, it is probably better to put it under the "Search Paths" tab instead.
Either you can use "Other C Flags" or use "HEADER_SEARCH_PATHS", to specify the include paths, to look for header for your executable.
In 2021, Xcode v. 12.4, the solution seems to be:
Project->Targets->General->"Scan All Source Files For Includes"-> set to "Yes"
This worked for me.
However, this might backfire if you have multiple versions of a specific .h file, probably not a good practice but it's possible if you have lots of sub-directories with their own mini-projects and similarly named include files.