For example there is the following structure of a project fragment:
directory1
file1.inc
directory2
file.php
How in gulp-preprocess to write <-- #include ??? --> instruction in the file.php, to include file.inc?
Related
Let's assume we have two directories dirA and dirB which contains 50 files each.
dirA - header_1.hh header_2.hh header_3.hh ---- header_50.hh
dirB - header_1.hh header_2.hh header_3.hh ----- header_50.hh
In my main.cc file, I want to include header_<1-40>.hh files from dirA, and remaining header_<41-50>.hh from dirB.
In Makefile, I have include path as:
INCL_PATH += -I/dirA
INCL_PATH += -I/dirB
How can I exclude 41-50 header files from getting included from path A?
You can't change the include path in the middle of a compilation unit -- there's no preprocessor directive to do that. You best bet is probably to include the directories in the #include directives in the file:
#include <dirA/header_1.hh>
:
#include <dirA/header_40.hh>
#include <dirB/header_41.hh>
:
#include <dirB/header_50.hh>
Then just have your -I option specify the parent of dirA/dirB
I'm attempting to build some code using a temporary version of an include file in my local ../include/records directory. The orignal lives in /home/apps/include/records. I have my gcc command set to search ../include before /home/apps/include, but it's still picking up the original module from /home/apps/include and reporting errors. If I rename the original in /home/apps/include, then gcc picks up my local edited copy and it compiles clean. So, what's up with the include order...? This 'local include first' logic has always worked for me in the past, but this may be the first time I've used it since migrating from AIX to Linux.
Is there something beyond the order of the -I command-line options that could be overriding the requested include order?
The source module include statment is:
#include "records/novarec.h"
and the gcc command line looks like this:
$make
gcc -DLINUX64 -c -g -I. -I../include -I/home/apps/include -I/home/apps/include/em -I/home/apps/include/odbc -Wno-implicit-function-declaration -Wno-implicit-int -Wno-format-security -Wno-format-truncation -Wno-discarded-qualifiers novaget.c
The compiler complains about an undefined value that's in my local copy of novarec.h, but not in the production /home/apps/include/records/novarec.h:
novaget.c: In function ‘calcComscoreDemoV1’:
novaget.c:2651:15: error: ‘CSCD_W21_49’ undeclared (first use in this function); did you mean ‘CSCD_W25_49’?
fval = *(dm+CSCD_W21_49);
^~~~~~~~~~~
It seems like the answer is this:
My module called in 2 include files. The first one also includes the second one - and the first one lives in /home/apps/include. That seems to make gcc search there for the second include file - even though /home/apps/include is not the first include directory in my path.
When I reverse the 2 include statements in my .c file, the correct path is followed for novarec.h. i.e. when I code:
#include "spottvdemos.h" (this modules has a #include "records/novarec.h")
#include "records/novarec.h"
novarec.h gets picked up from /home/apps/include, but when I code:
#include "records/novarec.h"
#include "spottvdemos.h"
novarec gets picked up from ../include, which is what I wanted.
When a file contains an include line like this:
#include "name.h"
gcc (and other C compilers) search for the file "name.h" in the directory containing the file being compiled. This does not by default happen if the line looks like this:
#include <name.h>
Is there an option to gcc to make it behave this way in the latter case too? As noted in the gcc documentation, "-I. searches the compiler's current working directory for header files. That may or may not be the same as the directory containing the current file." In the case I am working on (importing external code that used a build environment that automatically added the containing directory to the search path into a system that doesn't have such a build facility), the current directory is unfortunately not the same. What can I do? I'd rather not have to specifically modify the files...
I am confused about makefiles searching the include paths.
Lets say I have a file structure:
.
├── hdrMainFolder.h
├── headers
│ └── hdrDifferentPath.h
├── makefile
├── sourceCode.cpp
└── src
├── hdrSamePath.h
└── src1.cpp
I use -I option in the makefile to indicate the paths of the included headers.
Here are the included headers from src1.cpp
#include "hdrSamePath.h"
#include "hdrMainFolder.h"
#include "hdrDifferentPath.h"
Which of the paths I should indicate explicitly in the makefile? Which of them are unnecessary? Is it enough like below?
INCLUDING = -Isrc -Iheaders
Is it necessary to indicate to the path of a header, if it is only included by a source file under the same path?
Which of the paths I should indicate explicitly in the makefile?
Which of them are unnecessary?
On the command shell, the directory where compilation instruction is being run is the current directory for the compiler.
[Compilation being done using direct command by user or using makefile]
The current directory (./) is default included by compiler for header file search paths.
If you create sub-directories and place your header files in sub-directory structure, then, you need to explicitly add -I rule for each sub-directory which contains the required header files.
hdrMainFolder.h -> present in current directory, no need to add -I rule for this
hdrDifferentPath.h -> need to add -I rule (-I./headers)
hdrSamePath.h -> need to add -I rule (-I./src)
[You may omit ./ in above added -I rules, I follow for better clarity]
Is it necessary to indicate to the path of a header, if it is only
included by a source file under the same path?
Yes, source file location is not used to determine the user-defined header file search path. Need to explicitly mention it.
I'm writing library routines of which some characteristics can be tailored through #include'ing a configuration file. However, I'd like this configuration file to be optional, some default parameters being provided in the source. Here is a typical source beginning:
#include "userconf.h"
#ifndef BUFSIZE
#define BUFSIZE 100
#endif
...
where file userconf.h, if it exists, contains:
#define BUFSIZE 255
Standard compilers (gcc or others) consider a missing #include file an error (and they're right!). In this case, and only for this line, I'd like the compiler to continue without objection since default values are provided for parameters expected from the missing configuration file.
Is there a way to do this?
Note: I don't mind checking for this existence of the file from the make system (I'm using CMake) and passing a -Doption if that's easier to do (but, please, provide CMake directives for it, I'm not familiar with it and open documentation gives a hard time to grab the whole picture).
I found the answer "by accident" when including the wrong file.
You make profit of the multiple include directory search feature of the compiler (aka. -I option). You arrange your -I option list in such a way that there is a directory, preferentially at the end of the chain, containing a skeletal version of the configuration file.
For example, directory default/ contains the following userconf.h:
#define BUFSIZE 255
and the developement directory develop/ contains the live userconf.h:
#define BUFSIZE 100
Then, the source file of the original question may be compiled with
gcc source.c -Idevelop -Idefault ...
and -Idevelop may be omitted if it is part of the default searched directories.