Below is a small sample of the way I'm building my project. I have a list of headers and a list of source files, and pass them to add_executable. Sometimes after several incremental builds, I'm changing the header file but the build isn't doing anything. The status shows that each target is checked but no changes are seen. If I do a small modification in the CPP file, then the build is executed.
What could be the cause of this?
list (APPEND ${PROJ_NAME}_SRC_HEADERS ${CMAKE_CURRENT_SOURCE_DIR}/include/lua/lua_config.hpp)
list (APPEND ${PROJ_NAME}_SRC_FILES ${CMAKE_CURRENT_SOURCE_DIR}/source/lua/lua_config.cpp)
add_executable(${PROJ_NAME} ${${PROJ_NAME}_SRC_FILES} ${${PROJ_NAME}_SRC_HEADERS})
I'm using the 'Unix Makefiles' generator.
I see that all my projects header files are not part of the generated depend.cmake file. I guess this is the root of the problem. All the header files from the other conan packages are there, but not the ones for the top level project.
Two things are needed for the header files to be added to the depend.make file. First adding them in the list of files of the target, which I did and add the include directory using target_include_directories.
target_include_directories(${PROJ_NAME} PRIVATE
$<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/include>
)
At this point it's still not working. This is because I'm passing two lists of files that are separated using a space ' ' character. After I joined the two lists into a single one using a ';' it started working.
add_executable(${PROJ_NAME} "${${PROJ_NAME}_SRC_FILES};${${PROJ_NAME}_HEADER_FILES}")
Related
I've been asked to make a small mod to some software that was written back in the mid naughties on IAR Embedded Workbench v3.3
I have had the original source files copied from an old machine to one I have been given for the task.
For the moment I am simply trying to get the software compiling. It took me a while to realise, or at least I thought I'd realised, that the reason it couldn't open various header files was that, incredibly, all the include paths were absolute, not relative.
So, I changed all the paths to be $PROJ_DIR$ relative, but then started to get different files that couldn't be opened. Then realised that the machine they gave me just happened to have a very similar directory structure to the original machine used and, amazingly, had quite a few of the same files in the directory structure of this machine I'm using as was on the machine used to compile the code originally.
I then thought, OK, I'll just check I have got my relative paths correct by choosing one of the header files it was complaining about not finding and putting, in the Preprocessor tab, an absolute path to the directory on this machine I'm using that contained the header file it wanted. However, that still wouldn't find the header file!
Finally, I put an absolute path in the c file to point to the desired header file.
#include "C:\absolute__Path\stdtyp.h"
And it compiled.
To confirm:
Putting C:\absolute__Path
in the Project | Options | C/C++ compiler | Preprocessor tab will not work if I just have:
#include "stdtyp.h"
in the c file.
I have used IAR in the past - not that much - but I have used it and I was sure that's where you set your include directories. So, am I wrong, or can there be something else that is overriding that path in the Preprocessor tab as described above?
Edit: I'm not wrong, after having slept on it, I decided to create a new project with random directories, subdirectories and header files. Sure enough, if I set and remove $PROJ_DIR$ referenced paths in the preprocessor tab, the new project compiles, then doesn't. So, there must be something, presumably in the ewp file that is borking it.
It turns out you can override the paths on an individual file by file basis. So, the rogue files had the paths overridden and had absolute paths.
Right click on the file in EW and select Options.
That then for most file shows a load of greyed out boxes. What I'd failed to do was thoroughly check all files. The few I'd randomly checked were greyed out, but some files had their properties overridden here with different (and absolute) paths put there.
At least now the project can be easily copied between machines having used relative paths.
I'm extremely confused over how to make in c++. I'm working on a school project where we downloaded several files -- some starter code, and some libraries. File structure is something along the lines of
main --- lib/ severalLibraryFolders
\--- src/ starterCode
I cannot seem to get the starter code to make within the command line. There's a vector library within one of the library folders and when I run make on the starter file (a .cpp and .h) I get a fatal error: 'vector.h' not found. I managed to use gcc and the -I flag to include the folder that vector.h was in which fixed it -- however other similar problems popped up even after I used the -I flag on all possible library folders.
I'm fairly certain I'm doing something wrong/need a makefile but all the examples I've found are not clear on how to do what I need to do, which is essentially to find all header files below the parent directory. I'd love some direction here, as I come from a more scripty background where this sort of thing is much easier!
I'm trying to build opencv2 as a universal framework. I am systematically removing the files/folders that I do not need. But I am running into this issue where the include files are not found. See the image below:
The following image clearly shows that the file is indeed there.
One of the contractors working with us said he had put the include files into the same directory as the source files and rename them according to their file structure but using "." instead of "/" as shown below:
But that means that I must go through all of the files that include files and change the include statement to use "." instead of "/". REALLY?
Is this true? Or do we have a configuration set wrong?
You need to setup search paths for your target in Build Settings->Search Paths->Header search paths.
My C-gcc project structure is:
\Project\wscript (only one in project)
\Project\build\
\Project\Source\Module_1\foo.c
\Project\Source\Module_1\foo.h
\Project\Source\Module_1\dummy\foo2.h
\Project\Source\Module_n\bar.c
\Project\Source\Module_n\any dept...\bar.h
How can I recursively find all *.C files in 'Source' and add to
bld.program(source=HERE)?
instead of manually listing it:
bld.program(source="foo.c bar.c...", includes='..\\Source ..\\Source\Module_1')
Also how can I find every subfolders (preferably which has *.h) and append to include path?
Should I write my own finder functions in python and just pass it?
bld.program(source=SRCs_FOUND, includes=Paths_FOUND)
Will this cause any dependency problems in building?
In any modern IDE this thinking is common, drag one file to the Source tree, and it's automatically added to the build list. Thanks!
You can use globbing to scan the directories.
bld.program(
name = ...
....
source = bld.path.ant_glob('**/Source/*.C')
)
Just search for ant_glob in the waf book.
I have a lot of classes in my project which means a lot of files too. I want to put everything in subfolders so it's a grouped together and a bit more clear.
There is already a folder names scr where all my cpp and header files are in but I want to create a folder named 'products' and put all the product-related files in there.
But when I do so, I get this error (after pressing build) that one of my classes can't be build. It says:
make: * [scr/Producten/AudioKaart.o] Error 1 KassaSysteem C/C++
Problem recipe for target `scr/Producten/AudioKaart.o'
failed subdir.mk /KassaSysteem/Debug/scr/Producten line 30 C/C++
Problem
What's the right way to put files in subfolders? Do I need to change the includes? Or do something more than just dragging and dropping them into the folder?
If you put headers in your Producten directory, you need to include this directory in your project settings. Another way is to include your header by specifying the sub-directory, something like
#include "Producten/xxx.h"
Eclipse uses directories for project folders, so you need to adjust all includes as well.