Considering a plugin system with the following installation pattern:
/install_prefix/main.exe
/install_prefix/plugins/plugin.dll
If my plugin depends on a library compiled as shared, its dll should be installed in the exe path:
/install_prefix/main.exe
/install_prefix/plugin_dependency.dll
/install_prefix/plugins/plugin.dll
I found isolated applications can be used to keep the dependency side by side with the plugin as follows:
/install_prefix/main.exe
/install_prefix/plugins/plugin_dependency.dll
/install_prefix/plugins/plugin.dll
This relies on a manifest file generated with visual. I am using cmake to generate my projects and I can't find any reference on a "good" way to handle isolated applications in a cmake file.
Did anybody have this use case?
EDIT:
This question propose answers on how to embed an already existing manifest file. What I would like is a way to generate the manifest file in the build process, in a perfect world with something as simple as installing exports. Something like:
install(
TARGETS target_name
MANIFEST target_name.manifest
)
This would generate the manifest file and embed it with the target.
Related
ALL,
Does anyone succeeds building a client to libmysqlclient on Windows?
Following this instructions I can build the library itself
But then trying to follow mySQL documentaton which reads
To specify header and library file locations, use the facilities provided by your development environment.
With the old mySQL-Connector-C I was able to download just the code for the connector build it and then it had only 1 mysql.h
With the new library (8.0) I have t get the whole package, and there fore it will have multiple copies of mysql.h (yes, I did check by dong search of the file from Windows Explorer and Terminal/Bash).
In terms of library - it is easy as it will be hopefully just one and I can sue -L option for the linker.
But how do I get the proper include folder?
TIA!!
BTW, the tag here needs t be changed - it is not called connector-c anymore
I've created a nimble library package as per the documentation. When I try to build it using nimble build I get the following error.
Error: Nothing to build. Did you specify a module to build using the bin key in your .nimble file?
I can do this and it does fix the error but according to the documentation adding the bin key to the .nimble file turns my package into a binary package.
Other things I have tried:
Use nimble install: This does not appear to verify that my code will actually compile and will happily install anything to the local package directory (I added a C# class to my .nim file, for example, and it was successfully installed).
Use nimble c: This works but I have to pass in the path to the nim file I want to compile and the binDir entry in the .nimble file is ignored resulting in the output being placed in the same directory as the file being built. This complicates the development cycle because I have to manually clean up after the compiler.
Use the compiler directly. This is pretty much the same as the previous option with the same flaws.
I guess I could also create a separate .nim file and import my library after it is installed but this is a big overhead for just wanting to verify that a package in the early stages of development will actually compile.
I just want to be able to verify that the source code in my library package is syntactically correct and will compile. How is this meant to be done for library packages?
From your provided link to the nimble package manager documentation I have the feeling that
https://github.com/nim-lang/nimble#tests
is what you are looking for. But I have never used the test command, so I am not sure. I do my test manually still, I read the nimble docs maybe 4 years ago and can not really remember. And currently there is much package manager related work going on, I heard there is a new, alternative package manager called nimph, and from a forum thread I think I read something that nimble is going to change and improve also. Maybe you should consider subscribing to the Nim forum, that is the place where the bright Nim devs are. Well, at least a few of them.
I'm getting the following error compiling a program using a 3rd party library:
Error:(xx) No resource identifier found for attribute 'tint' in package 'com.example.mycompany.myapp'
The line xx is inside the xml layout that includes a custom component defined in the library.
cntrlco:tint="42"
The xml namespace documentation says I need the following:
xmlns:cntrlco="http://schemas.android.com/apk/res-auto"
Here's my best guess as to the problem, but if you think otherwise please let me know, this is a guess.
I suspect I don't have the library installed completely. The reason is that the library instructions want the library installed from maven. I'm not up on this technique, but it appears to be a web based auto install that automates dependency installs while performing the primary install. Nice idea, but I can't install using the web (long story), so I included the .aar file locally.
From my research, installing .aar files locally won't look at its dependencies. If this is true and the "tint" property is defined in a dependency, then this would explain the error I'm seeing.
Is there a way to follow the error chain in more detail so I can verify my theory? Along the way, will this help me find the name of the possible missing dependencies so I can see if including them fixes the problem.
I am trying to build VTK from sources as it is a dependency to PLC library which I am trying to build.
I use ccmake.. to select all relevant groups to be built (including Group_imaging), and I can build VTK with no particular problems.
Though, I cannot find vtkImageLoader2.h (and many other headers) anywhere in the system. As these files are required by PCL, this is a problem.
I checked that the original file exists inside the source tree, and it is indeed inside IO/Image.
I can't understand why the file is not being build and deployed to /usr/local/include, I made sure all modules (groups) are ON in ccmake.
Is this file deprecated, or am I missing the way to deploy it?
EDIT: I discovered that the file belongs to module vtkIOImage that is part of the "StandAlone" group. The StandAlone group is set "ON" when i run ccmake. Is this a bug in the build scripts of VTK?
I am working on bindings for a cpp library.
To do this I wrote a capi / wrapper for the library and compiled that to a shared lib (.so file).
My question is, how do I then use and integrate this file into cargo without forcing the user to install it? Currently I build the cpp via a Makefile called from the build variable in Cargo.toml, but I am unsure what to do with the compiled lib.
For testing, I can either use rpath or LD_LIBRARY_PATH to point the executable to the right location, but this will not work when distributing a library.
How are people managing this?
First of all, determine whether you really need a shared library. It's not clear from your question, but if you compiled your own wrapper into a shared library, that's probably unnecessary - you can compile your code into a static library and link it directly into your executable.
Moreover, you can try to link that third-party library statically too. I don't think this should be hard. And yes, you need to use build command in the manifest to do all of this now.
However, if you still need to use a shared library and you don't want the end user to install it herself (which is strange, because that's the point of shared libraries), you have to distribute it manually. For example, you can write a makefile which assembles an archive which your users may extract and use. For your program to find the library correctly you will either have the user to install this archive into the system root directory (e.g. /usr on linux; then this shared library will be located automatically) or you will have to write small shell script wrapper around your executable which will locate the shared library and set appropriate LD_LIBRARY_PATH.
I'd go for the first path. Usually all major platforms provide means to create installation packages (deb/rpm/pkg.tar.xz/whatever on Linux, brew on Mac, windows installer on Windows, though on Windows you can just put your shared library in the same directory as the executable and it will work). You just have to create packages for the platform your users work on, so your program will be installed in correct directories and your shared library will be resolved automatically.