Visual Studio nuget support for ogre/ogredeps
Posted: Mon Jan 26, 2015 4:53 am
Hello,
I have been experimenting with CoApp (http://coapp.org) autopackage powershell tools for creating native nuget packages. For the purpose of my own applications the use of nuget packages for ogre binaries could simplify the setting of Visual C++ project properties across multiple workstations without including the binaries themselves in source control. As a result of this experimentation it has occurred to me that the ogre project itself could potentially benefit from this endeavor and I would like to invite discussion here regarding the matter.
For those unfamiliar with nuget and the coapp tools, I will attempt to breifly describe their utility here.
NuGet functions as a package management utility for development projects. Most often this occurs in the form of packages containing .NET assemblies to be referenced by other .NET projects. The NuSpec NuGet package specification allows for packaging multiple runtime versions of the packaged assemblies (e.g. net40 for .NET 4.0, net45 for .NET4.5, wp7 for Windows Phone 7, etc.).
In short, when adding a dependency package to a project that package is extracted (.nupkg is basically a zip archive) to $(SolutionDir)\packages\packagename-version (e.g. $(SolutionDir)\packages\EntityFramework-6.0.2). Managed projects within the solution which must reference this library then have project references added by relative path to the platform-appropriate assemblies within that directory.
Additionally, the spec allows for packaging native assets. For Visual C++ projects it's not simply a matter of pointing the vcxproj to the DLL(s) you want to reference; you also need include path(s) and lib files for linking. For multiple platforms and build configurations these settings can be tedious to introduce and maintain on a single development machine, let alone some workstation-agnostic path specification for an entire team of developers. NuGet handles this by utilizing Visual Studio props and targets files for native packages. However, creating and maintaining these props and targets files can be quite tedious as well.
Enter CoApp...
It is my understanding that the CoApp project originally came to exist in response to a desire among certain parties within Microsoft to have Windows-compatible open source libraries available as NuGet packages. This would allow a developer using Visual C++ to consume openssl, zlib, etc in their projects with only a couple of mouse clicks, rather than the grind of manually configuring project properties.
The CoApp Developer Tools set of powershell utilities and the autopkg file specification greatly enhances the packaging process for native NuGet packages. With a single autopkg file we can create multiple packages for a library, separating the runtime DLLs, development headers and lib files, debugging symbols, sources, samples, and so on. Additionally, the autopkg format supports "pivoting" on conditions such as debug/release configuration, x86/x64/arm platform, desktop/winrt runtimes, Visual Studio version (for msvc runtime versions), and any custom pivots we can choose to define.
So how does this matter to Ogre?
I am currently working to produce these CoApp-built native NuGet packages to reference in my native projects. However, I do not believe that it would be appropriate for me or my organization to publish these packages to a publicly available NuGet package feed as I am not a member of the official Ogre Team. I would like to work with members of community and the team to create a process by which the packages can be produced and published automatically by the team, for use by Visual Studio users. Additionally, for those who modify and build their own customized ogre source locally, these autopkg scripts could easily be made configurable (as part of cmake perhaps) to enable publishing your own custom ogre packages to your own custom package feed.
What is required to implement all of this stuff?
I would like to create autopkg files for the complete Ogre feature set which is available on Windows. It is my belief that packages should be created on feature boundaries (e.g. OgreMain, OIS, RenderSystem_Direct3D11, Plugin_Foo, etc.) This will allow API consumers to install only the packages containing the features they want. Ultimately, it may be useful to have the cmake-generated visual studio projects consume at least some of the dependencies in ogredeps from packages already available on nuget.org or other such feeds.
Where I currently most need assistance in this endeavor is with:
[*] Establishing feature boundaries. Which includes, libs, DLLs belong to which features?
[*] Designing and creating build automation for packaging. This could be particularly challenging if the community desires packages to be built for multiple versions of visual studio. It is at least challenging to build for multiple platforms as even for a particular version of Visual Studio cmake only generates projects for one of x86/x64/arm. So packaging binaries for all three targets requires three passes of cmake and build (both debug and release).
Man that's a lot of words..
If you've gotten this far I appreciate your patience. This effort seems to me one which could provide considerable value to the community if implemented properly. Not only can arbitrary developers include ogre in their projects via the nuget package manager, but organizations customizing ogre could consume updates easily while avoiding sticky subjects like DLLs in source control or network drop locations.
At this time I would like to invite comments and discussion on the subject.
Thank you for your time and attention.
I have been experimenting with CoApp (http://coapp.org) autopackage powershell tools for creating native nuget packages. For the purpose of my own applications the use of nuget packages for ogre binaries could simplify the setting of Visual C++ project properties across multiple workstations without including the binaries themselves in source control. As a result of this experimentation it has occurred to me that the ogre project itself could potentially benefit from this endeavor and I would like to invite discussion here regarding the matter.
For those unfamiliar with nuget and the coapp tools, I will attempt to breifly describe their utility here.
NuGet functions as a package management utility for development projects. Most often this occurs in the form of packages containing .NET assemblies to be referenced by other .NET projects. The NuSpec NuGet package specification allows for packaging multiple runtime versions of the packaged assemblies (e.g. net40 for .NET 4.0, net45 for .NET4.5, wp7 for Windows Phone 7, etc.).
In short, when adding a dependency package to a project that package is extracted (.nupkg is basically a zip archive) to $(SolutionDir)\packages\packagename-version (e.g. $(SolutionDir)\packages\EntityFramework-6.0.2). Managed projects within the solution which must reference this library then have project references added by relative path to the platform-appropriate assemblies within that directory.
Additionally, the spec allows for packaging native assets. For Visual C++ projects it's not simply a matter of pointing the vcxproj to the DLL(s) you want to reference; you also need include path(s) and lib files for linking. For multiple platforms and build configurations these settings can be tedious to introduce and maintain on a single development machine, let alone some workstation-agnostic path specification for an entire team of developers. NuGet handles this by utilizing Visual Studio props and targets files for native packages. However, creating and maintaining these props and targets files can be quite tedious as well.
Enter CoApp...
It is my understanding that the CoApp project originally came to exist in response to a desire among certain parties within Microsoft to have Windows-compatible open source libraries available as NuGet packages. This would allow a developer using Visual C++ to consume openssl, zlib, etc in their projects with only a couple of mouse clicks, rather than the grind of manually configuring project properties.
The CoApp Developer Tools set of powershell utilities and the autopkg file specification greatly enhances the packaging process for native NuGet packages. With a single autopkg file we can create multiple packages for a library, separating the runtime DLLs, development headers and lib files, debugging symbols, sources, samples, and so on. Additionally, the autopkg format supports "pivoting" on conditions such as debug/release configuration, x86/x64/arm platform, desktop/winrt runtimes, Visual Studio version (for msvc runtime versions), and any custom pivots we can choose to define.
So how does this matter to Ogre?
I am currently working to produce these CoApp-built native NuGet packages to reference in my native projects. However, I do not believe that it would be appropriate for me or my organization to publish these packages to a publicly available NuGet package feed as I am not a member of the official Ogre Team. I would like to work with members of community and the team to create a process by which the packages can be produced and published automatically by the team, for use by Visual Studio users. Additionally, for those who modify and build their own customized ogre source locally, these autopkg scripts could easily be made configurable (as part of cmake perhaps) to enable publishing your own custom ogre packages to your own custom package feed.
What is required to implement all of this stuff?
I would like to create autopkg files for the complete Ogre feature set which is available on Windows. It is my belief that packages should be created on feature boundaries (e.g. OgreMain, OIS, RenderSystem_Direct3D11, Plugin_Foo, etc.) This will allow API consumers to install only the packages containing the features they want. Ultimately, it may be useful to have the cmake-generated visual studio projects consume at least some of the dependencies in ogredeps from packages already available on nuget.org or other such feeds.
Where I currently most need assistance in this endeavor is with:
[*] Establishing feature boundaries. Which includes, libs, DLLs belong to which features?
[*] Designing and creating build automation for packaging. This could be particularly challenging if the community desires packages to be built for multiple versions of visual studio. It is at least challenging to build for multiple platforms as even for a particular version of Visual Studio cmake only generates projects for one of x86/x64/arm. So packaging binaries for all three targets requires three passes of cmake and build (both debug and release).
Man that's a lot of words..
If you've gotten this far I appreciate your patience. This effort seems to me one which could provide considerable value to the community if implemented properly. Not only can arbitrary developers include ogre in their projects via the nuget package manager, but organizations customizing ogre could consume updates easily while avoiding sticky subjects like DLLs in source control or network drop locations.
At this time I would like to invite comments and discussion on the subject.
Thank you for your time and attention.