I've switched versions of QT (from 5.10.1 to 5.12.2) to get a more recent version of Mingw32 (from GCC/G++ 5.3 -> 7.3). The reasoning behind this is that have multiple products using the same library and using an old version of gcc is less than ideal. We've never had any issues with build before, but now I get the following error:
":-1: error: No rule to make target 'res/resources.qrc', needed by 'release/qrc_resources.cpp'. Stop."
Oddly enough, it does not stop the build from generating a completely functioning executable.
So far I've tried:
Cleaning the directory and building again
Deleting the build directory and building again
Not selecting shadow build option
Forcing Qmake (Build -> Run Qmake)
Creating a new .pro.user file
Deleting the whole repo, cloning it again, rebuilding the dependencies (we have a library which it relies on) and rebuilding QT
Adding the .qrc file to the includes (I know this was silly, but I was at my wits end)
Checking for deleted files (None that I can see)
Checking file names for inconsistencies(They seem ok)
Here is my qrc file
<RCC>
<qresource prefix="/">
<file>images/cnctbtn_connected.png</file>
<file>images/cnctbtn_connecting.png</file>
<file>images/cnctbtn_disconnected.png</file>
<file>images/configbtn.png</file>
<file>images/flash.png</file>
<file>images/logbtn.png</file>
<file>images/streambtn_start.png</file>
<file>images/streambtn_stop.png</file>
<file>images/d_logo_outlined.ico</file>
<file>images/d_logo_small.png</file>
<file>images/d_logo_small_outlined.png</file>
</qresource>
</RCC>
The list of resources which are located in the images folder
cnctbtn_connected.png
cnctbtn_connecting.png
cnctbtn_disconnected.png
configbtn.png
d_logo_small.png
d_logo_small_outlined.png
flash.png
logbtn.png
streambtn_start.png
streambtn_stop.png
d_logo_outlined.ico
The qrc_resource_File.cpp also looks ok. I see the bytes of the images in it, their names and assorted namespace declarations and functions in that name space.
The one thing I'm unsure of is why the images folder has it's on name in the resource name list.
Note: I've removed the bytes in this array, for my eyes and yours.
static const unsigned char qt_resource_name[] = {
// images
// cnctbtn_disconnected.png
// cnctbtn_connected.png
// cnctbtn_connecting.png
// streambtn_start.png
// d_logo_outlined.ico
// d_logo_small.png
// streambtn_stop.png
// d_logo_small_outlined.png
};
Ideally there would be no build error, which I don't really understand since I can see and use the executable produced. If you need any other information, don't hesitate to ask!
Related
Assume I have a qmake project file *.pro:
# some stuff ...
TARGET = my_binary
# other stuff...
include( $$PWD/post.pri )
And inside the post.pri file (because I would like to reuse whatever this *.pri file does), I would like to get the complete name of the output file.
For example if is an app, then on windows I would like to get my_binary.exe and on linux my_binary. Or if the project is a shared lib, I would like to get my_binary.dll or libmy_binary.so respectively. Same if is a static lib, I would expect my_binary.lib and libmy_binary.a.
I have already tried the undocumented qmake variable QMAKE_FILE_OUT but with no success.
You can do this in your .pro script:
load(resolve_target)
message($$QMAKE_RESOLVED_TARGET)
It will output the build path and target name, according to your platform and project TEMPLATE.
I'm trying to create app based on Jetty 9.4.20 (embedded) and Vaadin Flow 14.0.12.
It based on very nice project vaadin14-embedded-jetty.
I want to package app with one main-jar and all dependency libs must be in folder 'libs' near main-jar.
I remove maven-assembly-plugin, instead use maven-dependency-plugin and maven-jar-plugin. In maven-dependency-plugin i add section <execution>get-dependencies</execution> where i unpack directories META-INF/resources/,META-INF/services/ from Vaadin Flow libs to the result JAR.
In this case app work fine. But if i comment section <execution>get-dependencies</execution> then result package didn't contain that directories and app didn't work.
It just cannot give some static files from Vaadin Flow libs.
This error occurs only if i launch packaged app with ...
$ java -jar vaadin14-embedded-jetty-1.0-SNAPSHOT.jar
... but from Intellij Idea it launch correctly.
There was an opinion that is Jetty staring with wrong ClassLoader and cannot maintain requests to static files in Jar-libs.
The META-INF/services/ files MUST be maintained from the Jetty libs.
That's important for Jetty to use java.util.ServiceLoader.
If you are merging contents of JAR files into a single JAR file, that's called a "uber jar".
There are many techniques to do this, but if you are using maven-assembly-plugin or maven-dependency-plugin to build this "uber jar" then you will not be merging critical files that have the same name across multiple JAR files.
Consider using maven-shade-plugin and it's associated Resource Transformers to properly merge these files.
http://maven.apache.org/plugins/maven-shade-plugin/
http://maven.apache.org/plugins/maven-shade-plugin/examples/resource-transformers.html
The ServicesResourceTransformer is the one that merges META-INF/services/ files, use it.
As for static content, that works fine, but you have to setup your Base Resource properly.
Looking at your source, you do the following ...
final URI webRootUri = ManualJetty.class.getResource("/webapp/").toURI();
final WebAppContext context = new WebAppContext();
context.setBaseResource(Resource.newResource(webRootUri));
That won't work reliably in 100% of cases (as you have noticed when running in the IDE vs command line).
The Class.getResource(String) is only reliable if you lookup a file (not a directory).
Consider that the Jetty Project Embedded Cookbook recipes have techniques for this.
See:
WebAppContextFromClasspath.java
ResourceHandlerFromClasspath.java
DefaultServletFileServer.java
DefaultServletMultipleBases.java
XmlEnhancedServer.java
MultipartMimeUploadExample.java
Example:
// Figure out what path to serve content from
ClassLoader cl = ManualJetty.class.getClassLoader();
// We look for a file, as ClassLoader.getResource() is not
// designed to look for directories (we resolve the directory later)
URL f = cl.getResource("webapp/index.html");
if (f == null)
{
throw new RuntimeException("Unable to find resource directory");
}
// Resolve file to directory
URI webRootUri = f.toURI().resolve("./").normalize();
System.err.println("WebRoot is " + webRootUri);
WebAppContext context = new WebAppContext();
context.setBaseResource(Resource.newResource(webRootUri));
u-boot support many platform. and there are files with same file name. it's hard to determine which file is involved in the make process for a certain platform. how could I get all files that be used in make process?
You could:
first, build u-boot for your target platform,
then look for all object files that resulted from the compilation process.
For example, if your u-boot main makefile were located in /opt/u-boot-2019.01,
the following commands would give you all the object files that were compiled:
cd /opt/u-boot-2019.01
find . -name "*.o"
You can then correlate the list of files you retrieved with the content of your target board's config file, usually located in the configs sub-directory.
In my case, the first object files to be displayed are:
./scripts/kconfig/zconf.tab.o
./scripts/kconfig/conf.o
./scripts/dtc/srcpos.o
./scripts/dtc/dtc.o
./scripts/dtc/treesource.o
./scripts/dtc/util.o
./scripts/dtc/fstree.o
./scripts/dtc/checks.o
./scripts/dtc/flattree.o
./scripts/dtc/dtc-parser.tab.o
./scripts/dtc/livetree.o
./scripts/dtc/dtc-lexer.lex.o
./scripts/dtc/data.o
./arch/arm/cpu/built-in.o
./arch/arm/cpu/armv8/built-in.o
./arch/arm/cpu/armv8/cpu-dt.o
./arch/arm/cpu/armv8/cache_v8.o
./arch/arm/cpu/armv8/generic_timer.o
./arch/arm/cpu/armv8/exceptions.o
./arch/arm/cpu/armv8/lowlevel_init.o
./arch/arm/cpu/armv8/fwcall.o
./arch/arm/cpu/armv8/cpu.o
./arch/arm/cpu/armv8/start.o
./arch/arm/cpu/armv8/cache.o
./arch/arm/cpu/armv8/transition.o
./arch/arm/cpu/armv8/tlb.o
./arch/arm/mach-sunxi/built-in.o
./arch/arm/mach-sunxi/clock.o
./arch/arm/mach-sunxi/dram_helpers.o
./arch/arm/mach-sunxi/pinmux.o
./arch/arm/mach-sunxi/prcm.o
./arch/arm/mach-sunxi/board.o
./arch/arm/mach-sunxi/clock_sun6i.o
./arch/arm/mach-sunxi/cpu_info.o
./arch/arm/mach-sunxi/rsb.o
For example, the fact that the file ./arch/arm/mach-sunxi/rsb.o is in the list means that ./arch/arm/mach-sunxi/rsb.c was compiled during the build process and contributed to the resulting u-boot image.
I have a QT application app.exe and a QT plugin plugin.dll. My plugin.dll depends on many other dynamic libraries (e.g. lib1.dll, lib2.dll and so on). To distribute my project I have this folder structure (ignoring QT libraries):
app.exe
plugins\
plugin.dll
lib1.dll
lib2.dll
lib3.dll
The problem is that there are too many dependences on libX.dll and I want to hide them in a plugin folder, e.g.:
app.exe
plugin\
plugin.dll
lib1.dll
lib2.dll
lib3.dll
But this way libraries libX.dll are "unseen" to my plugin, so that it cannot be loaded. Is there any way to solve this problem?
I am using this code to import libX.dll in plugin.dll's pro-file:
LIBS += -Lpath -l lib1 -l lib2 -l lib3
One of the ways of solving this problem is:
Link all libraries dynamically (at runtime)
Add extra location to search for the libraries
These changes should be done in plugin.dll code:
/* Declare a pointer to import function */
typedef void (*FUNCTION)();
FUNCTION f;
/* Make system search the DLLs in my plugin folder */
// Variable "app" contains directory of the application, not the plugin
QDir app = QDir(qApp->applicationDirPath());
// Combine path
QString plugin_path = app.filePath("plugins/");
// Adding full path for DLL search
SetDllDirectory(plugin_path.toStdWString().c_str());
/* Linking the library */
QLibrary mylib("mylib.dll");
f = (FUNCTION ) mylib.resolve("function");
if (f != NULL)
f(); // You got the function from DLL
else
return; // DLL could not be loaded
This solution has disadvanges:
It is not platform independent (I think you can avoid using SetDllDirectory in UNIX-like systems but I am not sure)
If you import a lot of functions you will have a lot of pointers
Does any one know pure Qt solution?
So I have a Q_OBJECT tagged class, which requires pregenerated .moc to be usable.
In my .qbs file, I have a CppApplication item; this seems to be the wrong type of project, as qbs does not call moc ClassName.cpp to generate moc's for me. What should be used instead/tweaked?
-
So I knew about Qt.core dependency, but it wasn't working on my crippled install of Qt; while I was trying to fix it, these facts came up:
It was required to detect Qt toolchain (qbs-setup-qt) and call qbs-config-ui
Qbs indeed stores the build rules in core.qbs, linked in via Qt/core dependency.
it's possible to copy/paste the build rules into my own .qbs file and avoid external dependencies; I'm considering this as a dirty hack for deploying the code on really crippled build systems (now I have a word for Qt support on Gentoo).
I think you might be missing the dependency of the application on the Qt-modules.
The rule for generation of the moc files is part of the Qt.core module.
You might add this dependency with:
CppApplication {
name: "MyApp"
files: "path_to_source/**"
Depends { name: "Qt.core" } // Optional
Depends { name: "Qt.widgets" }
}
As all other Qt modules have an implicit dependency on Qt.core the explicit dependency could on Qt.core could be skipped if there is a dependency on a different Qt-module (Qt.widgets in this example).
More details could be found at http://doc.qt.io/qbs/qt-modules.html