I have an application, which stores a database and log files. When I install my application I want that these will be written to a place, where they belong. So perhaps (not an expert here) on Linux my database should be in /var/myApp/database.sql and my log /var/logs/myApp/myAppLog.txt. On Windows / Mac Os these paths are different I suppose.
Can CMake support me to know the right paths similar to how it knows with GNUInstallDirs, where to install my application?
I looked into GNUInstallDirs and found LOCALSTATEDIR, which looks like this could be the right variable for my database at least.
Is this the case? Is there some variable for log files as well?
If CMake cannot support me with such variables, do you know any alternatives?
CMake doesn’t provide any infrastructure for this. The GNUInstallDirs module just provides variables for where things should go into install trees; how they are used are up to each project.
The steps involved here includes:
at runtime, determining your installation prefix (you may have been moved since make install; DESTDIR also exists)
once computed, use an embedded string of where your data is expected (possibly via target_compile_definitions(mylib PRIVATE LOCALSTATEDIR=\"${CMAKE_INSTALL_LOCALSTATEDIR}\") and compute it relative to the determined prefix
I see, this is not exactly what I need I suppose. I found some libs, which will do the job, like QStandardPaths Class | Qt Core 5.15.3 from the QT5 Framework.
There is just one more problem: If I develop, I usually want the database and other stuff just in my project dir (or perhaps in the build dir). Do you have an suggestion how I can achieve that my code uses these paths from qt5 when installing (or packaging), but not for just development?
Best idea I had so far was a variable, which I pass as a compile definition (like you mentioned above). But I wonder if there is some pattern or more robust way? don’t want to manually set that variable actually that’s just error prone.
Furthermore I wonder: Does CMake has a concept for “portable” applications? Because that’s basically the same problem. For a portable version you want to use relative paths as well
It’s derived from the install directories. CMake provides nothing out-of-the-box for prefix detection or the like; that’s completely dependent upon a project.
Portable projects are built upon coding guidelines that don’t embed or assume build or install tree paths into code and instead detect, at runtime, the prefix in use and then compute locations based on that. CMake doesn’t provide such things.