BinaryDistributionNotes - coin-or-foundation/tlc GitHub Wiki

Binary Distribution Committee Working Notes

Here is a running commentary on the process we used to arrive at the strawman proposal for the binary distribution project.

Ted's Additional Comments

  • Issues to be resolved
    • What code versions should we use?
      • "Stable"
      • Current
      • Both?
    • How should the compilation be done?
      • Peridically, by hand
      • Automatically, by script
    • What testing should be done before release?
    • How often should we do releases?
    • What platforms should be supported?
    • Should we put binaries on SVN?
    • What about installation scripts/wizards?
  • Suggestion: Manage the distribution of binaries just like any other project with an overall project manager and possibly sub-project managers for each architecture.
    • Trac page
    • Documentation/READMEs
  • Goals
    • Make it EASY
    • Limit confusion/options
    • Very good documentation
    • Should work for the most inexperienced of users

Modified strawman suggestion:

  • COIN
    • binaryDistribution
      • msvc6 - Optimized Build with Microsoft Visual C++ V6
        • README
        • LICENSE
        • AUTHORS
        • include (all include files in one directory)
        • lib
          • cbcLib.lib
          • cglLib.lib
          • clpLib.lib
          • coinLib.lib
          • osiCbcLib.lib
          • osiClpLib.lib
          • osiLib.lib
          • osiVolLib.lib
          • smiLib.lib
          • volLib.lib
        • bin
          • ClpMain.exe - this is the executable from building COIN\Clp\Test\ClpMain.cpp
    • msvc7 - Optimized Build with Microsoft Visual C++ Visual Studio .NET Version ?????
      • README
      • LICENSE
      • AUTHORS
      • include (all include files in one directory)
      • lib
        • cbcLib.lib
        • cglLib.lib
        • clpLib.lib
        • coinLib.lib
        • osiCbcLib.lib
        • osiClpLib.lib
        • osiLib.lib
        • osiVolLib.lib
        • smiLib.lib
        • volLib.lib
      • bin
        • ClpMain.exe - this is the executable from building COIN\Clp\Test\ClpMain.cpp
    • CYGWIN - Optimized cygwin build.
      • README
      • LICENSE
      • AUTHORS
      • include (all include files in one directory)
      • lib
        • libCbc.a
        • libCgl.a
        • libClp.a
        • libCoin.a
        • libOsi.a
        • libOsiCbc.a
        • libOsiClp.a
        • libOsiSym.a
        • libOsiVol.a
        • libVol.a
      • bin
        • ClpMain.exe - this is the executable from building COIN\Clp\Test\ClpMain.cpp
    • linux-i386-gcc3 - Optimized linux I386 gcc3 build.
      • README
      • LICENSE
      • AUTHORS
      • include (all include files in one directory)
      • lib
        • libCbc.a
        • libCgl.a
        • libClp.a
        • libCoin.a
        • libOsi.a
        • libOsiCbc.a
        • libOsiClp.a
        • libOsiSym.a
        • libOsiVol.a
        • libVol.a
      • bin
        • ClpMain.exe - this is the executable from building COIN\Clp\Test\ClpMain.cpp

Additional Suggestion:

I still think it would be more clear for users to have under the Binary Distributions root a w32 directory and then the zip files for each VS and cygwin. In other words:

  • COIN
    • Binary Distributions
      • win32
        • msvs6.zip
        • msvs7.zip
        • cygwin.zip

Ted's Additional Suggestions:

I think we are confusing matters by trying to put this into an overall file structure. I think what we are talking about is a Web page with a bunch of zip files listed. A user would simply download the appropriate zip file for his or her platform. We can name the zip files appropriately to reflect the platform, i.e.,

  • coin-win32-msvc6.zip
  • coin-win32-msvc7.zip
  • coin-win32-cygwin.zip
  • coin-linux-i386-gcc3.zip

JP's Additional Suggestions: JP agrees with Ted's zip file names.

In my experience, this sort of naming convention is pretty standard. Each zip file would then have identical file structure.

  • COIN/README
  • COIN/LICENSE
  • COIN/AUTHORS
  • COIN/include
  • COIN/lib
  • COIN/bin

I forget the standard files that are supposed to be included in every project (README, LICENSE, etc), but whatever they are, they should be reflected here. Is this a good simple answer?

JP's Response:

This unzipped file structure does not allow one to easily have more than one platform in the same file system I would suggest:

*coin-win32-msvc6-YyMmmDd.zip contains:

  • COIN/win32-msvs6/README
  • COIN/win32-msvs6/LICENSE
  • COIN/win32-msvs6/AUTHORS
  • COIN/win32-msvs6/include
  • COIN/win32-msvs6/lib
  • COIN/win32-msvs6/bin

*coin-win32-msvc7-YyMmmDd.zip contains:

  • COIN/win32-msvs7/README
  • COIN/win32-msvs7/LICENSE
  • COIN/win32-msvs7/AUTHORS
  • COIN/win32-msvs7/include
  • COIN/win32-msvs7/lib
  • COIN/win32-msvs7/bin

*coin-win32-cygwin-YyMmmDd.zip contains:

  • COIN/cygwin/README
  • COIN/cygwin/LICENSE
  • COIN/cygwin/AUTHORS
  • COIN/cygwin/include
  • COIN/cygwin/lib
  • COIN/cygwin/bin

*coin-linux-i386-gcc3-YyMmmDd.zip contains:

  • COIN/linux-i386-gcc3/README
  • COIN/linux-i386-gcc3/LICENSE
  • COIN/linux-i386-gcc3/AUTHORS
  • COIN/linux-i386-gcc3/include
  • COIN/linux-i386-gcc3/lib
  • COIN/linux-i386-gcc3/bin

With networked file systems and on windows one is likely to easily want more than one set of COIN binaries in the same file system.

The zip file contains an indication of the version of coin that it contains. (Since we don't have versions, it is the date of extraction from the repository.

Kipp's Response:

Right, the zip files are NOT part of the directory structure. My fault. We need to distinguish in our discussion whether we are talking about the directory structure that the user sees at the download Web page or the directory structure for the distribution that gets zipped. The current strawman is modified to reflect README, LICENSE, AUTHORS.

Using nmake for Windows distributions

When we talk on Tuesday I would like to revisit the possibility of using nmake makefiles for building the Windows distributions. I think there are several reasons for doing so.

  1. The nmake file is independent of the version of the Visual Studio IDE (JP -- this might prove useful for us if you build VC6 and I build VC7 -- we can avoid duplication of effort).

  2. We may also wish to distribute the nmake files. Microsoft distributes its C++ compiler for free (the C++ toolkit). This is the full-blown compiler, but without the IDE. An nmake file is very useful for folks who go this route.

  3. There was a recent posting to the COIN discussion list from someone wanting to use Coin with the Borland compiler. An nmake file might prove useful to this person since nmake is compiler independent.

At one point, you could import nmake into Visual Studio and it would build the corresponding project. I don't know if this is still true, nmake would prove useful to people wanting to build a Visual Studio project.

I have built the following nmake makefiles:

commonmakefile coinlibmakefile osilibmakefile clpmakefile osiclpmakefile osiglpkmakefile

I attach the commonmakefile and the coinlibmakefile to illustrate building the libraries.

I am willing to maintain these files.

Library Names

In the Linux and cygwin lib directories we use common nameing such as libCbc.a. In the windows library should we follow the same convention, i.e. libCbc.lib?

Comments on cross-platform builds

I think we will ultimately want to have automatic, cross-platform build scripts for the binaries, so it's probably worth thinking along those lines now. With automatic build scripts, we would be able to put out daily binary tarballs/zip files just like the daily source tarballs we currently distribute. This would allow us to quickly and easily migrate bug fixes into the binaries. Of course, these daily snapshots would be in addition to less frequently updated "stable" binaries. I looked into it and according to wikipedia, you can build MSVC-compatible libraries in MINGW as follows:

"MinGW can be used to develop DLLs which can later be used in Microsoft Visual Studio projects. This does however require the Microsoft LIB.EXE library manager, and LINK.EXE linker to create LIB-files, both of which are bundled with Visual Studio. Add the following line to the top of C:\msys\1.0\msys.bat to gain access to LIB and LINK (Visual Studio 2003):

call "C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Tools\vcvars32.bat"

DLL-files are created by using the -shared, --output-def and --out-implib paremeters when compiling with gcc, as shown in the MinGW FAQ."

It occurred to me that, in fact, it should be easy to use the native Microsoft compiler with the "make" command from MSys to build COIN using Microsoft's own compiler with the existing Unix Makefiles. In other words, rather than using using nmake and a separate makefile format, we could just use make with the standard Unix makefiles we already maintain and still get perfectly compatible libraries. This could essentially eliminate the need for nmake files, since anyone willing to compile on the command line with nmake would probably be willing to install Msys. It would also make automatic building very easy. Here is a page that describes how to use the Visual C++ toolkit from the command line.

http://msdn.microsoft.com/visualc/vctoolkit2003/default.aspx?pull=/library/en-us/dv_vstechart/html/vctoolkitcmd.asp

As far as maintenance of a single, cross-platform automated build environment, it seems to me this would be pretty ideal.

Another thing I discovered along the way is that the CYGWIN DLL is actually licensed under the GPL, which could be problematic, except that there is a specific exemption for linking with code already covered under another OSI-certified open source license, so I think we are OK.

http://cygwin.com/licensing.html

However, we should notify users that they cannot link to CYGWIN binaries unless their code is open source. FYI, here is another open source cross-platform make system a ran across:

http://www.cmake.org/HTML/Index.html

Draft Authors Files

The authors of the COIN modules can be found at the following URL's:

-- end of Draft Authors File --