0

Is there a preferred canonical way to distribute development packages (for example a DLL and headers) to developers (without source) on windows?

Coming from a Linux background my preference is split a project into three packages:

  • A runtime - e.g. libfoo-1.2.3.rpm containing /opt/foo/lib/libbar.so -> /opt/foo/lib/libbar.so.1.2.3
  • A development package - e.g. libfoo-devel.1.2.3.rpm containing /opt/foo/include/bar.h
  • A source package - e.g. libfoo.1.2.3-src.tgz containing the source and build machinery

I expect few windows developers would complain if given a zip file with a similar directory layout. E.g.

foo-devel.zip: 
   foo/doc/foobar.pdf
   foo/include/bar.h
   foo/lib/libbar.dll
   foo/lib/libbar.lib

for completeness only (off-topic) the run-time might be:

foo-runtime.zip: 
   foo/doc
   foo/lib/libbar.dll

or:

foo-runtime.msi - install libbar.dll to an appropriate location

However I am still curious if there is actually a preferred way of doing it?

For example should you provide a foo-devel.msi to be installed on the build machine?

I am not interested in the question what should go into the library. Anyone who is can see for example Distributing (native C++) libraries on windows

It still is worth bearing in mind ABI compatibility issues if providing a C++ interface rather than only a C one.

Another related question is Is there a best practices guide to distributing native C libraries for Windows?. That question covers the what but this one asks how.

Bruce Adams
  • 4,953
  • 4
  • 48
  • 111
  • 1
    There's no canonical way, and projects using your library will probably have to redistribute the dll anyways (installing in a system folder is begging for problems on windows), so I don't see the point in providing a separate runtime package for windows. –  Oct 26 '17 at 16:10
  • As a #1 developer (in the world) you usually get dlls as part of the source when you checkout the code from a repository in github, svn, tfs etc.. Same procedure works for #2 developer.. – boateng Oct 26 '17 at 16:21
  • @Felix Palmen As I said the runtime part is off topic. You are correct except for big runtimes like say for example directX – Bruce Adams Oct 26 '17 at 16:39
  • @numbtongue: As I said this is to distribute libraries for developers to use **without source**. When I am providing source I would probably provide a FindFoo.cmake as well as a link to github or wherever. – Bruce Adams Oct 26 '17 at 16:40
  • @BruceAdams so you're asking for a "*preferred way to distribute DLLs*", but the "*runtime*" (which is the package that would typically contain the binary library) is "off-topic"? Then this question makes little sense. Anyways, on Windows, just put all relevant stuff in a zip file and be done. –  Oct 26 '17 at 16:43
  • 1
    I'll rephrase as development packages. Its not just the DLL but also the headers, export/import libraries and documentation. – Bruce Adams Oct 26 '17 at 16:45
  • If it is appealing you could try with creation of a nugget approach.. It's like a zip file but for Visual Studio/.Net.. I usually download nuggets such as pdf generator or some third party piece of code/functionality or internal framework within my company (this is your case).. it's easy to distribute, much easier than your linux codes.. – boateng Oct 26 '17 at 17:01
  • Presumably you mean nuget (not nugget which googles badly!) - https://learn.microsoft.com/en-us/nuget/guides/install-nuget ? How widely is that used? – Bruce Adams Oct 26 '17 at 17:08
  • Yes, it's a weird name or what? Very widely, can't go wrong: https://stackoverflow.com/questions/18113223/how-should-i-use-nuget-for-internal-enterprise-development – boateng Oct 26 '17 at 17:41
  • This being C++, there is no preferred way to do *anything* pertaining the tool chain. With that out if the way, consider using a package manager. Vcpkg and NuGet are promising, not because they are inherently good, but because everyone uses them. Vcpkg started out as a tool to distribute native modules. NuGet used to be .NET-only, but can deliver native modules as well. – IInspectable Oct 26 '17 at 20:01

1 Answers1

0

The canonical (to an extent) way of distributing redistributable files on Windows is Windows Installer Merge Module (msm). It is intended to be integrated into another Windows Installer (msi) package. DLL should go there as they are files needed at runtime.

As for development files (e.g. headers, libraries, etc), there is no standard way of organizing them in the file system on Windows. Therefore, it could be a simple archive or an msi package. For an msi package, it makes sense to not require an admin account to install it.

A.K.
  • 839
  • 6
  • 13