Unsolved Do .pri subprojects have a name?
-
As Qt Creator handles .pri files in a special way, somewhere in between a module and a subproject, does anyone know if this particular concept/feature received a specific official name by the Qt community? A specific name would simplify how this feature could be addressed in technical discussions.
-
.pri is simply an include file, there is no special name for it. And there is nothing special about .pri files either - they are more or less copy pasted into .pro when you call include().
-
@rmam said in Do .pri subprojects have a name?:
somewhere in between a module and a subproject
I always treated it as nothing more than a copy/paste machine. Happy to see if someone have a more insightful view
-
@sierdzio said in Do .pri subprojects have a name?:
And there is nothing special about .pri files either
Actually there is, when using Qt Creator. Qt Creator lists files included in .pri files differently, in dedicated sections which are something between a subproject and a module.
-
This is just a display difference. There is no functionality change due to things being in a pri file
-
@VRonin said in Do .pri subprojects have a name?:
This is just a display difference. There is no functionality change due to things being in a pri file
Representing groups of related components differently is already a significant change in functionality.
Furthermore, multiple subprojects can include the same .pri file, which propagates the same pseudo-module throughout multiple projects. That's also a significant functionality change as well.
-
@rmam said in Do .pri subprojects have a name?:
Furthermore, multiple subprojects can include the same .pri file, which propagates the same pseudo-module throughout multiple projects. That's also a significant functionality change as well.
But it's still only about displaying the .pri. You project is build by qmake, and to qmake the pri file is just a simple include.
Think of it like of a global header you might have in your source code: you may include it across different modules, even across libraries of your project, but from compiler's perspective there is nothing special about it: just a header that it has to parse more often than other headers.
-
Since you mention functionality change: there is, of course, a way to use .pri cleverly. Consider this code:
CONFIG += feature1 # ... feature1 { include(mySuperFeature.pri) } else { include(myOtherSuperFeature.pri) }
In this simple way you can include different headers, sources, rules etc. based on some config values. However, even here, the pri file is only a simple include. You would get exactly the same results if you copy-pasted the contents of mySuperFeature.pri and myOtherSuperFeature.pri directly into the code above.