I have a Qt application that is not intended to be extensible. It does,
however, use Qt plugins to allow extra widgets and stuff.
At boot time, I see that the application scans all files in the application's directory to detect possible Qt plugin binaries. This takes a lot of time when I run the app from the build output dir (which contains .lib, .pdb, .exp, .ilk, ... files, too).
My current solution is to build my app and its own plugins into a separate dir. This alleviates the problem, but complicates the build.
Is there a way to directly tell Qt which dlls are to be loaded as plugins, and prevent it from scanning for additional plugins?
Related
I'm currently experimenting with golang's plugin system. A problem which I experienced in my testings is that the file size of the plugins is relativly big.
The application loading the plugin will be referenced as "host".
The host application itself is ~50MiB big since it is a web application and should be extended with plugin functionality.
I've implemented a small plugin loader to start the plugins up.
The plugins may use the already existing APIs in the application for example to access the database.
I've prepared a example plugin for this question. The plugin .so file size is ~39MiB. This gives me the reasonable suspicion that the plugin also contains source code from the host application.
Command used to create main.so:
go build -ldflags="-s -w" --buildmode=plugin main.go
Is it possible to "remove" the duplicated source code from the application to reduce file size since it is already loaded on runtime when the plugin gets loaded?
Plugin loader: https://github.com/jonasfranz/gitea/blob/feature/plugin/modules/plugins/loader.go
Example plugin: https://git.jonasfranz.software/JonasFranzDEV/giteaplugin
Source code is not included in plugins. But what is included in them is their dependencies, recursively. This is so because there is no guarantee that the main app that loads the plugin also contains the dependencies, so to ensure the viability of the plugin, its dependencies must be self-contained.
This does not cause problems if the main app also include the same dependencies (with the same version), they will only be "instantiated" once in the go runtime, for details, see How do Go plugin dependencies work?
What to do in order to reduce plugins' sizes? Besides removing the debug information (what you did), you should minimize the dependencies.
This may require redesign and major changes both in the plugin or in the app you wish to create the plugin for. For example, plugins should not refer to "implementation" packages, plugins should only refer to "interface" packages. If interfaces and implementations are not separated, this may not be possible (hence may it be required to change the main app too).
You may also try utilities that try to compress binaries, for details see: Shrink your Go binaries with this one weird trick
I am a total beginner at maven, I have read about it online but I am still confused how it can be used. I have eclipse Oxygen version installed and when I open projects I can see maven project option is already there. I was even able to create a maven project using YouTube tutorial. But now then I saw popular plugin called m2eclipse but I am not able to comprehend why is it actually used; when my application ran without it.
I am learning maven to get started with spring boot but I am finding it really overwhelming where to begin with, and many of the tutorial sites state to download maven (But maven already comes along with eclipse?)
Please explain.
Apache Maven is a build tool - a tool for compiling the source code of a project into a program that you can run (for example a jar file, or a war file that can be deployed on a Java EE application server). Besides automating all the tasks for building a project, it also gives you a standard way to organize your project and to keep track of dependencies (libraries that your project needs).
Why do you need such a tool?
When you write a small program that consists of one, or maybe a few source files, it's easy enough to compile it by hand on the command line, by directly using the Java compiler javac that comes with the JDK.
But when your project becomes more complex, and you have hundreds or even thousands of source files in multiple modules, it becomes really hard to keep track of everything and cumbersome to compile the files using javac. If your program needs libraries, it becomes even more complex, because you have to make sure that all the libraries are on the classpath, and some libraries need other libraries, which also have to be on the classpath.
A tool such as Maven helps you to compile all the source files in the right order and to keep track of all the libraries. Maven can automatically download libraries from the web and add them to your project, and downloading everything and building the whole project can be done with one simple command such as mvn clean package.
Spring Boot is part of the Spring Framework, which is a huge framework with tons of useful functionality for developing projects in Java. A Spring Boot project typically needs dozens of libraries, and it would be very hard to use if you'd have to keep track of all those libraries by hand - so that's why it uses Maven to manage all of this for you.
A Maven project is configured using a file named pom.xml - in that file, you describe your project and you put a list of libraries that your project needs. When you build your project, Maven will read the pom.xml file and figure out automatically what source files need to be compiled, and what libraries need to be downloaded.
m2eclipse comes preinstalled in Eclipse (at least when selecting "Eclipse for Java developers" or "Eclipse for Java EE developer"), thats why you were able to use Maven by default.
Still you probably want a command line Maven, because that's most likely how it will eventually run on the CI server, sometimes Eclipse Maven installation can produce different result than the command line install.
I have a fairly large multi-project C++ solution in Visual Studio 2015. Some of the projects compile to static libraries which are used by other projects, and most of them use precompiled headers to speed up compilation. Each project also has multiple build configurations: debug, release, and several testing configurations which always build an executable to run the tests (even if the normal configurations build a static library).
When building debug and release configurations, or when doing a full rebuild, everything works well, but when doing an incremental build of a test configuration for a project that uses another project's static library, I get C2859 errors which cause the build to fail.
For example, let's say I have a project peach which builds a static library, and a project cobbler that relies on peach. The precompiled header for cobbler references only system and external libraries (no headers from inside the solution). cobbler's test configuration references peach.lib. peach.lib is created by peach's release configuration, so I have a solution configuration called cobbler-test which specifies that:
peach uses its release project configuration
cobbler uses its test project configuration.
Building cobbler-test from scratch (or rebuilding it, clean & build, etc) works fine. But if I then modify a source file called crust.cpp in cobbler and try to build, I get this error:
c:\...\cobbler\src\crust.cpp(1): error C2859: C:\...\out\cobbler-test.pdb is not the pdb file that was used when this precompiled header was created, recreate the precompiled header.
Again, this only happens when referencing a static library from the same solution that was built with a project configuration name different from the current one. With both projects using release or debug, incremental builds work fine.
Having to do a full rebuild every time defeats the purpose of using precompiled headers in the first place. Is there any way to get incremental testing configurations to work without having to resort to creating extra project configurations for every combination of projects?
My current solution to this problem is not to use testing configurations, and to create separate projects for testing projects that generate static libraries. This allows all dependent projects to use the same project configuration and allows the precompiled headers to work their magic without blowing up when doing incremental builds.
While this works fairly well for the static libraries, since they can easily be imported with #pragma comment(lib, ...), it's a bit more problematic for projects that build standalone executables. Thankfully, in my case most of those projects don't have a lot of stuff that needs testing.
Why there's a difference in Default Source Lookup Path between GWT and java launch configurations?
In multi-module projects instead of containing projects, the Default folder contains the class folders of those projects!
It causes "Source not found" errors when the debugger steps into a dependency project.
I know I can add projects manually. Just want to know why this difference is needed.
The only project in the list is the associated with the .launch.
GWT needs '.java' source files of dependencies to be able to compile (translate to js) while the Java launcher needs only '.class' compiled files.
I suppose you know GWT has a different way to manage dependencies (through modules within the same project), which is good for some advanced GWT practices like loading a module's js lazily (this feature doesn't work with "foreign" libs/projects).
So this could also be an answer for why eclipse GWT doesn't suppose you will have more projects (but more modules instead)
Finally if you really have an independent GWT lib that you're maintaining this is an issue as you said.
I don't understand the difference between these Xcode features.
I'm building and app - but the functionality of the app is being abstracted into libraries (so they can be distributed separately as an "SDK").
So I have a workspace of library projects and the app project. I can add library projects to the app project by doing "link binary with libraries". This gives me a list of .a library projects in the current workspace which I can link to.
I can also add frameworks here.
In the "target dependencies" bit all I can add is other targets in the current project.
What I really want to do is both - I want my app project to build all the other library projects when I build it. I also want to make it verbose what libraries the app (and other libraries) depend on.
So can somebody please explain the difference, and whether what I am doing is the right way to go about it?
Many thanks!
It says here...
Drag your framework product (located in the Products folder) to the existing Link Binary With Libraries build phase of your application
target. This causes the application to link against your framework.
And...
In the General tab of the inspector window, add your framework as a dependency for the application. Adding this dependency causes Xcode to
build the framework target before building the application target.
The build dependency you establish in the application target causes
the framework to be built before the application. This is important
because it guarantees that a built version of your framework will be
available to link against and to embed in the application. Because of
this dependency, you can set the active target of your Xcode project
to your application and leave it there.
So it seems that you're supposed to use both. Seems redundant though, because if you're linking to a framework then its a dependency. I suppose you might want to only link to a library and not build it first. Although Xcode seems to build linked libraries even without them being added to the dependency section. Perhaps that's a result of the "Find Implicit Dependencies" option in a scheme's build settings.
I do something similar and was explicitly setting the 'header search path' and 'library search path' in the final executable target. However this all depended on where the objects were being generated. Initially I had set this to be within the source tree (actually a sibling directory called build), however after changing the location of the Xcode DerivedData directory and telling it to build into that directory, the projects no longer built.
The final solution was simply to remove the explicit setting of the 'header/library search path' and set the target dependencies correctly. This resulted in the project building for debugging and archiving without issue.