I'm trying to load image with IMG_Load() function from SDL.
I saw from tutorials that they doesn't need full path for asset files.
But when I try to do that, it doesn't work.
My solution is include full path of those files, but I found that is clunky. Especially when I try to collaborate with my friend, it's hard to synchronize source files since we use different file paths.
May I ask what is typical way to collaborate between programmers when they have different setup, different file paths? I think that I need to simplify the file path for asset.
I tried to add include directories for compiler, but it only work with header files, not for asset files.
Relative paths are relative to the current working directory. On Windows, when starting a program from the exporer with a double-click, it matches the location of the .exe, but this isn't always the case, e.g. when running from some IDEs.
Use SDL_GetBasePath() to get the directory where the .exe is located. Prepend it to your asset paths.
Related
I am creating some software with C++ and Cmake that I want people to be able to effortlessly build and run. Cloning the GitHub repo will install the folder Project/, and the code in the file Project/src/navigation/camera/image.cpp compiled into and linked to multiple programs all over the Project repository. However, inside image.cpp there is a path to a file Project/Models/model.txt, and the file path is relative to Project/build/navigation/camera/image.o:
image.cpp:
int processImage() {
read_file("../../../Models/model.txt");
// Do something
}
But since the object file is linked to other programs all over the project, the path should be relative to many different locations. What is the standard "Software Engineering" technique to solve this? Do you tell Cmake the path of Project/, and somehow let it modify image.cpp before building? Or is there a way to still use relative paths?
If you are using CMake, the typical build model separates the source tree from the build tree, which means that your build folder could be anywhere relatively to the source folder. Therefore, any relative path wouldn't work reliably.
If I can't avoid having an hardcoded path in the source, my favourite solution is to pass your cpp file to the configure function of CMake to replace that relative path to an absolute path that CMake will calculate at generation time
I don't know how "standard" this approach is, but what I would expect is a requirement that Models be a subdirectory of whatever directory the executable is executed from. Usually this is wherever the executable ends up, but not necessarily. For released projects, this directory is usually (expected to be) the installation directory. There is a caveat that other functions are capable of changing the current working directory, and that would make it more difficult for your code to find model.txt. So I would also expect a requirement that the current working directory be restored before your code is run.
If you go this route, the relative path to your data file would be Models/model.txt. It would be up to each project to copy this data to the appropriate directory (or create a link from the directory to the data file). Note that each project would probably want this configuration for release anyway since you usually should not (sometimes cannot) access the parent of your install directory.
So, we have all seen (some of you guys might have even made) professional libraries which have proper include directories which contain all the header files you need to use the library. An example would be the OpenCV library include folder which I have attached.
When we release libraries, what we do is just zip the headers for the lib and ask the recipient to extract them to somewhere convenient, which is, to be honest, quite fine. However, I would like to make an 'include' directory with all relevant headers if possible because I feel that my distribution can be organized better that way. How can we go about doing that?
You can just create a folder for all neccessary headers and specify path considering that folder when include them in code.
You can also specify that folder in preferences of your project, for example Visual Studio or Eclipse allow it, so you shouldn't write full path for those includes.
As stated in this post the working directory when I debug my SDL program is relative to the .vcproj instead of the .exe (which it should be IMO)
So I'm wondering if there's anyway I can change this, so when i press F5 the path will be relative to the .exe and not .vcproj?
The current (relatively easy) workaround I'm using, is simply opening up the folder and starting program from there, but I would much rather prefer simply pressing F5.
The naive answer to your question is that you can set the Working Directory option in the Debugging configuration properties to $(TargetDir). The default setting is $(ProjectDir) and by default the project directory is not where the executable file is output. However, I do not recommend you take this option, as I explain below.
You are attempting to solve this the wrong way. Your fundamental problem is that you are assuming that the working directory is the same as directory which contains the executable file. There's no reason for that to be so, and you should not rely one it. You know that the files are in the same directory as the executable and so you should look there, rather than the working directory which is only sometimes, coincidentally, the same as the executable directory.
So, instead of relying on the invoker of the process setting up the working directory to your liking, make your program independent of the working directory. You state that you wish to work with files whose location you know relative to the executable directory. So there is the answer. Construct full paths to your files, using the directory which contains the executable as the base.
If you need to find out the location of the executable, call GetModuleFileName(), and strip off the file name. What you have left is the directory which contains your executable. Combine that with the relative path of your files and your code is now independent from the working directory.
The Xcode docs for this don't explain exactly where each of the Destination paths maps to on disc, relative to my application package.
If I use this app as an example, could someone give a canonical answer where each will put files relative to this directory structure?
The app bundle in your example is Viewer. This is not a file; it's a directory. If you click on it and "Show Package Contents", you'll see the rest of it.
Products Directory is the directory that Viewer is written to. You cannot write to this directory in iOS.
For iOS, Wrapper is the top level directory within Viewer.
For iOS, Executable is the same directory as Wrapper.
For iOS, Resources go into either the Wrapper directory, or the localization directories (Base.lproj, etc) if the resource is localized.
The other directories aren't meaningful for iOS.
Still, you should use the directories logically. Use "Executable" to mean "the directory where my executable lives." Don't assume that the directory tree is laid out a particular way internally.
Regarding your comment that you need to know the path to access the file, you do not need that (and shouldn't try). You should use [NSBundle pathForResource:ofType:] to find files.
Inside .vcproj files There is a list of all source files in your project.
How can we use a macro to specify the path to a source file?
If we do this:
<File
RelativePath="$(Lib3rdParty)\Qt\qtwinmigrate-2.5-commercial\src\qmfcapp.cpp">
</File>
The compiler cannot find the folder:
qmfcapp.cpp
c1xx : fatal error C1083: Cannot open source file: '.\$(lib3rdparty)\qt\qtwinmigrate- 2.5-commercial\src\qmfcapp.cpp': No such file or directory
As you can see, our project compiles in several source files from QT. QT lives inside a folder of external libraries, and we don't want hardcode the path from our project to that folder (we have a very large solution)
The normal solution is to include the 3rd party includes, libs and source in source control with your own source, so you can track changes to your 3rd party dependencies with your source.
If this is the case, you should be able to use a relative path from each project to the 3rd party source files.
However if your solution is big, and it has project complicated settings you should look at CMake, even if you are only building on windows. CMake enables you to describe your build environment with common settings specified in only one place. More complicated cases can be handled with variables and macros. Then it generates your visual studio projects, or makefiles from this description. We introduced it to support a unix port, and now I use it for windows only development too.
VS projects are really clunky to use, opening and closing dialog boxes, setting things for debug and release. Each project with its own copy of the settings, but mostly the same as all the other projects.
If you add an existing file from a different drive, you'll notice an absolute path is used.
At least for v8.00, macros do not seem to be expanded. I tried VC, Ant, and OS macro forms - none worked.
There's always the sysinternals' junction option, a mapped network path, or a .lib with a macro spec set into the project/global source, include, and lib paths. Even with the lib package, you should be able to step into the source.
Try setting an environment variable for 'Lib3rdParty' to the appropriate relative path snippet.
..it should be mentioned that using property sheets gets rid of a lot of the clunkyness though