I am trying to use a resource file (*.rc) in a command line compiled application, using a make file. I discovered that even though the current directory was the output directory, and that cl seems to be building its object files to this output directory, that the rc compiler will only put its output .res file in the same location as the .rc file. How can I, with some flexibility, tell rc to put its output file in a different location without a manual 'move' operation?
i.e.:
This will put source.obj file in the (current) c:\foo\bar\ directory:
c:\foo\bar>cl c:\foo\src\source.cpp
Whereas this will put a .res file in the c:\foo\res\ directory:
c:\foo\bar>rc c:\foo\res\resource.rc
The main problem is it is awkward to find a way to have the make file script do the post-compile move of the res file. Is there a way to change the output folder?
Probably an answer to your question:
MSDN specs for RC
This is the NMAKE line I have for resource compiler:
$(RC) -fo$# $**
It puts the resource file where I direct it.
It seems, however, that the directory has to exist beforehand, or RC throws its hands up in the air in dismay. Maybe I've misunderstood this problem, but I'm right about that, it's pretty lame behavior. And in that case, depending on the order of execution, you may need a MKDIR command in your makefile.
Related
Suppose that I add a program to path that is dependent on a file name "test.in". I programmed this in C++ so I used ifstream fin("test.in") without specifying the directory. Now if I were to run this program from a different directory, would the program be able to access the file "test.in"?
Firstly, this has nothing to do with the file extension, which is merely a convention given as part of the filename.
Secondly, you were always using a relative path. Even when you were running your program "from the same directory" as test.in, you were reliant on the "working directory" of your shell context being the same as the directory in which the executable and the file reside.
This is not always the case.
For example:
~/myProject:# ls
test.in
program
~/myProject:# ./program
This is okay, because your shell is at ~/myProject, and so is test.in.
However, if you'd written:
~/myProject:# cd ..
~:# ./myProject/program
…then your test.in file wouldn't be found, as it does not exist in ~. It exists in ~/myProject. It doesn't matter that the executable itself is also found in ~/myProject.
This is actually desirable behaviour, as it allows flexibility from the shell. Ideally you would allow support for piping/redirecting the file to the process instead (program < test.in — now there are no assumptions baked into your code at all!), but we can save that for another day.
For now, you seem to be concerned about what happens if you move the executable away. Don't worry: just use this feature!
~:# mv myProject/program .
~:# cd myProject
~/myProject:# ../myProject
Your working directory is the directory in which test.in resides, so it will be found via the relative path given in your program code.
When I run the Debug in Visual Studio for a project, fopen function works fine. It tries to open a file contained in the project and that I added in the filter "Resources".
But when I run .EXE file of my project, I get the null pointer exception: 0x000005c.
When I added the file to be in the same directory as my .EXE file, the exception disappeared.
This is the instruction I use :
fopen(&filename, "rb");
I know it is adviced to use fopen_s instead, but the file is not found anyway...
Apparently, the file is searched always in the current directory...
So, how to include the file in .EXE and make the path of the file relative to the .EXE, at a way it will be contained in the .EXE and not added to the directory where there is .EXE?
You can't include the file in the .exe. You just need to make sure that the file is in the same directory as the .exe.
If you really, really want to only use one file, you could either:
Zip the .exe and the text file together and make sure you include in a readme that the text file needs to be in the same location as the .exe
Use an array/struct/some other way of storing the contents of the file in the program itself, and reference that instead of using a file (I assume you don't care about users being able to edit this data outside of an instance of the program since you wanted it bundled with an executable, so the file is unnecessary in that case)
The reason the program only works when you put the file in the directory of the .exe is because the path to the file is defined in the program as something like .\file.txt or file.txt. When the file isn't in the same directory as the .exe, the program will try to find it, and will be unable to, which is why you get the error. It works when you debug because you have a copy of the text file in the same location as the debug .exe.
EDIT: I would also ignore the warnings about fopen_s and other variant's that append a _s to the end of a command - these are windows specific, non-standard, and in most cases, pointless. If you know this program will only be used in windows environments and you're not doing something for school where you are required to write standard code, I suggest you use the _s variants for the sake of security, but it will reduce portability of your code.
I am using gcov as my code coverage tool for my c++ project with gcc (currently 4.6.3 but soon to be 4.8) on Ubuntu 12.04 and am getting the error cannot open graph file. What does this error mean? And how do I get rid of it so that I can see my code coverage?
I've seen other solutions to this problem the most popular being to use clang (gcov: cannot open graph file) instead of gcc but I can't switch compilers, I have to use gcc so that is not a workable solution for me. Plus, the documentation on gcov says that it should work with gcc.
Another solution was to fix a configuration file (http://ubuntuforums.org/showthread.php?t=1547252) but I'm not sure what configuration file this user is speaking of so if that is my problem as well I don't know how to fix it
my .gcda and .gcno files are correctly being generated in my obj directory
beyond going into my top directory where I compile my code and doing gcov *.c I'v also tried
gcov -o directory/to/obj *.c
and
gcov -o directory/to/obj *.gcda
and
gcov -o directory/to/obj *.gcno
but none of these solutions work; i still get the cannot open graph file error.
Any help or advice would be appreciated!
The above problem is due to absence of .gcda and .gcno file in the directory where your source code present .
So my suggestion is 1st copy one .gcda and .gcno file of particular .c file in your source code where your .c resides then execute gcov filename.c.
If you get coverage ,then try to soft link all your .gcda and .gcno to source code if dont want to copy from obj directory then as u stated problem ll be solved
Let me clarify few of the things that you were doing wrong.
First: you always tried to specify *.gcda, *.gcno, *.c etc after obj directory path, which is totally wrong.
What you need to do is to specify it as "-o path/to/obj/ " (path to directory)
You can even specify path to gcda file of that particular c/c++ source file and specify path to obj directory in "-o" flag to get the report for that file.
And if you use gcovr instead of gcov for your reports then you can get all the kind of reports by specifying only the root directory (directory above src & obj) with "-r -root=ROOT" flag.
Refer to this user guide for details on gcovr.
I am new to c++ and am making a very simple program. All my program does is call a function from the main function, which reads in a text file and returns. To check that I am reading in the file correctly, I am trying to print out the strings I have read in. The print out (cout) works properly when I run from Visual Studio (f5). However, when I run the executable from command line, none of the print outs from my function show up. Only print outs directly in the main function appear. I cannot find a similar question elsewhere. Any help would be appreciated.
When you run a program from within VC++ the current directory is set to the project directory by default, but the application is by default in a different folder.
E.g. the application may be:
D:\Work\MyApp\Debug\MyApp.exe
But the project directory may be:
D:\Work\MyApp\MyApp\
When you start the program from outside of VC++ you need to take steps to make sure the current directory is correct, or that the executable and any data files it refers to are in the same folder.
The default working directory for an IDE-launched project in Visual Studio is the project folder. This is the folder where you project file resides (the .vcproj or .vcprojx file is the project file).
If the data file you are reading is in the same folder, code like this:
std::ifstream inf("datafile.txt");
will succeed because the current working folder and the folder where the data file resides are the same.
However, if you switch to where the executable was written (typically this is the project-dir/Debug or project-dir/Release folders) and run the same executable from a command-shell, the data file will not be found.
To test this is the case. Do the following:
Open a command prompt.
Switch to the project folder where your data file resides.
Run the executable with a specified path: ./Debug/YourProgram.exe, for example.
Note: you can avoid this by having the program take the data file name as an argv[] parameter. Then your program will simply use whatever file you tell it to at launch-time.
I'm in the process of upgrading a Visual C++ 6 project to Visual Studio 2010, and I've been replacing the post-compile steps of copying files to a common location with having the output file put directly in the final location. However, for the *.tlb files that are being generated, there is an option (in project properties -> MIDL -> Output) to specify the filename. When I put the full path there, it looks reasonable in the command line (says /tlb "full\path\to\filename.tlb"). However, when it actually compiles, the file doesn't get put in the right place, and the command that was executed according to the log was /tlb ".\filename.tlb"). I'm hesitant to specify the path as the output directory, because then it will output the XXX_i.c and XXX.h files into that location as well, which isn't what I want.
Is there any way to get Visual Studio to respect the setting I actually put in the option, instead of doing what it wants?
I just had this problem as well and I finally found out why. Even though this question is a bit old, since it's still open I'll post my solution...
In addition to the MIDL settings under the project properties, there's the same settings under the IDL file itself. Just right-click the IDL file -> Properties -> MIDL -> Output.
This did it for me. Seems illogical, though.
I also ran into same situation so I specified the output file as a relative path and it generated the tlb file in the correct location instead of the default location