coapp-developers team mailing list archive

[Garrett Serack <garretts@xxxxxxxxxxxxx>]

Further to the conversation we had last week at the weekly conference call,
here's what I have for how coapp composes developer packages and how library
packages work.

We can go over this more at the conf call online tomorrow.

============================================================================

============================================================================
Assumptions:
- nearly nothing here is "forced"; we're aiming for solid "best practices"

    - let's define "CRT" as a given "compiler::runtime library".
    The significant ones that come to mind currently:

        - VC6 - Visual C++ 6.0
            - (may depend on msvcrt, mfc dlls?)

        - VC7 - Visual C++ 7.0 (aka VC2002, aka VS.NET)
            -- depends on MSVCR70 and friends

        - VC71 - Visual C++ 7.1 (aka VC2003, aka VS.NET 2003)
            -- depends on MSVCR71 and friends

        - VC8 - Visual C++ 8 (aka VC2005, aka VS 2005)
            -- depends on MSVCR80 and friends

        - VC9 - Visual C++ 9 (aka VC2008, aka VS 2008)
            -- depends on MSVCR90 and friends

        - VC10 - Visual C++ 10 (aka VC2010, aka VS 2010,  aka DEV10)
            -- depends on MSVCR100 and friends

        - VC11 - Visual C++ 11 (aka VC????, aka VS??? aka DEV11)
            -- depends on ???? and friends

        - MinGW4 - GCC/MinGW compiler suite (currently gcc 4.6)
           -- depends on msvcrt, libgcc/libstdc++
              - Should we call it MinGW46? Gcc4? Gcc46? something else?
              - When is the binary compatibility going to break?

        - packages can also be 'flavorless' -- ie, they don't have a CRT
          distinction at all (and don't depend on a flavored package)


    - generally speaking, we will have 1 package per "CRT" , per architecture.

    - there should be an equivalent -dev package per library package

    - in order to save on insane duplication, there should be a -dev-common pkg
      that has the headers/docs/non-arch-specific files that the -dev package
      can have a dependency to.


Inside the $COAPPROOT folder (ie, c:\apps ) :  we will have a general layout
that looks like this:

c:\apps\
    lib\
        x86\
            vc6\
            vc7\
            vc71\
            vc8\
            vc9\
            vc10\
            vc11\
            gcc46\
        x64\
            vc6\
            vc7\
            vc71\
            vc8\
            vc9\
            vc10\
            vc11\
            gcc46\

    include\

    assemblies\
        anycpu\
        x86\
        x64\


for a given library 'foo', packages:

foo-1.2.3.4-x86-0000000000000000.msi
    (flavorless shared library package x86)
foo-1.2.3.4-x64-0000000000000000.msi
    (flavorless shared library package x64)

foo[vc10]-1.2.3.4-x86-0000000000000000.msi
    (vc10 flavored shared library package x86)
    installs to c:\apps\.installed\foocorp\foo[vc10]-1.2.3.4-x86\

foo[vc10]-1.2.3.4-x64-0000000000000000.msi
    (vc10 flavored shared library package x64)
    installs to c:\apps\.installed\foocorp\foo[vc10]-1.2.3.4-x64\

foo-dev-1.2.3.4-x86-0000000000000000.msi
    (flavorless developer library package x86)
    contains:
        .\lib
            foo.lib
            foo-static.lib

foo-dev-1.2.3.4-x64-0000000000000000.msi
    (flavorless developer library package x64)

foo-dev[vc10]-1.2.3.4-x86-0000000000000000.msi
    (vc10 flavored developer library package x86)
foo-dev[vc10]-1.2.3.4-x64-0000000000000000.msi
    (vc10 flavored developer library package x64)

foo-dev-common-1.2.3.4-any-0000000000000000.msi
    (common/shared headers, docs,etc for developer library package)
    contains:
        .\include


all the -dev-n.n.n.n-arch packages have a dependency on -dev-common-n.n.n.n-any

c:\apps\
    lib\
        x86\                        (symlinks to)
            foo.lib
                =>  $INSTALLED\foocorp\foo-1.2.3.4-x86\lib\foo.lib
            foo-static.lib
                =>  $INSTALLED\foocorp\foo-1.2.3.4-x86\lib\foo-static.lib
            foo-1.2.3.4.lib
                =>  $INSTALLED\foocorp\foo-1.2.3.4-x86\lib\foo.lib
            foo-1.2.3.4-static.lib
                =>  $INSTALLED\foocorp\foo-1.2.3.4-x86\lib\foo-static.lib

            vc6\
            vc7\
            vc71\
            vc8\
            vc9\
            vc10\
                foo.lib                 (`active` version)
                    =>  $INSTALLED\foocorp\foo[vc10]-1.2.3.4-x86\lib\foo.lib
                foo-static.lib          (`active` version)
                    =>  $INSTALLED\foocorp\foo[vc10]-1.2.3.4-x86\lib\foo-static.lib
                foo-1.2.3.4.lib         (version-specific)
                    =>  $INSTALLED\foocorp\foo[vc10]-1.2.3.4-x86\lib\foo.lib
                foo-static-1.2.3.4.lib  (version-specific)
                    =>  $INSTALLED\foocorp\foo[vc10]-1.2.3.4-x86\lib\foo-static.lib

            vc11\
            gcc46\

        x64\
            vc6\
            vc7\
            vc71\
            vc8\
            vc9\
            vc10\
            vc11\
            gcc46\

    include\
        foo\             ('active' version)
            => $INSTALLED\foocorp\foo-dev-common-1.2.3.4-any\include\
        foo-1.2.3.4\     (version-specific)
            => $INSTALLED\foocorp\foo-dev-common-1.2.3.4-any\include\


Since .NET libraries don't need include files and .lib files, they should be a
lot simpler:

assemblies\

        anycpu\
            foodotnet.dll      ('active' version)
                => $INSTALLED\foocorp\foo-1.2.3.4-any\foodotnet.dll
            foodotnet-1.2.3.4\
                foodotnet.dll  (version-specific)
                    => $INSTALLED\foocorp\foo-1.2.3.4-any\foodotnet.dll
        x86\
            foodotnet.dll
            foodotnet-1.2.3.4\
                foodotnet.dll

        x64\
            foodotnet.dll
            foodotnet-1.2.3.4\
                foodotnet.dll