[RFC][Win32] Abandoning depency management in favor of nugget packages
#1
This will be a bit light on content, is at work but thought it could be nice to get a discussion going.

Nuget for C++ libraries is starting to become a reality and this could help us/you guys to abandon maintaining a dependency repository for Win32. It would ofc take a fair bit of work to get all the packages needed available in the nuget repository.

You can learn more about nuget
http://blogs.msdn.com/b/vcblog/archive/2...for-c.aspx

currently available packages
http://www.nuget.org/profiles/coapp/

Authoring tools for packages
http://coapp.org/index.html

And to finish up, a quick presentation of how it's used to build zlib(about 20 minutes and well worth watching)
http://channel9.msdn.com/Events/GoingNat...-Libraries

Let the discussion begin! Smile
Reply
#2
wow! windows has finally discovered the wonders of the 90s!
Reply
#3
I've used NuGet a few times in .NET applications but only really from the "user" side (I only once published a NuGet package in our companies NuGet repository) and I have to admit it's pretty sweet.

The main problem I see in combination with XBMC is that we usually use a very specific version of a library and in most cases not the most recent one (for good reasons). I'm not sure how that is possible/handled by NuGet. Furthermore we couldn't push libraries that we need to NuGet because we don't want to (and can't) maintain them so it would be up to the maintainers of those libraries to do that.

In the end that would probably leave us with two ways to get/handle dependencies on win32 which might become confusing and would also require to maintain both of them. I'm not saying I don't like the idea but it only really makes sense if there already are a lot of libraries used by XBMC available as NuGet packages (in the necessary version).
Always read the online manual (wiki), FAQ (wiki) and search the forum before posting.
Do not e-mail Team Kodi members directly asking for support. Read/follow the forum rules (wiki).
Please read the pages on troubleshooting (wiki) and bug reporting (wiki) before reporting issues.
Reply
#4
Versioning shouldn't be a big problem, as long as it's provided you can install an older version or afaik, pin it to that version.

yeah Spiff, I think someone felt envy when ruby gems was the hot thing and wanted to have that, admittedly they've done a good job for the .net and javascript side of it.

I'll try and look at how much work it would be to maintain packages and try to get working on it to test it out, hopefully will have some time over the weekend
Reply
#5
@Trem: The problem with older versions might be that they won't ever make it into a NuGet repository because they may already be very old.

EDIT: Obviously XBMC could setup its own NuGet repository and upload all its dependencies there. That would save the extra work to write scripts for the dependency download etc.
Always read the online manual (wiki), FAQ (wiki) and search the forum before posting.
Do not e-mail Team Kodi members directly asking for support. Read/follow the forum rules (wiki).
Please read the pages on troubleshooting (wiki) and bug reporting (wiki) before reporting issues.
Reply
#6
just setup our own NuGet repository and use that, we have the servers and we already squirrel away any tarballs we need to build in the mirrors.
Reply
#7
Quite some time ago I looked for a package manager on windows since I wanted to get rid of our custom scripts. Unfortunately nothing was very major. I don't know NuGet but if its works and doesn't make more effort than our current solution why not. But an own repo is a must.
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.
Reply
#8
Had a bit less free time than expected, few notes so far trying to build a few packages
1. When using the packaged library it shouldn't actually be listed in the linker>additional includes settings, this causes a file not found error.

2. Coapp(the packaging tool) doesn't like the current configuration names with parenthesis, package build fails

I'll keep poking at this, won't promise a timetable this time though Smile
The janitor, cleaner of cruft, defender of style. Also known as the unfunny guy that doesn't understand signatures.
Reply

Logout Mark Read Team Forum Stats Members Help
[RFC][Win32] Abandoning depency management in favor of nugget packages0