I have been using tools like androgurad, dedexer and apktool to decompile android apk files and have been viewing the statistics. While analysing the packages dependencies in apk files, I noticed that there are internal and external packages. Please explain the difference between the two.
Usually those packages which are not available to developers through the official SDK they are called internal.
Related
Package Manager gives this output:
Resolved actions to install package 'Zebra.Printer.Card.SDK.2.15.2634'
Install failed. Rolling back...
Package 'Zebra.Printer.Card.SDK.2.15.2634' does not exist in project 'ZCDOTNETSC'
Package 'Zebra.Printer.Card.SDK.2.15.2634' does not exist in folder 'P:\Windmill\ZC300SC\packages'
Executing nuget actions took 48 ms
Could not install package 'Zebra.Printer.Card.SDK 2.15.2634'. You are trying to install this package into a project that targets 'native,Version=v0.0', but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.
Time Elapsed: 00:00:00.1490121
========== Finished ==========
I have a C++ project supporting older Zebra card printers and I would like to add support for their current range but they have dropped C++ SDKs, so I would like to mix .NET with C++ if possible, so I can use the latest SDK.
Am I barking up the wrong tree and it's just not possible? I can only use C# with such a package?
I've checked several similar posts dating back to 2013 often suggesting editing XML in various project and packages files which I do not see on my set-up.
Thanks in advance for any pointers.
I'm working on a project, which targets both Windows and Linux (and possible in the future MacOS). It consists of some applications with several shared libraries. It is written in modern C++ and modern CMake. It also uses 3rd-party libraries like Qt, OpenCV, Boost, GraphicsMagick, samplerate, sndfile. Those dependencies are handled through Conan package manager. I'm building both on Linux (Ubuntu 18.04, GCC 8.1) and Windows (via WSL - also Ubuntu 18.04, MinGW-w64 8.1). I'm using fairly recent versions of 3rd-party libraries with custom built options (strictly speaking - different versions than available on Ubuntu's APT, e.g. Qt v5.11.3, or custom built of GraphicsMagick)
I'm using CPack. On Windows I'm building NSIS installer, but on Linux I would like to use DEB generator (may be other if needed). All of my targets (written apps and shared libs) have appropriate CMake's INSTALL configurations, so they are copied correctly into the generated installers (component based installation). The real problem comes with packaging of 3rd-party dependencies.
Problem
Strictly speaking, I have no idea, how to do it well using CMake+CPack+Conan, both on Linux and Windows. I've read a lot of articles and posts, but I'm stucked. I would like to have something, that automatically bundles into the installer all 3rd party libraries used by project with needed plugins and, what is the most important, with needed system/compiler libraries (libgomp, libstdc++ and so on).
Possible solution
To my surprise, on Windows, this task is fairly easy, because every DLL used by app (my libs, 3rd-party libs and system/compiler libs) needs to be located where executable is. I'm engaging Conan into this, by importing all used DLLs into bin directory. In the end, in most naive way of packaging, I will just copy the bin directory into the installer and it should work. But I'm not sure, if this approach is OK.
On Linux, things are more complicated. First, there is arleady a package manager. Unfortunately, libraries/compilers available there are too old for me (e.g. on APT there is only Qt 5.9.6 ) and are built using different compile options. So, the only way for me is to ship them with my software (like in Windows). There are also issues with searching for dynamic libraries by ld, RPATH handling and so on. At the moment, the only solution I see is to write something like 'launcher' for my app, which sets LD_LIBRARY_PATH before program starts. After that, in this case we can just copy bin or lib directory to the DEB installer and this should work. But still, I don't know if this is correct approach.
Other solutions
I've also looked into other solutions. One of them was BundleUtilities from CMake. It doesn't work for me. It has a lot of problems in recognizing, whether some library is system or local one. Especially in WSL, where it stucked in processing dependencies to USER32.dll, KERNEL32.dll. BundleUtilities in Windows worked for me only with MSYS, but in MSYS I've failed to compile some 3rd-party libraries (GraphicsMagicks via Conan) and that's the reason, why I'm using WSL.
Summary
I'm looking for good and verified method of packaging C++ projects with multiple apps, libs and shipped 3rd-party libs, both for Windows and Linux. How are you doing things like this? Are you just copying bin and/or lib dirs to the installers? How (in terms of CMake/CPack code) are you doing that? INSTALL(DIRECTORY ...), or similar? I'm not sure, but I think that this problem should be already solved in the industry. ;)
Thanks for all suggestions.
First, Conan is a package manager for development, not for distribution, that's why you didn't find an easy way to solve your problem. Second, most of discussions are made at Conan issue, including bugs and questions. There you will find a big community + Conan devs which are very helpful.
with needed system/compiler libraries
This is not part of Conan. Why you don't use static linkage for system libraries?
Talking about CPack, we have an open discussion about it usage with Conan: https://github.com/conan-io/conan/issues/5655
Please, join us.
I see few options for your case:
on package method, run self.copy and all dependencies from self.cpp_deps, which includes all libraries, so you can run Cpack
Use Conan deploy generator to deploy all artifacts, and using a hook you can run cpack or any other installer tool
Out friend SSE4 is writing a new blog post about Deployment + Conan, I think it can help you a lot. You can read a preview here.
Regards!
What do Android Studio modules produce? e.g. a jar per module, an apk per module?
How do dependencies between modules affect these?
Or is it solely an IDE fiction?
Well if you are getting started I would advice you check out this page:
https://developer.android.com/tools/projects/index.html It contains what you seek.
"There are only a handful of files and folders generated for you, and some of them depend on whether you use Android Studio or the android tool to generate your module. As your application grows in complexity, you might require new kinds of resources, directories, and files."
-As in the the dev.android link I just posted above
My project currently depends upon a library (PJSIP) that is distributed with Autotools build scripts for *NIX and Visual Studio project files for Windows.
My project currently uses the CMake build system. The current script is Linux-specific: it assumes that PJSIP has been installed as a prerequisite (in a system-wide library location, managed by the package manager) and only specifies target_link_libraries(pj pjnath pjlib-util). This is canonical for Linux software.
I would like to make my project also work for Visual Studio. What is the canonical Windows way to set up this dependency? Should it be configured in some global Visual Studio setting? Or should PJSIP be in a subdirectory, and CMake told to invoke the correct build system itself?
To find dependent 3rd Party libraries, follow the CMake guide, http://www.cmake.org/Wiki/CMake:How_To_Find_Libraries
Generally speaking, CMake prefers absolute paths. During my evaluation of CMake, I found that it does not have a canonical way to reference dependent libraries in Visual Studio. Their message is that CMake should be run on every developer system in order to set up the build environment for that specific target station. Therefore I could never create a solution file directly from CMake that could be versioned because the paths would be absolute. It would be possible but only after modifying the CMake project files after creation.
I had labored over this issue many times as CMake software needed to be approved on our developer stations before the build system was created.
In the end, I had versioned modified CMakeLists.txt files for all our dependent projects that finds the correct canonical paths to locations and had the caveat that anyone that built (these were for dependent 3rd party libraries that only get built on version changes) must have CMake installed.
So I've been working on a game, and the sheer number of projects has become unmanageable. Enter NuGet.
I wanted to ensure my code would work on different devices, so I've been making these projects as Portable Class Libraries. I needed to use these on XBox, Windows, iOS, Android, and Silverlight. I created some custom custom SupportedFrameworks in C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETPortable\v4.0\Profile\Profile1\SupportedFrameworks
Specifically MonoAndroid and VSMonoTouch
I successfully turned one of these PCLs into a NuGet package, but when I try to add them to another PCL of the same profile I get this error:
Could not install package 'Framework.dll 1.0.0.0'. You are trying to install this package into a project that targets '.NETPortable,Version=v4.0,Profile=Profile1', but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.
The package folder was brought down and contains a folder named: portable-win+net40+MonoAndroid16+sl40+net10+wp+Xbox40 and indeed contains the requested dll. I am able to add this dll to my project manually, so I believe this may be a bug in NuGet. I investigated this online, and found the main fix was to update NuGet, because the newest version plays nicer with PCLs. I've updated, but to no avail.
Has anyone seen this before, or am I missing something obvious? Any help would be greatly appriated =)
Thanks,
Joshua
It looks like you are using ".NETFramework" for the identifier in the XML file you put in the Profile1 SupportedFrameworks folder. This was basically a hack to get iOS projects building on Windows, but with real support for that scenario you should change that identifier to MonoTouch. Then when you create the package it should use monotouch in place of net10 for the lib/portable-x+y+z folder.
Then, as #Deepak suggests, install the nightly build of NuGet. Then you should be able to install the NuGet package into your PCL project. If you do try this, please let me know whether it worked or not. :)