I have a file called assert.h which defines several assertion macros. The project is called Core and lives in a folder with the same name. However, this file lives in Core/hul, which is a submodule of the project that implements some abstract utilities. Here's an excerpt of the file:
#if defined(HUL_DEBUG)
# if defined(HUL_TEST)
# define HUL_ASSERT(e) HUL_TEST_ASSERT(e)
# else
# include <assert.h>
# define HUL_ASSERT(e) assert(e)
# endif
#else
# define HUL_ASSERT(e) /* empty, do nothing */
#endif
As you can see, when HUL_TEST is defined assertion macros expand to a unit test assertion callback. That works fine. When compiling for release (e.g. HUL_DEBUG is not defined) it does nothing. Also fine. When compiling for debug (without testing), it includes the system's assert.h and defines a macro that expands to assert. Everything OK so far.
The problem is that regardless of including <hul/assert.h> or <assert.h> it's always hul/assert.h that is included, which is not what I want. This is one of the reasons that hul/assert.h is qualified under the hul folder.
The obvious first thing to check is Other C Flags and Header Search Paths. But the later is empty and the former is as follows:
-I../../include/Core
-I../../test/include/Core
-I../../test/include
As you can see, Core/hul is not included, so #include <assert.h> should not resolve to hul/assert.h. The question is, why does it? Am I missing some configuration?
Note: of course I could change the file's name, but I rather understand why this is happening. This framework will still grow immensely in number of files and I don't want to be worrying about this kind of conflicts.
set USE_HEADERMAP = NO. When set to YES, XCode uses a dictionary that maps a header file name to a path where to find in order to speed up compilation. So regardless where you place your header file, if it has found his way into this map it will be found forth on.
Another way would be to use absolute paths for all user header files, e.g. #include "./assert.h" (which should give you an error if the file is not located directly in the project directory or any manually defines user header search path).
Hope it helps;
Related
I'm creating a new project in keil to learn how to add files and headers and link them properly. I need some help in understanding the optimised way to add header files.
I've a main.h file, in that I've included FU68xx.h, adc.h and gpio.h file.
#ifndef HEADER_FILE
#define HEADER_FILE
#include <FU68xx.h>
#include "adc.h"
#include "gpio.h"
#endif
In "adc.c" and "gpio.c" file i've included only main.h file and I'm able to compile successfully. But is this the right way to do it? is adding main.h file in all the files cause multiple inclusion of header files?
If I add the main.h file under #ifndef HEADER_FILE in the "adc.c" or "gpio.c" file, i get error while compiling about undefined identifiers.
Multiple inclusion of the same header file is not a problem (and not a noticeable compile-time increase) if each header is appropriately protected with an "#ifndef" as you did.
Note that the name you used in that "#ifndef" must be unique (different in each header file), so the name "HEADER_FILE" is not very good - it would have been better to call it with a unique name, e.g., "INCLUDED_MAIN_H" (and other header files will use other names). Alternatively, all modern compilers support the "#pragma once" command which is better than ifndef in two ways:
You don't need to invent a unique name (and risk that it's not unique)
The compiler doesn't need to read the header file until the end just to look for the "#endif" - once it sees the "#pragma once" and knows this is the second time reading the same file, it immediately stops reading it.
But even though including the same header file is not a problem, including too many headers in a file that doesn't need it is a problem - it increases compilation time, and also increases incremental compilation time: If you change a header file, and a hundred other files include it, the build system (e.g., make) will need to re-compile all of these hundred other files. So usually I would recommend that each source file (.c) should include only the minimal set of header files that it really needs - rather than include some big "main.h" that includes everything.
I'm trying to include a folder that contains a combination of around 60 .h and .hpp files. This folder contains libraries for programming robots with a Wallaby (a mini-computer-like device) for Botball competition. include is located in the same place as main.c (inside code). Up until now, this is what my header for including libraries looks like:
#include "../code/include/accel.h"
Just like accel.h, I have 60 other .h and .hpp files inside include. So, coming to my question, do I need to type out all the 60 header lines? or is there a way to include the include folder.
I'm using Clion for this project, if I can't include the folder itself, does anyone know of a shortcut in Clion to include all the files in include.
I was also thinking of using some sort of placeholder for the folder name and only specify the file type. So, for example: #include "../code/include/(generic placeholder name).h". I have no clue if something like this exists.
I would also request you to keep in mind that I'm a beginner to programming, so please keep your answers simple.
This is just for some extra info:
The Wallaby is a mini computer to which you would connect your sensors, motors, servos and cameras in order to control a robot for the Botball competition. Usually, one can connect to the Wallaby either via Wifi Direct or a cable and write programs on it directly through an online interface (not entirely sure of the word for it, but you just type in an IP address in your browser and it brings up an interface where you can make projects and code). All the code written in that interface saves directly onto the Wallaby. Here the default include statement is #include <kipr/botball.h>, so I'm assuming that botball.h (which is located on the Wallaby's storage) has all those 60 libraries consolidated in it. I got the include folder that I'm using from GitHub. This link was provided to me by one of the Botball organisers. So the main point in me trying to download the library is so that I can write and successfully compile code even when I'm not connected to the Wallaby. Hope this provides some relevant context.
Thank you for your answers!
What I'd do is
Create (maybe with scripting tools or a specific program) a "all.h" file which includes all the other header files
#ifndef ALL_INCLUDED
#define ALL_INCLUDED
#include "accel.h"
#include "bccel.h"
//...
#include "zccel.h"
#endif
Include "all.h" in your main file
#include "../code/include/all.h"
You can create "all.h" automatically every time you build your code.
CLion is an IDE for Clang and GCC. These compilers are instructed to search paths for include files by specifying -I<path> command line arguments. Any number may be specified, and they are searched in the order given, and the first match found is the file that gets included.
I am not familiar with CLion specifically but no doubt it has a dialog somewhere where you can set header file search paths.
Edit: It seems that CLion may not make this so straightforward. I understand that you have to add then via CMake: https://cmake.org/cmake/help/v3.0/command/include_directories.html#command:include_directories, but after that, the IDE will not recognise the header in the editor and will warn you of unrecognised files and will not provide code comprehension features. I believe it will build nonetheless.
Say I am writing a small libary in C, with most of the source code in two folders src/A and src/B, and where the header file src/A/a.h needs to include src/B/b.h. When writing code for a non-library project, I usually write
#include "B/b.h"
in a.h and use the -Isrc flag to tell the compiler where to look for header files.
Now suppose that my library is installed locally at ~/mylib and that I want to use functions from a.h from a different project. Simply including that file using
#include "~/mylib/src/A/a.h"
would not work, because ~/mylib/src/B/b.h might not be part in the search path. My question is about the canonical way to solve this issue. It's probably quite basic, but I haven't done any advanced programming in C and have been unsuccessful in my attemps to find a solution online.
Possible solutions I thought of are the following:
Add ~/mylib to the search path, but that might lead to problems if the library and client projects have header files with the same name (say src/helpers.h). Is it possible to include one header file without cluttering the search space with files I won't need?
Use relative paths in the library header files, but that doesn't feel very robust.
Thank you.
The normal approach is to have a separate directory specifically for the headers which form the public interface of your library. Usually this directory would be called 'include'.
You would then place the public headers for your library under a library-specific directory in there, i.e. "mylib/include/mylib/b.h". This extra 'mylib' directory prevents clashes if you're using some other library that also has a "b.h". You can also, if you wish, keep other private headers, which do not form the public interface of your library, under the 'src' directory instead, to stop them being exposed to users of the library.
This means a user of the library can then use "-I mylib/include" to include this directory, and include the individual files with, for example, "#include "mylib/b.h".
Why aren't you using the standard implementation? Break out into header and source files into their own directories. Add #define headers to avoid multiple includes or namespace corruption.
Here is your directory structure:
~/mylib/headers/a.h
b.h
~/mylib/src/a.c
b.c
Now a.h will have at the very top of the file...
#ifndef __A_H__
#define __A_H__
// code
#include "~/mylib/headers/b.h"
// end of file
#endif
Now b.h will have at the very top of the file...
#ifndef __B_H__
#define __B_H__
// code
// end of file
#endif
Then just compile. gcc -I~/mylib/headers
If you have 2 helpers.h just change the #define __HELPERS_H__ in one of the files to something else like #define __HELPERS2_H__
Background:
I am putting together a test environment for an embedded project. Since it's an embedded project it tries to access hardware registers e.g. ADC results, timer settings, interrupt flags...
These registers are implemented automatically by Halcogen (it's a TI processor), as defines pointing to specific addresses.
#pragma system_include
#ifndef __REG_FLASH_H__
#define __REG_FLASH_H__
/* USER CODE BEGIN (0) */
/* USER CODE END */
#include "sys_common.h"
typedef volatile struct flashWBase
{
uint32 FRDCNTL; /* 0x0000 */
uint32 rsvd1; /* 0x0004 */
.
.
.
uint32 EESTATUS; /* 0x031C */
uint32 EEUNCERRADD; /* 0x0320 */
} flashWBASE_t;
#define flashWREG ((flashWBASE_t *)(0xFFF87000U)) //<--- This one
#endif
My attempted solution:
In order to compile and run this code on a MinGW Win7 machine these specific addresses need to be re-defined to be pointing to observable and mutable variables. I have a Python script that analyzes the source code; creating a new header file using the same name in a common directory containing:
#ifndef _COMMON_INCLUDES_REG_FLASH_H_
#define _COMMON_INCLUDES_REG_FLASH_H_
#include "..\..\W2_Library\Halcogen\Include\reg_flash.h" //<--- original Halcogen header
#undef flashWREG
flashWBASE_t _flashWREG;
#define flashWREG (&_flashWREG)
#endif
I have made many attempts using -I-, -I<dir> and -iquote to redirect inclusion of the headers getting farthest using the deprecated -I- to make GCC ignore the . directory. I would however rather have my Common folder precede the . than ignoring all together. Adding a -I. does not seem to be the same thing, I get the feeling it expands to the directory of the source code and doesn't stay "relative" as GCC delves deeper into the inclusion tree like the original . do.
Letting my Python script clone the entire header, replacing only the HW address with a variable, could be a solution. Just redefining the register defines in a separate header does however feel less prone to break.
Question:
Is there any other ways to alter the search order?
I have read several questions about -I- but none has really had any answers as to how you get around the behaviour. This question is pretty close but unlike that user, I am not using precompiled headers.
There are a few assumptions above and please correct me if they are wrong!
The problem you are having is with #include "..." as opposed to #include <...>
With a normal C compiler, using the " form always searches in the same directory as the current file, and then looks in the include path set by -I. If you want to search somewhere else before looking in the current file's directory, there's no easy way to do it.
You can use gcc's -I- to inhibit searching in the current file's directory, and add other directories to use only for " include files (not for <>), but if you use that, there's no way to get back the behavior of searching in the current file's directory.
You can try something like:
-ICommon -I. -I- -Iwhatever
This will search for " includes first in Common, then in the current working directory, then in whatever (and the rest of the normal path), while <> will start in whatever. Unfortunately, it will never search in the current file's directory, if that is different from the current working directory.
-I- is also deprecated, so may go away soon.
I am trying to use the following method to include a project header file:
#include FILE_PATH
Where FILE_PATH is defined as the file to be included.
The project compiles without errors if FILE_PATH is include as:
#define FILE_PATH "hal/micro/config.h"
#include FILE_PATH
But if FILE_PATH is pre-defined as a compiler define option inside the project options, then building the project returns the following error:
Error #13: Expected a file name
The development software being used is Code Composer Studio version 6.
What am I missing here to pre-define the header file path in a project?
Additional Details:
I am in the process of converting a working project from the IAR embedded workbench IDE to Code Composer Studio. The Pre-define NAME (--define, -D) shown in the picture below are mostly identical to how they were in the IAR project.
The pre-define name boxed in red is currently the cause of the error, but this could occur with any of the other defines with file pathnames.
I have tried the suggestion of using the #ifdef statement to at least verify that PLATFORM_HEADER is actually defined and it does seem to be defined. I also checked for typos and there doesn't appear to be any noticeable typos.
The key reason for wanting to go with the pre-defined macro approach is to avoid individually making changes to numerous files affected by this error.
I still have not yet tried a command line compile, since I need to reference the manual on how to do so, but I will try as soon as I figure it out.
#StenSoft wrote:
The IDE does not correctly escape the parameters. You should escape the quotes. You can also try placing PLATFORM_HEADER somewhere in the code and see what the compiler would tell you it sees.