How to get __FILE__ as absolute path on Intel C++ compiler

[jamiecook]

I've tried using the /Fc flag which works with visual studio but get a message that it isn't recognized by the intel compiler.

I'm trying to write a test which uses data from a directory relative to the cpp test file, however the executable will be deployed elsewhere so it's hard to get it relative to the exe... hence i'd like an absolute path at compile time! How else could I get a path relative to the current cpp file?

Cheers, Jamie

[Milind_Kulkarni__Int]

In VS new versions like vc9, /Fc is now deprecated. Probably, /FC & /FAsc would replace that..

In Intel compiler, /FC works perfectly. Let us know if thats what you want, and if it works in your version.

[jamiecook]

Milind, thank you for the quick reply however what you say does not appear to hold true for me. I was trying to attach the test project I created to test this... basically a main with

[cpp]int main(int argc, char* argv[])
{
    cout << "__FILE__ => " << __FILE__ << endl;
}[/cpp]

but the add files button doesn't do anything for me... I'll try again with another browser in a reply to this message.

Basically I've enabled the /FC option (both as the check box and explictly as a command line flag) and in both cases it results in output of

__FILE__ => "./FileMacro.cpp"

I'm using visual studio 2008 with SP1 and Intel C++ Compiler 11.1.071 [IA-32], if I compile with VS2008 it works as expected. Possible bug?

[jamiecook]

Add files doesn't do anything in either firefox or chrome, here is a rapidshare link to the zip file.

[Milind_Kulkarni__Int]

yes, that seems to be bug or rather lack of feature implementation, which is surprising. No option seems to make it work in Intel compiler, like /FAsc , /FC etc.

Also, since it has not been implemented this far, it may not be in future, looking at a few isolated customer cases. More surprising is that /FC is said to do just the thing in the compiler doc.

However, I will raise it as a Feature Request, to see what happens.

[Milind_Kulkarni__Int]

Also, you have a workaround here,and you can give it a try.. See if this gives you a compile-time control, and let me know .. See if this fits your case, or I will try to find a different workaround ..

Follow these STEPS:-

1. Include 1 header file in that .cpp file, which has the code content :--

[bash]#include 

int func()
{
std::cout << << __FILE__ << "n";
return 1;
}
[/bash]

2. Put that "test.h" in the same location as the .cpp file..
And include the #include "test.h" in the .cpp file ..

For eg. .cpp file is as :-- (sample code)

[bash]#include "test.h"     //  not as 

int main(int argc, char *argv[])
{
func();
return 0;
}
[/bash]

Now, compile .cpp file as :--

icl s.cpp /// no need of any /FC or /Fc

s.exe -- will give the full path of the .h file..

3. Apply some string operation on the full path got after storing in some string variable, to get the absolute path of .cpp file..

It looks a lengthy process. But, I am not totally sure what is the situation you are facing, hence could help such extent..

Do not know if some system() commands may help like in Unix, and not aware of that in Windows ..

regards

[jamiecook]

That workaround doesn't change anything... it's just moving the definition into a header file which generates exactly the same output. I don't see this as a feature request because the compiler takes the arguments (if you use /Fc it says unsupported) - but /FC doesn't say unsupported... therefore it's meant to be supported - it just hasn't been supported CORRECTLY.

Can I keep track of the issue that you've raised?

[Milind_Kulkarni__Int]

So the workaround does not help.

/Fc not supported. /FC is supported, but does not work.

I would escalate and let you know the update.

[jimdempseyatthecove]

Jamie,

According to your problem description and the reply from the Intel respondent, if you use:

#include "./foo.h"

and inside the included file use __FILE__ you receive ".\foo.h" (the path and file name used to open the current file)

If you use

#include "foo.h"

and if "foo.h" not located in "." but found in path included in environment variable INCLUDE, then inside the include file use __FILE__ you receive "\foo.h" (the path and file name used to open the current file)
or if "foo.h" located in "." you receive "foo.h" (the path and file name used to open the current file)

In all cases __FILE__ is (the path and file name used to open the current file)

One work around is to set your environment up such that the paths to where headers are located are in INCLUDE (may be local to process/makefile) and then use #include "foo.h" with foo.h not located in ".".

A second work around is to generate where "." is locate and place into a macro name, say __ROOT__, then in your error routine use

cout << __ROOT__ <<" " << __FILE__ << endl;

or however you want to use it. Such asto assembling reasonablepath and name

if((__FILE__[0] == '.') && (__FILE__[1] == '\'))
cout << __ROOT__ <<&__FILE__[1] << endl;
else
cout << __ROOT__ <<"\" << __FILE__ << endl;

Where the else clause may generate "C:\Developemt\FooBar\..\Widgets\foo.h"

Which, by the way is fully readable and correct.

Jim Dempsey

[Milind_Kulkarni__Int]

yes, the above workarounds are more practical, and have wider scope to use it for the problem.

Meanwhile just an add-on to the workarounds, if in my example, icl s.cpp -I would also serve the purpose, and then also the .h do not have to be in same location.

Or said above, use INCLUDE=%INCLUDE%; // something like this.

Meanwhile as you said before, I have escalated as defect, since the driver (internally) already accepts the option, but the front-interface does not give the correct result.
thanks to bring to notice about this option not working..

[jimdempseyatthecove]

In VS, right-click on project in solution explorer (usualy left pane)

Properties | [+] C++ | Preprocessor

Click in Preprocessor Definitions
Then Edit
Add "__HOME__="
Click on Macros
highlight $(ProjectDir)
click on Insert
Click on OK

If you are using MAKE files you may have to do a bit of hoop jumping to add "/D__HOME__=$($@D)"
The above will depend on your version of nmake

On Linux I think there is an auto generated environment variable holding the current directory.

[aazue]

Hi

about:

Add files doesn't do anything in either firefox or chrome, here is

a rapidshare link to the zip file.

I have make test Gecko and and Google-chrome attachment file

not problem Intel site, It work perfectly without problem.

Regards

[Milind_Kulkarni__Int]

Came acrosssome functions in stdlib.h, which gives full path-names from relative names. and does not depend on header file processing..

though not sure if they will serve all purpose required here. Anyone, let me know if they help, as I am new to them, and not tried it many possible ways..

[bash]#include 
#include 
using namespace std;

int main(int argc, char* argv[])
{

char absolutePath[_MAX_PATH];
_fullpath( absolutePath, "t.cpp", _MAX_PATH );

cout << absolutePath << "n";

return 1;
}[/bash]

Also, _getcwd(...) , current-working-directory etc. Moreabout them in msdn :--

http://msdn.microsoft.com/en-us/library/sf98bd4y(v=VS.71).aspx
http://msdn.microsoft.com/en-us/library/506720ff(VS.71).aspx

[jamiecook]

Jim,

Regarding the __HOME__ proposal, I had this idea myself but gave it up after I actually tried it and ran into the problems of passing a string full of back slashes through the preprocessor. My best efforts got me this far :http://stackoverflow.com/questions/3682773/pass-an-absolute-path-as-preprocessor-directive-on-compiler-command-line

I can also confirm that I can get __FILE__ to generate an absolute path if it is in a header file which has been included via one of the "Additional Include Directories" which must be an absolute path. ie if test.h is in a directory called "test_include" then the include must be specified to the compiler as "$(InputDir)/test_include". Normally I would use the relative path "test_include" which will compile and build but will not generate the correct (absolute) output for __FILE__

Jamie

[jamiecook]

Milind,

I think this is the approach I will use, thank you for digging this out for me.

I prefer this to relying on a quirk of the pre-processor.

Can you provide a link to the bug-report that you filed? I would like to keep track of the issue.

Regards,

Jamie

[Milind_Kulkarni__Int]

I would update you when it gets fixed/released..

The Reference number for this bug is DPD200160225, which you too can note for future references, or to check the status from us.
thanks..

[Milind_Kulkarni__Int]

yes, the solution in the link you provided also did not work out for me.. It ousts the back-slashes, and also I had much struggle to try with Stringizing # operators in the preprocessor, and came to conclude that they too did not help. Also, Preprocessor defines in the IDE did not help (backslash gone). I hope there should be some way to have it done with /D & IDE Macros, but beyond my capability..

Lastly, I tried to specify HOME_DIR=__FILE__ (without any double-quotes , etc) in the Preprocessor defines in the C/C++ Prop.

For Visual Studio as natural, it gives full-pathname, while for Intel Compiler (surprisingly instead of just the file-name), it gives the relative path-name of the .cpp w.r.t the .exe .

Smthng like:-- ../../../../

Please let me know whether the result is the same for you with Intel Compiler, so HOME_DIR=__FILE__ serves atleast half-purpose than including it in the .cpp file

[Milind_Kulkarni__Int]

Specify HOME_DIR=__FILE__ in the preprocessor define (C/C++ Prop page), and just type this small test:--

[bash]#include 
#include 

int main()
{
	std::cout << HOME_DIR << "n";
	_getch();
return 1;
}[/bash]

Let me know if it helps too..

[Milind_Kulkarni__Int]

oh. thats trivial case and won't help.. I came to know why that is happening with Intel compiler. If you see the Build logs of IDE, the .cpp gets compiled as ../../../../ , and not as , and hence __FILE__ macro expands to the relative path-name that is mentioned in the build-line.

Even using cout << __FILE__ instead of HOME_DIR in the code will give the relative path in IDE..

[jimdempseyatthecove]

Milind,

The problem with _fullpath is the executable has to be run on the development system .AND. run in the "current directory" as-when compiled .NOT. as when run.

For the developer that can work this out for testing purposed, it would be much easier to wire the __HOME__ pathinto the project/solution or make file.

For use on the development machine, the error diagnostic can write out argv[0], which is the fully qualified program path and name plus whatever is in __FILE__. Since this is being run on the developer's system, he/she can remove "/x64/Debug/program.exe" or "/x64/Release/program.exe" or "/Debug/program.exe" or "/Release/program.exe", ... to programmatically locate the __HOME__ directory. The work out the relative paths.

For use on customer's system, the execuitable can contain a text string containing the original __HOME__ $(ProjectDIR) for the project and then the error message canfixup the __FILE__ to produce a meaningful diagnostic message to beemailedback to thesupport center.

Jim Dempsey