I have a legacy C++ project that targets both Windows and macOS which is still exported and consumed as a .zip file of prebuilt libraries and include headers. I was looking into instead packaging them with NuGet as a native NuGet package. However, I haven't found any reference on how to create NuGet packages that ship prebuilt libraries and target multiple platforms.
Does anyone know whether NuGet supports such a usecase? If it does, is there any reference and real-world example showing how this sort of package can be created?
Related
I'm porting some existing (c++) Visual Studio projects to linux that leverage native nuget packages. The linux projects use cmake and the CMakeLists.txt file will either be hand generator or converted from the vs project file using a conversion tool like cmake-convertor. nuget package information is stored in package.config files and installed directly per cmake with a nuget install option within the CMakeLists.txt.
My dilemma is defining the compile and link information for each installed nuget package, as each one could follow its own convention where headers reside, additional lib dependencies, etc. On windows, this information is stored in .targets file, which is also part of the nuget package. Is there a way to parse this file when cmake runs?
How can I install a nuget package system-wide on visual studio 2015?
I mean, yeah, you can install nuget packages per-project and per-solution... but, is it possible to install them system-wide so they'll be available for sources using vs2015 compiler?
Right now I'm coding some swig c++ modules to be used on python with cmake and having these libraries available system-wide so I can include them like any other system header would be quite convenient.
Just to clarify, the generated project by cmake will be ninja(using vs compiler)+ST (no package manager involved)... but still I'd like to be able of using the goodies provided by nuget to have my library set ready to be used by the swig modules
Nuget package management system does not have a "system-wide" install mode.
Downloaded packages are cached, so that you are not forced to re-download them each time for each project/solution referencing them.
You can also specify a path where to put the packages, but as far as I know for C++ projects this has some drawbacks, including the fact that project files are injected with *.props file paths relative to the solution, that causes Nuget system to be hardly usable from same projects included in different solutions at different path levels.
It seems that Microsoft is moving toward a different package manager for C++ native projects, you may want to look at VCPKG on Github.
I'm very new to C++ world, so please, sorry for such a dummy question. I googled a little, but wasn't able to find a proper answer.
My question is fairly simple - how should I use libraries in C++ world. For example in Java - there is maven and gradle for this task. In Python - I use pip. In javascript npm and bower do all the stuff. In C# you use nuget or just adding DLL lib to your project. But looks like in C++ things isn't such easy.
I found a tool, called conan but amount of libraries they have is pretty small and does not include any what I'm looking for.
So, for example - I want to use nlp lib meta but it seems like they don't provide any installer files. So I assume I need to get sources from Github. Should I compile them and then try to add the compiled files to my project or do I need to have a lib folder in my project, and put meta's sources in those folder and after operate with meta's sources as they are in my project?
My question isn't about how to install specific meta lib, but more from the source management point of view. If I use Visual Studio on Windows for example, but my colleague will be coding Clion under Linux. And I don't know the proper way of managing dependencies in C++ world.
C++ doesn't have anything like pip or npm/bower. I don't know if maven or gradle can be persuaded to handle C++ libraries.
In general, you are going to have to end up with
Header files in a directory somewhere
library files (either static libraries, or DLLs/shared objects). If the library is a header-only library like some of the boost libraries, then you won't need this.
You get hold of the library files, either by building them on your machine (typical for open source projects, and projects aimed at Linux platforms), or by downloading the pre-compiled binaries (typical for Windows libraries, particularly paid-for).
Hopefully, the instructions for building the library will be included on the library website. As noted in the comments, 'meta' seems to be quite good at that.
When you try to compile with the library, you may need a command line option (eg -I) to specify the directory containing the header files, and you may need a linker option (eg -l) to tell the linker to link against your library.
Cget will install any package that uses standard cmake, and works for linux and windows. It has shorten syntax for getting packages directly from github(such as cget install google/googletest).
In addition, dependencies can be automatically downloaded as well by listing them in a requirements.txt file.
There is also recipes for installing non-cmake packages and the repository here has over 300 libraries(and growing). So you can install curl with just cget install pfultz2/cget-recipes curl.
C++ sadly has no package manager for libraries. Some are out there and try to be one which are still small and scattered though (like conan).
In linux you have some "-dev" packages you can install but they are also not "all".
You most likely end up downloading them yourself. Next though is you have the problem of integrating those libraries. You have different build systems per operating system so you have to see how you build c++ files.
Like in windows with Visual studio you have to get a visual studio project or a nmake compatible makefile to build the libraries and then add them to your project. Same with linux makefiles.
There are several build frameworks who are higher level like cmake. The example you have in your post also works with CMake. So integrating that one into a cmake build environment would be easier but this only applies for other libraries also trying to use/integrate cmake build environments to it (e.g. boost / qt is doing this).
Yeah these are some thoughts to this. Sadly there won't be an easy/definitive answer to this because there is no real central c++ packet repository which is also integrated into a build system.
It appears to me that the Crascit/DownloadProject could be of help in your situation. It provides CMake plugins for downloading projects from a git repository by specifying tags, etc. Then you can use add_custom_target to run commands you need to have the project built.
There are a number of popular C++ released via nuget packages.
You can search on the gallery for them, usually using the native or c++ tags. Obviously you need a nuget manager for your OS, and I'm pretty sure that the C++ nuget packages rely on MSBuild for a lot of the grunt work, so you may have trouble getting a non-Visual Studio oriented setup to work nicely.
Also Gradle actually does have some support for native dependencies as well. I had a look at little while ago but the work on it was curtailed because the support for VS 2015 was lacking.
I recommend vcpkg for cross platform development. It has a number of IDE integrations. GitHub project is here.
I do cross platform development using tools like CMake, Visual Studio, WSL. vcpkg was incredibly helpful.
I started new project... in cureent time it's just "source package manager" you can provide some source code on github and then it will be just copy to you project (based on cmake + auto generating cmake files)
So links here:
https://github.com/wsjcpp/wsjcpp
I am quite new to VC++ and Boost.
My problem is that I want to use Boost 1.56.0 in my VC++ Visual Studio 2013 project (so I use vc120).
I have installed Boost via NuGet (https://www.nuget.org/packages/boost/). Everything seems to be okay, but when I try to build my project it says:
Fatal error LNK1104: Cannot open file "libboost_thread-vc120-mt-gd-1_56.lib".
Do you know where exactly the problem is and how I can fix it?
I thought installing a package using NuGet will do the whole job to get things working on its own.
I know that the linker can't find the lib file (actually there was no build process at all). But I don't know how I can fix this issue.
I think it is not a good idea to manually compile Boost with VC120 and add the lib folder to the additional paths of the linker. Why should I use NuGet then?
Any help is welcome - I am trying and searching the internet for so many hours now and I couldn't fix the problem.
Thank you,
Stefan
As mentioned before, Boost Nuget can't contain all possible compiled libraries for all possible configuration and compiler versions. However, there are separete precompiled Nuget packages and also source packages. Here is a list of all 1.56.0 Boost Nuget packages https://getboost.codeplex.com/releases/view/126256
In your case, I would suggest to use precompiled boost_thread-vc120.1.56.0. Not 1.57 yet!
If you are lazy, you can also use boost-vc120.1.56.0 which depends on all precompiled Boost libraries for Visual Studio 2013.
It seems that the latest version of NuGet for boost doesn't include every lib and dll files package (source).
You should install boost_thread altogether.
BlueGo is a tool which builds Boost using Visual Studio 2010/12/13. You just have to start the application, select your configuration and hit the Build button- everything else works automatically.
It can be downloaded here: https://bitbucket.org/Vertexwahn/bluego
Since the NuGet packet of Boost does not contain the lib files anymore, because the package is getting to big, I have decided to build Boost by my own.
I followed this instructions: Build Boost for Visual Studio - also read the second post!
I saw it too late but maybe it is helpful for somebody else:
There are pre-build Boost installer!
Here you can download an installer, which will install Boost (of specific version) for 32/64 bit (depending on which file you choose). There are also already different versions (vc100, vc110, vc120) available.
The problem when you use NuGet is, that you have
Install the Boost package (to get the source files)
Install the lib files (see the link Marco A. provided)
This can be very cumbersome since not all libraries of Boost are available. E.g. the lib files of ASIO were missing. So if you need them you have to compile it again by your own. So you mess up your project with NuGet packages and self-compiled boost libs. If NuGet provides everything you need I would use the NuGet way.
Finally, as I said I need the ASIO lib and therefore I have finally compiled Boost by my own. It seemed so easy to just use a NuGet Package.
Thank you all for your help.
I've been working on various open-source projects, which involve the following C++ libraries (& others):
MuPDF
Boost
FreeType
GTKmm
hummus PDF libraries
LibTiff
LibXML2
Wt xpdf
xpdf
Poppler
ZLib
It often takes a long time to configure these libraries, when setting them up on a clean machine. Is there a way to automate the grabbing of all dependencies on a windows machine?
The closest I've found is CMake, which checks to make sure you have the dependencies installed/extracted before generating your project files. But I haven't found anything for Windows which can parse the list of dependencies and then download+install the required versions.
Please recommend a package manager for Windows with up-to-date C++ libraries.
Vcpkg, a Microsoft open source project, helps you get C and C++ libraries on Windows.
Take a look at the Hunter package manager when you already use CMake to setup your project. It automatically downloads and builds your dependencies whith only a few lines of extra cmake code. Hunter is based on cmake export and import targets.
For example if you want to use the GoogleTest library in your cmake based project you would add the following lines to your root CMakeLists.txt
# file root CMakeLists.txt
cmake_minimum_required(VERSION 3.0)
# To get hunter you need to download and include a single cmake file
# see documentation for correct name
include("../gate.cmake")
project(download-gtest)
# set the location of all your hunter-packages
set( HUNTER_ROOT_DIR C:/CppLibraries/HunterLibraries )
# This call automaticall downloads and compiles gtest the first time
# cmake is executed. The library is then cached in the HUNTER_ROOT_DIR
hunter_add_package(GTest)
# Now the GTest library can be found and linked to by your own project
find_package(GTest CONFIG REQUIRED)
add_executable(foo foo.cpp)
target_link_libraries(foo GTest::main)
Not all the libraries you list are available as "hunter-packages" but the project is open source so you can create hunter-packages for your dependencies and commit them to the project. Here is a list of libraries that are already available as hunter packages.
This will not solve all your problems out of the box because you have to create hunter-packages for your dependencies. But the existing framework already does a lot of the work and it is better to use that instead of having a half-assed selfmade solution.
Biicode is a new dependency manager for C++. It also has a few libraries that you listed. Biicode automatically scans your source files for dependencies, downloads and builds them. See here for a very cool example that includes Freeglut.
What I've found:
Closest thing to what I'm looking for:
NuGET
Unfortunately it doesn't have any of the libraries I require in its repository.
So I ended getting most of the libraries from the KDE4windows project and custom building the rest.
Npackd is a package manager for Windows. There is a default repository for C++ libraries and also a third party repository for Visual Studio 2010 64 bit libraries. Boost and zlib are already in the default repository. If you decide to use Npackd, you could file an issue if you need other libraries.
Windows does not have a package manager. Go to the libraries' website and download the Windows builds if they provide any.
There are some alternatives, but not without drawbacks:
Cygwin: provides a nice package manager, but all binaries are built for Cygwin, which means they run slower than their native equivalent, any apps using them will link to the Cygwin DLL, and you're stuck with that license. Also the use of the native Win32 API is sometimes troublesome due to incompatibility with the POSIX emulation offered. Only for GCC.
MinGW-get: is a package manager for the MinGW.org compiler. These are native Win32 binaries, but only for use with MinGW's GCC.
There is no package manager or slightly equivalent thing for anything Visual Studio or MinGW-w64 related.
There is no package management on Windows. On Windows developers typically use full-blown everything-and-the-kitchen-sink development environments and produce monolithic applications themselves, shipped with all dependencies.