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
_______________________________________________
Mailing list: https://launchpad.net/~coapp-developers
Post to : coapp-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~coapp-developers
More help : https://help.launchpad.net/ListHelp
