For Unit testing purposes I mocked some cpp files in a separate directory but still using the origin header files.
In my special case the cpp files (origin and mocked) are holding the member documentation.
Sadly the cpp mocks aren't documented. I've set INCLUDE_PATH to the origin of the h-files (where are the origin cpp files are located as well).
In the mocked cpp files I used #ingroup/#addtogroup to proper arrange them inside the modules section.
Related
When I develop a project that output is a shared library or executable, normally, I will use include_directories in the CMakeLists.txt of root directory. In such case, before I include a header within a translate unit, I can't use angle brackets to let headers include each other. I think it is because files in include_directories is not a part of project. I can fix this by using relative path, but when I have to import external project, this can not fixed easily.
Assume that I have a external project with a root CMakeLists.txt, which has this snippet
add_library(mylib INTERFACE)
target_include_directories(mylib INTERFACE .)
and the directory seems like this
└──external
├───mylib.hpp
└───CMakeLists.txt
I want to import this project, and I'm writing a header-only project. The file tree seems like this
├──external (above)
├──include
| ├──header.hpp
| └──CMakeLists.txt
└──CMakeLists.txt
The CMakeLists.txt in root directory is simply add_subdirectory(include), and here is the CMakeLists.txt in folder include
add_library(Header INTERFACE)
target_include_directories(Header INTERFACE .)
target_link_libraries(Header INTERFACE mylib)
Theoretically, I can now include mylib.hpp by #include <mylib.hpp>, but it is not the case. VSCode tells me it can't find this header file. As much as I know, the only way to solve this is add a translate unit and let the implementation code include the header.hpp. I have tested this several time. VSCode won't report this error as long as I add a cpp file and include that header, and once I remove the cpp file, the error appears again.
By the way, I have set "C_Cpp.default.configurationProvider": "ms-vscode.cmake-tools" in configuration file of vscode.
Please tell me how to fix this without a translate unit.
I have some C++ code that I need to compile using Adacore GNAT Programming Studio.
One file (SomeHeader.h) is in a Common directory (../../Common/) relative to my GPR file.
Our convention for C++ include directives is to use
#include "Common/SomeHeader.h"
No matter what I do, I cannot get GprBuild to find "Common/SomeHeader.h"
I followed the instructions here at AdaGem 108 with modifications for C++
for Include_Switches ("c++") use ("-I ../../");
and
for Include_Path ("c++") use "../..";
None of this seems to work for me during gprbuild and frustratingly I can't seem to get at the backend command that gprbuild is using even after turning the build verbosity up.
I see some temp files in the build messages but they get deleted before I can access them.
I am using Adacore GPS 17.1 on Windows 10 i686-pc-mingw32, GNAT Pro 17.1.
Does anyone know how to get include search paths working in Adacore's Gprbuild?
If you want to use relative paths, and you are dead set on using the -I flag, be aware that the current directory at the time you compile your c++ code it is set to the obj directory configured for grp.
So if the directory you want to include is located at C:\Foo\Bar\src\include\ and your grp obj directory is at C:\Foo\Bar\env\gpr\obj then your relative path will need to use -I..\..\..\src\include
I haven't tried to use gprbuild for compiling C++ source text yet, but I suppose it works more or less like with Ada, where you add the relevant directories to the Source_Dirs attribute:
project Cookie is
for Languages use ("C++");
for Source_Dirs use (".",
"../..");
[...]
end Cookie;
I'm using ccache with git-worktree. So many of the same files are shared across multiple directories. Problem is that ccache doesn't check if the file is the same, and is compiled again. Is there a ccache option that would allow it to check the cache across multiple source directories?
ccache (by default since version 3.3) adds the current working directory to the hash if -g is used, which only makes it possible to get cache hits within the same source directory. Another similar issue is if you use absolute paths in compiler arguments, then you need to use the base_dir configuration setting.
More details from the "Compiling in different directories" section in the ccache manual:
If you build with -g (or similar) to add debug information to the object file, you must either:
use the -fdebug-prefix-map=old=new option for relocating debug info to a common prefix (e.g. -fdebug-prefix-map=$PWD=.); or
set hash_dir = false.
If you use absolute paths anywhere on the command line (e.g. the source code file path or an argument to compiler options like -I and -MF), you must to set base_dir to an absolute path to a “base directory”. ccache will then rewrite absolute paths under that directory to relative before computing the hash.
I'm trying to compile C shared library from Matlab. My Matlab code uses a lot of the image processing functionality. So, compiling goes fine, but when I call the dll from my application, I get messages like:
"Undefined function or method 'XYZ' for input arguments of type double".
I have verified my arguments are ok -- it's not a type problem. So, I tried adding %#function XYZ to my .m file, but that didn't help anything. Then, I tried using the -a flag in my compile command:
eval(['mcc -v -N -W lib:cshared -d ' clibdir ' -T link:lib -a edge' allFiles]);
but it fails to compile with:
Depfun error: 'Unable to locate edge as a function on the MATLAB path'
I have verified the image processing files are on my computer (I can run everything from matlab with no problem) and my path points to the directory that contains them.
I've also tried copying the toolbox .m files into my working directory, but that quickly balloons into a lot of files. And, for some functions, there is no .m - just a .mex - and i haven't found a way to include a mex file into my .dll.
What am I missing?
Have you tried including the Image Processing Toolbox folder using the -a option? For example:
mcc ... -a C:\Program Files\MATLAB\R2009a\toolbox\images\images
According to the mcc documentation, all files in this folder, as well as all files in any subfolders, are added to the CTF archive, and the folder subtree is preserved in the CTF archive.
If you don't want to include every subfolder, you can load only the files in a folder using a wildcard pattern:
mcc ... -a C:\Program Files\MATLAB\R2009a\toolbox\images\images\*
This may be necessary if there is a subfolder that may have functions or scripts that could shadow ones in the parent folder. For example, there is an edge.m function in the parent folder C:\Program Files\MATLAB\R2009a\toolbox\images\images\, and there is a ja subfolder that contains Japanese language help files (on Windows), one of which is also called edge.m. You wouldn't want this subfolder to be added when compiling, so you could either:
Remove that subfolder temporarily, add the parent folder without the wildcard option (to add the other subfolders you do want), then put that folder back.
Add the parent folder with the wildcard option (to add just the files), then separately add only the subfolders you want (such as #strel and private) with an additional -a command. NOTE: I'm uncertain if adding subfolders separately will maintain the folder subtree of the parent directory in the CTF archive in the same way as option #1 would!
If you don't want to include a large list of files that may not end up being used, you could instead try using the function DEPFUN to first get a list of dependencies for your MATLAB code. Then from this list you can find the specific Image Processing Toolbox functions your code uses and include only those when compiling. Since you specifically asked, this newsgroup thread mentions how to include a .mex file:
mcc ... -a imreconstructmex.mexw32 %# For a 32-bit Windows mex file
NOTE: There is also a MathWorks bug report I came across (which you need a login to see) that mentions a problem compiling applications using some Image Processing Toolbox functions on Windows in R2009b. There is a workaround given at the above link. This bug is fixed as of R2010a.
For instance I set the source code path as c:\code\testapp\src. Is this then available as a var I can use - for instance so I can spit out a tag file in a location relative to this, not relative to the working dir of doxygen? I think I'm looking for something like how Ant defines vars for just about everything and these can be re-used; does Doxygen have special vars for any of the config values?
I'm thinking like $PROJECT-NAME or %VERSION% or whatever...
You can use environment variables in the configuration file; the syntax is the same as in a makefile, i.e. $(VAR_NAME)
I am not sure, but I have seen people use variables as part of their build process. For example the lemon graph library uses cmake, sets a variable for the absolute file path in cmake and the doxygen config file includes variables such as #abs_top_srcdir#. Through the build process these variables are replaced with the relevant text.