Custom assembly of plugins - we will go the other way
Hello everyone!
A small (well, very small) note on how to let the plug-in choose for itself - to assemble in this system or not. Of course, there is a good old way - just exclude the extra plugin from the assembly itself, for example, like this:
But with this approach, when adding each new plug-in, you need to register it in plugins.pro and establish for which systems it will be built. If there are only 5 plugins and no longer expected, then this is normal. But if there are already 20 plugins, and another 30 are planned, and many of them should be assembled only for some platforms, then plugins.pro turns into garbage. If there are several developers, this is even more confusing.
Isn’t it more logical to transfer the concern about which systems the plugin is going to build onto the fragile shoulders of its developer? Then the plugins.pro file becomes very simple and straightforward:
But then in macplugin.pro you have to write something like this (it will be the same for winplugin.pro):
As you can see, the thing now is small - make the file nobuild.inc in the root of the folder with the plugin source files and write something in it so that it cancels the build of the plugin. At first it seems that it is better to leave it empty at all, but this will lead to an attempt by the plugin to collect - because Qt for empty .pro files tries to collect all the sources in the folder with the default parameters. So, it will try to compile the plug-in sources into an executable file, and even more so the sources that are not intended for this OS. Of course, in this case, you will most likely see something similar to the picture at the beginning of the topic.
Break qmake documentation, I did not find a single function to skip building the project, so I had to make a dirty hack: replace the compiler and linker! For what? Well, what kind of program is in all systems, does nothing destructive, takes any arguments and always returns 0?
In general, we write like this:
The Windows block is needed so that qmake does not try to inject the manifest into an unassembled binary.
"Conclusion" or something like that.
The method is dirty, an obvious crutch, but it works. And then - what kind of program without crutches? =)
But if dear habralu people propose a different, more adequate method of solving the problem, I will only be glad.
A small (well, very small) note on how to let the plug-in choose for itself - to assemble in this system or not. Of course, there is a good old way - just exclude the extra plugin from the assembly itself, for example, like this:
# plugins.pro
TEMPLATE=subdirs
SUBDIRS+=common
macx: SUBDIRS+=macplugin
win32: SUBDIRS+=winplugin
But with this approach, when adding each new plug-in, you need to register it in plugins.pro and establish for which systems it will be built. If there are only 5 plugins and no longer expected, then this is normal. But if there are already 20 plugins, and another 30 are planned, and many of them should be assembled only for some platforms, then plugins.pro turns into garbage. If there are several developers, this is even more confusing.
Isn’t it more logical to transfer the concern about which systems the plugin is going to build onto the fragile shoulders of its developer? Then the plugins.pro file becomes very simple and straightforward:
# plugins.pro
TEMPLATE=subdirs
SUBDIRS+=common
SUBDIRS+=macplugin
SUBDIRS+=winplugin
But then in macplugin.pro you have to write something like this (it will be the same for winplugin.pro):
# macplugin.pro
macx: {
# project configuration here
} else {
include(../nobuild.inc)
}
As you can see, the thing now is small - make the file nobuild.inc in the root of the folder with the plugin source files and write something in it so that it cancels the build of the plugin. At first it seems that it is better to leave it empty at all, but this will lead to an attempt by the plugin to collect - because Qt for empty .pro files tries to collect all the sources in the folder with the default parameters. So, it will try to compile the plug-in sources into an executable file, and even more so the sources that are not intended for this OS. Of course, in this case, you will most likely see something similar to the picture at the beginning of the topic.
Break qmake documentation, I did not find a single function to skip building the project, so I had to make a dirty hack: replace the compiler and linker! For what? Well, what kind of program is in all systems, does nothing destructive, takes any arguments and always returns 0?
In general, we write like this:
# nobuild.inc
QMAKE_CXX=echo
QMAKE_LINK=echo
win32: {
CONFIG-=embed_manifest_exe
CONFIG-=embed_manifest_dll
TARGET=
}
The Windows block is needed so that qmake does not try to inject the manifest into an unassembled binary.
"Conclusion" or something like that.
The method is dirty, an obvious crutch, but it works. And then - what kind of program without crutches? =)
But if dear habralu people propose a different, more adequate method of solving the problem, I will only be glad.