Custom assembly of plugins - we will go the other way
All habra 
A small (well, very small) note on how to let the plugin choose for itself - whether to build on this system or not. Of course, there is a good old way - just to 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 install for which systems it will be built. If there are only 5 plug-ins and is no longer foreseen, then this is normal. But if there are already 20 plug-ins, and another 30 are planned, and many of them should be built only for some platforms, then plugins.pro turns into a trash bin. If there are several developers, this is even more confusing.
Wouldn't it be more logical to transfer concern about the systems in which the plugin will assemble on the fragile shoulders of its developer? Then the plugins.pro file becomes quite simple and clear:
')
But macplugin.pro will have to write something like this (it will be the same for winplugin.pro):
As you can see, the matter is now small - to make the file nobuild.inc in the root of the folder with the sources of plug-ins and write something into it so that it cancels the build of the plug-in. 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 compile - for Qt for empty .pro files tries to collect all the sources in the default settings folder. So, the source code of the plugin will try to compile into an executable file, and even more so the source code 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.
Breaking the qmake documentation, I didn’t find a single function to skip the project build, so I had to do a dirty hack: change the compiler and linker! For what? Well, what program is in all systems, does not do anything destructive, takes any arguments and always returns 0?
In general, we write this:
A Windows block is needed so that qmake does not attempt to inject a manifest into an unassembled binary.
"Conclusion" or something like that.
The method is dirty, an obvious crutch, but it works. And then - what a program without crutches? =)
But if the respected Habram people offer a different, more adequate method for solving the problem, I will be only too happy.
A small (well, very small) note on how to let the plugin choose for itself - whether to build on this system or not. Of course, there is a good old way - just to 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 install for which systems it will be built. If there are only 5 plug-ins and is no longer foreseen, then this is normal. But if there are already 20 plug-ins, and another 30 are planned, and many of them should be built only for some platforms, then plugins.pro turns into a trash bin. If there are several developers, this is even more confusing.
Wouldn't it be more logical to transfer concern about the systems in which the plugin will assemble on the fragile shoulders of its developer? Then the plugins.pro file becomes quite simple and clear:
')
# plugins.pro TEMPLATE=subdirs SUBDIRS+=common SUBDIRS+=macplugin SUBDIRS+=winplugin But macplugin.pro will 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 matter is now small - to make the file nobuild.inc in the root of the folder with the sources of plug-ins and write something into it so that it cancels the build of the plug-in. 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 compile - for Qt for empty .pro files tries to collect all the sources in the default settings folder. So, the source code of the plugin will try to compile into an executable file, and even more so the source code 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.
Breaking the qmake documentation, I didn’t find a single function to skip the project build, so I had to do a dirty hack: change the compiler and linker! For what? Well, what program is in all systems, does not do anything destructive, takes any arguments and always returns 0?
In general, we write this:
# nobuild.inc QMAKE_CXX=echo QMAKE_LINK=echo win32: { CONFIG-=embed_manifest_exe CONFIG-=embed_manifest_dll TARGET= } A Windows block is needed so that qmake does not attempt to inject a manifest into an unassembled binary.
"Conclusion" or something like that.
The method is dirty, an obvious crutch, but it works. And then - what a program without crutches? =)
But if the respected Habram people offer a different, more adequate method for solving the problem, I will be only too happy.
Source: https://habr.com/ru/post/139026/
All Articles