I have the following project layout in Code::Blocks 13.12. I'm running as root.
Notice the file dtconfig.h is in the Headers folder.
The file is located in the same directory as the main.cpp file:
However, when I go to build I get the following error:
When I wrap the include in quotes, such as:
#include "dtconfig.h"
It works, but then I have to modify all the other headers to do the same thing. These headers are not something I have written and are part of a source project. So I don't want to go messing around with these files if I don't have to.
Is there anything I need to do/configure in the program to get this to work?
Also, I am running Ubuntu 16.04.1 LTS Mate.
You're not meant to use angle brackets (<dtconfig.h>) for your own project's code, but if you need to make them work without changing every file, then you can pass an option to the compiler telling it to use your dtSearch directory as an include directory.
I don't know whether C::B supports include directories in the GUI, but you can always fall back to passing -Ipath/to/dtSearch to GCC and Clang directly, or /I for MSVC. You can do this where C::B lets you specify additional command line options for the compiler.
Related
I'm currently Studying Computer enginering and taking embeded systems class, My isuse is that we use a custom library then compile it in a old version of Codewarrior.
how I would go about creating an include path for my lsp with nvim
I was woundering how I would go about creating an include path for my lsp with nvim, when I am not compiling the code localy but later compiling it with an old IDE
any wisdom would be apreciated.
note: in class we are required to use an exterior editor and the older version of code warrior is verry bad it is used for compiling for our micro controler but is unusable for writting code.
things I have done
I have atempted using compile_commands.json by coppying my vscode config for path location
I have tryed using a .clangd file with -I ...
I have tried other method but had no sucess so far
over all I was hopping to find a solution and have poured over the getting started page and stack overflow for several hours trying diffrent method to no avail.
The easiest approach is probably to use a .clangd file. Based on the path in your comment, the .clangd file should look like this:
CompileFlags:
Add: -I/home/bjc1269/Documents/github/libraries/lib/hc12c/include
A few things that I'm seeing in the .clangd file in your comment that don't work are:
Variable substitutions like ${workspaceFolder}. This is a VSCode feature that works in some VSCode settings like "clangd.arguments", but is not supported in a .clangd file, which is editor-agnostic (for example, it works with editors that don't have a concept of a "workspace").
Referring to your home directory as ~. Expanding ~ to /home/<username> is a feature of your shell. Command-line arguments specified in .clangd are passed directly to the compiler without being processed by the shell, so ~ will not work.
Globs like **. To be honest, I'm not even sure what the intended semantics for this could be in the context of specifying include directories.
Square brackets inside the argument to -I. Square brackets may appear in a .clangd file as YAML syntax for specifying multiple values in a list, for example you might have:
CompileFlags:
Add: [-I/path/to/directory1, -I/path/to/directory2]
But if you write -I=[/path/to/directory], the brackets just get passed on verbatim to the compiler, which does not understand this syntax.
First of all: Welcome to stackoverflow! :D
I'd recommend to use bear for this. You just simply invoke it with your build-command and the clangd LSP will read the includes automatically.
Ok, n00b question. I have a cpp file. I can build and run it in the terminal. I can build and run it using clang++ in VSCode.
Then I add gtest to it. I can compile in the terminal with g++ -std=c++0x $FILENAME -lgtest -lgtest_main -pthread and then run, and the tests work.
I install the C++ TestMate extension in VSCode. Everything I see on the internet implies it should just work. But my test explorer is empty and I don't see any test indicators in the code window.
I've obviously missed something extremely basic. Please help!
Executables should be placed inside the out or build folder of your workspace. Or one can modify the testMate.cpp.test.executables config.
I'd say, never assume something will "just work".
You'll still have to read the manual and figure out what are the names of config properties. I won't provide exact examples, because even though I've only used this extension for a short time, its name, and therefore full properties path, has already changed, so any example might get obsolete quite fast.
The general idea is: this extension monitors some files/folders, when they change, it assumes those are executables created using either gtest or catch2. The extension tries to run them with standard (for those frameworks) flags to obtain a list of test suites and test cases. If it succeeds, it will parse the output and create a nice list in the side panel. Markers in the code are also dependent on the exactly same parsed output, so if you have one, you have the other as well.
From the above, you need 3 things to make this work:
Provide correct path (or a glob pattern) for finding all test executables (while ignoring all non-test executables) in the extension config. There are different ways to do this, depending on the complexity of your setup, they are all in the documentation though.
Do not modify the output of the test executable. For example, if you happen to print something to stdout/stderr before gtest implementation parses and processes its standard flags, extension will fail to parse the output of ./your_test_binary --gtest-list_tests.
If your test executable needs additional setup to run correctly (env vars, cwd), make sure, that you use the "advanced" configuration for the extension and you configure those properties accordingly.
To troubleshoot #2 and #3 you can turn on debug logging for the extension (again, in the VSCode's config json), this will cause an additional "Output" tab/category to be created, where you can see, which files were considered, which were run, what was the output, and what caused this exact file to be ignored.
This messed with me for a while, I did as Mate059 answered above and it didn't work.
Later on I found out that the reason it didn't work was because I was using a Linux terminal inside windows (enabled from the features section) and I previously had installed the G++ compiler using the linux terminal so the compiler was turning my code into a .out file, for some reason TestMate could not read .out files.
Once I compiled the C++ source file using the powershell terminal it created a .exe file which I then changed the path in the setting.json as Mate059 said and it showed up.
TL;DR
Mate059 gave a great answer, go into settings.json inside your .vscode folder and modify "testMate.cpp.test.executables": "filename.exe".
For me it also worked using the wildcard * instead of filename.exe but I do not suggest to do that as in that might mess up something with the .exe from the main cpp file and what not.
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 using Xcode (with C++) and my project layout (in the file system, not in Xcode) looks like this:
SubfolderA
-file_A_1, file_A_2
SubfolderB
-file_B_1, file_B_2
Right now I've set up this structure in Xcode via groups. And so, when I want to include file_A_2 in file_B_1, I write #include "file_A_2" in file_B_1.
Is there some way to make an inclusion look like #include "/SubfolderA/file_A_2", so that I can easily see to what directory/subfolder an included file belongs?
One way to see what's going on is to look at the Build Log and expand the line for compiling sourcefile.m. Look at the -I options being passed to the compiler.
If it's not to your liking you can add the source tree in the Build Settings > Header Search Paths to include $(ProjectDir)/srcroot and make it recursive, which saves you from adding each sub-folder individually.
In my experience this has never been necessary, however, as far as I can remember.
As far as the Xcode folders are concerned, if the top-level source folder is added then all sub-folders are automatically added when you add them to the filesystem, saving the hassle of keeping them in sync. You might need to add the top-level folder under the Source Files group for this to work, however.
Surprisingly, in Xcode's Build Settings I've added to User Header Search Paths non-recursive path to my project. This solved my problem.
I ended up here when I was having an issue with XCode while trying to include a header in a group by doing
#include "MyGroup/MyHeader.h"
Turns out the project structure and the file system weren't in sync, so I just had to remove my group from the project, put it in the correct place in Finder, then drag and drop it back into the project in the correct place and it worked for me.
I'm not sure if this is necessary or not, but I also have already set up my app's working directory because I am doing some game programming and need to be able to load in .png and make textures.
Very recently, I had this idea to start using Mozilla NSS and to learn to use it, so that somewhere in the future, i can use it, or can atleast start contributing to it.
So i went to its Website and cloned it source code into a director "NSS" using mercurial
Then I used
make nss_build_all
instead of
gmake nss_build_all
Note : I don't know, if it makes a difference, gmake is just GNU Make
This make command created a dist folder outside the nss folder. So, Now my NSS folder has 3 folders nss,nspr,dist.
In .bashrc i added a line at the end
export LD_LIBRARY_PATH=/home/ayusun/workspace/NSS/dist/Linux3.5_x86_glibc_PTH_DBG.OBJ/lib
Then i went over to this Sample code, did a copy paste and saved it in my NSS Folder.
And then i tried to compile it, but it failed, stating it couldn't find iostream.h, I went over and changed the location of header files
So
<iostream.h> became <iostream>
"pk11pub.h" became "nss/lib/pk11wrap/pk11pub.h"
"keyhi.h" became "nss/lib/cryptohi/keyhi.h"
"nss.h" became "nss/lib/nss/nss.h"
I tried compiling again but this time error came, that it couldn't find "planera.h"
which is actually present in dist/*.OBJ/include/ which is a link to a file planeras.h in nspr
And so i don't know, how to include these files anymore.
I always have trouble when it comes to include 3rd party header files.
Thanks
This is an old question, but I'll answer it anyway for future reference.
The simplest way is just to use the NSS package for your operating system.
Then you can use things like nss-config --cflags, nss-config --libs, nspr-config --cflags and nspr-config --libs and add that to your CFLAGS and LDFLAGS as appropriate.
For those who do decide to compile their own NSS, I'll give the quick overview.
The NSS headers are in dist/public. Add -I/path/to/dist/public to your compiler command line. The NSPR headers are in dist/Debug/include¹ so add -I/path/to/dist/Debug/include to your comiler command line.
Now you can use #include <nspr/prio.h> and #include <nss/nss.h> and friends.
The NSS code relies on directly uncluding the NSPR headers, so you'll need to add -I/path/to/dist/Debug/include/nspr for it to find things like plarena.h. Or you could do the same and not prefix your includes like I did above. It's up to you.
Now add -L/path/to/dist/Debug/lib and -lnss3 -lnspr4 to your linker command line. You may want to also add -rpath /path/to/dist/Debug/lib for the runtime link path, or copy them to a system directory or use LD_LIBRARY_PATH.
I hope this gets you started.
¹ This actually depends on your operating system and build type. I hope you can figure out the name of the actual Debug directory in your case.