Request - eliminate absolute paths in projects

#1 I just checked with Torque 3D 1.2 release and when you create a project using the Torque 3D Toolbox (Torque 3D.exe in Torque 3D's install directory) it will generate project files that use relative paths to the files. The only files that use absolute paths are the .user options files for IE Plugin and NP Plugin projects for debug settings. .user files should never be shared between developers anyway as they won't work from one machine to the next by design. :)

#2 I'm getting absolute paths with Torque 3D 1.2.

i.e. I just created a new project "New Project2", with the Full PhysX project template.

It does copy the Full PhysX DLL.vcxproj file, which has relative paths in the project file, but that project file is not referenced in the solution file. I opened up the New Project2 DLL.vcxproj file in a text editor before opening it in the IDE to make sure there was no replacements being done by Visual Studio 2010 for any reason, and I see the following:

Quote:
<AdditionalIncludeDirectories>../../../game/shaders;C:/Torque/Torque 3D 1.2/Engine/lib/lmng;C:/Torque/Torque 3D 1.2/Engine/lib/lpng;C:/Torque/Torque 3D 1.2/Engine/lib/ljpeg;C:/Torque/Torque 3D 1.2/Engine/lib/lungif;C:/Torque/Torque 3D 1.2/Engine/lib/zlib;C:/Torque/Torque 3D 1.2/Engine/lib/tinyxml;C:/Torque/Torque 3D 1.2/Engine/lib/opcode;C:/Torque/Torque 3D 1.2/Engine/lib/squish;C:/Torque/Torque 3D 1.2/Engine/lib/convexDecomp;C:/Torque/Torque 3D 1.2/Engine/lib/libvorbis/include;C:/Torque/Torque 3D 1.2/Engine/lib/libogg/include;C:/Torque/Torque 3D 1.2/Engine/lib/libtheora/include;../../../source;C:/Torque/Torque 3D 1.2/Engine/source/;C:/Torque/Torque 3D 1.2/Engine/lib/;C:/Torque/Torque 3D 1.2/Engine/lib/directx8;C:/Torque/Torque 3D 1.2/Engine/lib/openal/win32;C:/Torque/Torque 3D 1.2/Engine/lib/fmod/inc;C:/Torque/Torque 3D 1.2/Engine/lib/collada/include;C:/Torque/Torque 3D 1.2/Engine/lib/collada/include/1.4;C:/Torque/Torque 3D 1.2/Engine/lib/openal/win32;C:/Program Files (x86)/NVIDIA Corporation/NVIDIA PhysX SDK/v2.8.4_win/SDKs/Physics/include;C:/Program Files (x86)/NVIDIA Corporation/NVIDIA PhysX SDK/v2.8.4_win/SDKs/Foundation/include;C:/Program Files (x86)/NVIDIA Corporation/NVIDIA PhysX SDK/v2.8.4_win/SDKs/PhysXLoader/include;C:/Program Files (x86)/NVIDIA Corporation/NVIDIA PhysX SDK/v2.8.4_win/SDKs/Cooking/include;C:/Program Files (x86)/NVIDIA Corporation/NVIDIA PhysX SDK/v2.8.4_win/SDKs/NxCharacter/include;C:/Program Files (x86)/NVIDIA Corporation/NVIDIA PhysX SDK/v2.8.4_win/Tools/NxuStream2;$(DXSDK_DIR)/Include;%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>

Additionally, I now see that the source files themselves are also using absolute paths. i.e.:

Quote:
<ClCompile Include="C:\Torque\Torque 3D 1.2\Engine\source\T3D\aiClient.cpp" />

I never actually noticed that last one before, but that does explain some weird things that I went through that I thought was just me being delirious.

The PhysX directories I can understand, though I think it would also be good to use an environment variable for those. I know that NVidia doesn't supply an environment variable, but it wouldn't hurt for Torque to supply one that could be used, which could be set by the user from the Toolbox. This is actually more likely to be a problem when sharing project files, since the PhysX SDK is installed in Program Files, which is in a different default absolute location in 32- and 64-bit Windows.

#3 Hmmm, OK lets try this method. Manually run the project generator batch file by opening Windows Explorer and browse to C:\Torque\Torque 3D 1.2\My Projects\<ProjectName>\. Run generateProjects.bat by double-clicking on it. Let it run completely and then close it out when it says Press any key.

Now check to see if the paths are absolute or not, for me they're all relative except the debug arguments for the Plugins projects. Not sure if it makes a difference or not, but I'm running Windows XP SP3 (32bit) using Visual Studio 2008 Professional.

#4 I believe the PhysX paths have to be absolute since the PhysX SDK doesn't not define an environment variable by default.

#5 Yep, you're right, that does do it correctly. That makes things more convenient, as long as that is done after the creation of each new project, and before making any project changes that would get wiped out by the batch file.

#6 @Matt, yes, I mentioned that. But Torque could create it's own environment variable based on user input. i.e. when installing Torque, it could ask the user to browse to the location of the PhysX SDK if it exists and set an environment variable like TORQUE_PHYSX_DIR. Or when creating a new project and the environment variable isn't set yet.

That's what I do in another project of mine that uses PhysX and it's much more convenient. Otherwise each developer has to manually change the project files after each checkout and before each checkin, which is annoying, unless they have the SDK installed in the same absolute location.

Obviously we can manually do the environment variable ourselves and change the project files to use it, which is what I'll be doing. So it's not a high priority or anything, just something that would be nice to have.

#7 Gerald: I'm glad that fixed it for you. :)

Matt Fairfax: Sadly that is true of which I think that should be considered a design flaw in the PhysX project generator component as it should instead just use the TORQUE_PHYSX_PATH environment variable since Visual Studio has supported environment variables in paths since at least VC++ 6.

#8 If you look in the project generator directories you'll find the php scripts that Torque uses - in there is an environment variable that the generator will look for when generating a new project - if you set TORQUE_PHYSX_PATH manually in your environment variables to the correct PhysX SDK path it will pick it up.

The php include you're looking for is in Torque 3D 1.2/Tools/projectGenerator/modules - physX.inc is the file that actually looks for it.

#9 Alright I just spent the past couple of hours modifying the project generator to support VC++ environment variables literally being passed to the project generator API and updated the physX.inc module to search for and literally pass the PhysX environment variable to the project generator. Here is the zip file projectGenEnvVarsSupport1.zip (12KBytes) with the changed files you can extract over the existing projectGenerator installation. Be sure to read the ReadMe.txt file included with the zip file so you'll know what to do with the files. Also either or of these two environment variables must be declared and set to the absolute directory path of the PhysX SDK or it will fail: TORQUE_PHYSX_PATH -or- PHYSX_SDK_PATH

The end result of this modification makes it so that the two projects related to PhysX (nxCharacter and nxuStream) are now created using relative paths to the environment variable and not hard-coded absolute paths as before. So, now the last remaining projects that uses absolute paths related to the project files are the debug session arguments for the two Plugins and there's nothing that can really be done about those as they're user specific anyway (hence the .user postfix on them).

Enjoy! :)

#10 Thanks Nathan, but it doesn't quite seem to work. I have tried alternately with TORQUE_PHYSX_PATH and PHYSX_SDK_PATH environment variables set, and also with both of them set, both as system and user variables, and this is what I get for the include directories each time:

$()/SDKs/Physics/include
etc...


And the nxuStream and nxCharacter projects are empty projects with no source files.

#11 What exactly are you setting your TORQUE_PHYSX_PATH environment variable to?

#12 Ha, very strange. I was using D:\PhysX, and it was giving me the results noted above. Today after reading your question I changed it to D:/PhysX, and it worked fine. Then I changed it back to D:\PhysX and it was still working fine. Deleted the variables and tried again, and back to the original result. Added them again as D:\PhysX, and working fine again.

If I had to guess it was probably some issue with my computer (Win7 x64) where the environment variable hadn't actually propagated itself yet. Possibly because I had 9 million programs open.

Sorry for the false alarm. Great work!

#13 I second the OP's request. It's not *too* much of a pain to get a Torque install to be completely directory-portable, which I just did for my own personal repository, but it doesn't seem like something we should have to deal with.