I am using IAR Embedded workbench 5.51 for MSP430. I am using C99.
I am trying include code from a third party library. I have copied the directory structure of this third party library exactly within a sub-directory in my main project directory. However, when I try to compile I get a bunch of
Fatal Error[Pe1696]: cannot open source file "ThirdPartyLib/Subdir/file.h"
However in the log IAR shows:
searched: "C:\ ... bla bla bla ... \Source\ThirdPartyLib\Subdir\"
The include statements in each of the source files in this library are all like:
#include "ThirdPartyLib/Subdir/someheader.h"
I have attempted to add the path to the C preprocessor by going to:
Project -> Options -> C/C++ Compiler -> Preprocessor
and adding the lines:
$PROJ_DIR$\ThirdPartyLib\
$PROJ_DIR$\ThirdPartyLib\Subdir\
$PROJ_DIR$\ThirdPartyLib\Utils\
I do not have "Multi-file Compilation" checked.
All of the source files in question have been added to the project. I have created groups to mimic the directory structure of the library.
The problem goes away if I change the paths from absolute paths to relative paths such as
#include "somelocalheader.h"
#include "../Utils/someotherheader.h"
But I am dealing with a large number of files and want to modify them as little as possible.
I have never had an issue with this before - does anyone have any idea why this would happen. Is there a simple fix for this so I do not have to scrub every include statement in every c file?
This is essentially what my directory tree looks like:
Source
Debug
Exe
Output.d43
List
blabla.map
Obj
...
Release
...
settings
...
ThirdPartyLib
Subdir
... Third Party Code Files Live Here ...
Utils
... More Third Party Code Files Live Here ...
... My Code Lives Here, Along with the EWP, EWW, etc ...
EDIT #2:
I moved the directory of ThirdPartyLib up a level, because I run doxygen recursively on /Source/ and I realized that it takes doxygen FOREVER, and plus the library has its own API.
Anyway, here is what the structure looks like now:
Working Copy
Source
Debug
Exe
Output.d43
List
blabla.map
Obj
...
Release
...
settings
...
... My Code Lives Here, Along with the EWP, EWW, etc ...
ThirdPartyLib
Subdir
... Third Party Code Files Live Here ...
Utils
... More Third Party Code Files Live Here ...
I have added a group back to my project for ThirdPartyLib with two subgroups SubDir and Utils, and added all of the files from the Subdir and Utils directories to the corresponding subgroups.
Now I have tried to compile this again, and again i am faced with the Pe1696 errors. IAR says:
searched: "C:\...\Working Copy\ThirdPartyLib\SubDir"
Yet it is still not finding the files.
I referred to this post:
http://e2e.ti.com/support/low_power_rf/f/155/t/110195.aspx
I am not sure it is completely relevant, because the directories I am including don't seem to have 'fallen out'. IAR is clearly searching for the files.
But I tried anyway to add the following lines to the preprocessor
$PROJ_DIR$\..\ThirdPartyLib\SubDir
$PROJ_DIR$\..\ThirdPartyLib\utils
This does not seem to help. I get these additional lines in the message log:
searched: "C:\...\Working Copy\Source\..\ThirdPartyLib\SubDir\"
searched: "C:\...\Working Copy\Source\..\ThirdPartyLib\Utils\"
Edit #3
I tried moving the EWW/EWP up a level to "Working Copy" and then readded all of the groups and all of the files... no dice. I am lost here. The part that is most frustrating is that the same library is implemented in another project that was done by some former developers and I am trying to include it the same way. I know this is going to be something trivial, I just don't know what.
If all of the #include references inside the library are of the form #include "ThirdPartyLib/Subdir/file.h", then the root directory where ThirdPartyLib is located should be in the preprocessor include path.
If your directory structure is:
C:\My Project\Source
\ThirdPartyLib
then C:\My Project would be expected to be in the preprocessor include path.
When the compiler searches for include files it will join in turn, each of the include search paths with the path listed in the #include directive until a matching file is found.
Related
I'm trying to copy a couple of libraries I created to my local sketch folder, as instructed in the Arduino Library Tutorial
My folder structure is the following
Documents\Arduino\MySketch\
MySketch.ino
libraries\
Timer\
Timer.h
Timer.cpp
I get the following error
fatal error: Timer.h: No such file or directory
#include <Timer.h>
Note that this works just fine if I move my libraries to the C:\Program Files (x86)\Arduino\libraries folder, but I really don't want to keep them appart from my source since I can not check them to my git repository.
I think I'm following the instructions given in the tutorial precisely. I just googled about this and found several similar problems, but no solution. It's supposed to be working in recent versions of the IDE (I'm on 1.8.5 on Windows 10).
I also tried to include the libraries using double quotes instead of angle brackets but I got the same error.
Can you please let me know how to fix this problem?
Thanks
Recent versions of the Arduino IDE do recursive compilation of the src subfolder of the sketch folder. So to achieve your goal, you will want a folder structure that looks something like this:
MySketch
|_MySketch.ino
|_src
|_Timer
|_Timer.h
|_Timer.cpp
Then the #include directive in the sketch should look like this:
#include "src/Timer/Timer.h"
It's quite common for Arduino libraries to use incorrect syntax for their internal #include directives. For example, Timer.cpp might contain this line:
#include <Timer.h>
That doesn't cause a problem when the library is installed normally but it will cause an error when you try to use the library bundled with a sketch. The solution is to edit the library to use the correct syntax:
#include "Timer.h"
It seems to me that the solution looks fine if libraries/Timer is used only by this sketch. What if you have several projects {git_repo}/sketch_{n}/sketch_{n}.ino calling the same class Timer(.h, .cpp) ?
If you want to avoid code duplication (and you do), then you may put them into {git_repo}/libraries/. You will still be able to check them out into git. However, this is painful because it requires that each time you modify one file into the library, you need to :
delete the dir C:\Program Files (x86)\Arduino\libraries\Timer
reload the ".zip" (from {git_repo}/libraries/Timer) from the Arduino IDE
Very painful.
What you could do is create a symbolic link from {git_repo}/libraries/your_library to C:\Program Files (x86)\Arduino\libraries\your_library
On Ubuntu that would be :
cd ~/Arduino/libraries/ # where Arduino stores the libs
rm -rf Timer/ # deleting your library if exists
ln -s ~/dev/code/[MY_PROJECT]/libraries/Utils/Timer Timer
The Arduino IDE will know your library exists, and would recompile it automatically if Timer.{h,cpp} (from your git_repo) was modified in between.
how do I solve this
The output directory is under your source tree
warning:the output directory is under your source tree
your generated files may get interpreted as source code
consider building into a different directory instead meteor build ../output
I apologize for my ignorance on this matter, I am new in the world of programming and meteor. about my case. 1. I have a folder on Desk called “Findme” where I have the structure of my project (the code and everything which forms the application which works) 2. Then through the console I access that directory findme and then run the command meteor build/Desktop/MyApp --server = https: //findme.com, and start downloading. 3. But inside the console I also get the message indicated before and when it is finished, and I check the folder MyApp, it is empty. 4. And when I check the Findme folder it has created a folder named ~ and inside displays a file called Desktop/MyApp but it also doesn’t have any useful files, only winrar and nothing useful. 5. I am trying to generate the apk, could you please let me know what I might be doing wrong? Is there another way to generate the apk? I would appreciate it if you could help me!
Your should specify a path for where to build your application that is outside of your project directory.
Otherwise this can lead to problems with Meteor's file watcher and as your error already pointed out:
your generated files may get interpreted as source code consider
building into a different directory instead
So if your command uses a relative path, as used in meteor build ../output then it is important to call this command at the most upper project folder.
Consider the following project structure:
/myapp
/client
/import
/server
If you call meteor build ../output from within /myapp it will generate the output folder as expected outside of the project:
/output
/myapp
/client
/import
/server
However if you call it from within a subfolder, say /myapp/imports it may generate the output within the project like so:
/myapp
/client
/import
/output
/server
So keep this in mind when building your app.
Further readings:
https://guide.meteor.com/deployment.html#custom-deployment
https://docs.meteor.com/commandline.html#meteorbuild
I'm new to OCaml, but I'm trying to figure out the equivalent of __filename, __dirname from Node. That is, I need to build a path relative to the file containing the code in question.
For reference, I'm working through Ghuloum's IACC: http://ell.io/tt$ocameel
I'm building my first compiler, and I have an utterly-simplistic ‘runtime’ file (in C — temporarily) adjacent to the compiler's source-code. I need to be able to pass the path to this file, as an argument (or a pre-compiled version, I suppose) to gcc or my linker, to have it linked against my compiler's output when I invoke the linker/assembler tooling.
(This may be a stupid question — I'm at a bit of an unknown-unknown here, “how does a compiler get the runtime to the linker”, or something like that. Any commentary about idiomatic solutions to this is welcome, even if it's not a direct answer to the above question!)
If you're running the source file directly via ocaml myfile.ml, Sys.argv.(0) will give you the path to the source file and you can use Filename.dirname to get the directory from that.
If you first compile the source file into an executable and then run the executable, Sys.argv.(0) will give you the name of the executable. In that scenario it's impossible to get the location of the source code (especially if you consider that the person running the executable might not even have the source code on their system).
If you set up your project structure, so that your sources live in src/, your compiled binary in bin/ and the compiled stdlib in lib/, you could just use Filename.dirname Sys.argv.(0) ^ "../lib" as the library path for gcc. This will work whether you run ocaml src/mycompiler.ml, bin/mycompiler or just mycompiler after installing everything to /usr/ or /usr/local/.
I was given an Ada source file from a co-worker to include in an existing project. This source file wants to include the win32.ads which I see in c:\gnatpro\include\win32ada . But my installation of GnatPro doesn't look into this folder area, only the version-specific c:\gnatpro\6.2.2... I'm not sure what I need to change to force the build tools to see c:\gnatpro\include as well (if it was C/C++ I'd add -i).
Any suggestions on how to modify my build command to include c:\gnatpro\include ?
Add the environment variable ADA_INCLUDE_PATH=dir to include the folder into the build process.
I have a project with some folders which happen to contain source files with the same names.
My source tree looks like this:
project.pro
foo/
conflict.h
conflict.cpp
bar/
conflict.h
conflict.cpp
some.h
other.h
files.h
main.cpp
Per default, qmake generates a Makefile which will produce a build tree like this:
conflict.o
main.o
target
Where conflict.o is the object file resulting for both foo/conflict.cpp and foo/conflict.h.
I can't to change their names because they are generated using an external tool and forcing different file names would imply to change their contents, so this is not an option.
I also don't want to use qmake SUBDIRS template because this would imply that (1) every subdir is built separately as a library and thus very much complicate the overall build process (in my eyes at least) and (2) in the top level directory I can't have any source files. Or am I wrong?
Can't I just tell qmake to write the object files into separate directories within the build directory? So my build tree will look like this:
foo/
conflict.o
bar/
conflict.o
main.o
target
Or are there any other solutions neither requiring to rename the source files nor introducing something complicated like static libraries? I just can't believe that Qt didn't solve this (in my eyes simple) problem for years. (I already hat this problem 4 years ago but could rename the files in that project, while here I can't.)
If it's important: I use Qt 4.8 on both Ubuntu with G++ and Windows with mingw32.
Are you tied to qmake? If not, an alternative could be to use cmake. I just verified your usecase with a simple CMakeLists.txt like
cmake_minimum_required (VERSION 2.6)
project (conflict)
add_executable(conflict foo/conflict.cpp bar/conflict.cpp main.cpp)
which even included a source file in the top level directory (main.cpp). This properly builds the executable - the object files are created in sub directories like
./CMakeFiles/conflict.dir/main.cpp.o
./CMakeFiles/conflict.dir/bar/conflict.cpp.o
./CMakeFiles/conflict.dir/foo/conflict.cpp.o
cmake also includes support for Qt4, to automatically pull in the required include paths and libraries. It might require some effort to migrate from qmake to cmake, but given the requirements you have I would give it a try.