<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>I'm not sure I can explain this well or if I fully understand it.<BR>
<BR>
"Ship" means "Install"<BR>
Let's say your install is at<BR>
c:\cm3<BR>
<BR>and your source is at<BR>
<BR>c:\dev2\cm3<BR>
<BR>(I would use dev, but Unix took it.)<BR>
<BR>Depending on the state of things, you probably two of many things:<BR>
<BR>c:\cm3\pkg\libm3\nt386\libm3.lib<BR>c:\cm3\pkg\libm3\nt386\libm3.dll<BR>c:\dev2\cm3\m3-libs\libm3\nt386\libm3.lib<BR>c:\dev2\cm3\m3-libs\libm3\nt386\libm3.dll<BR>
<BR>
You will have more in \dev2\cm3\m3-libs\libm3\nt386.<BR>
<BR>When you build stuff, you can use the installed dependencies or the just built dependencies.<BR>
<BR>buildlocal uses the just built dependencies.<BR>
<BR>buildglobal uses the installed dependencies<BR>
<BR>buildship build and ships (installs) each directory<BR>It does it in one pass:<BR> buildship pkg1 pkg1<BR> => build pkg1<BR> ship pkg1<BR> build pkg2<BR> ship pkg2<BR>
<BR>and NOT <BR> build pkg1<BR> build pkg2<BR> ship pkg1<BR> ship pkg2<BR>
<BR>You may only ship/install outputs that are builtglobal.<BR>Outputs are presumed to only be valid if "amidst" dependencies that<BR>match the declarations and such they were built against -- i.e. the headers, in C.<BR>
<BR>If you are starting with a minimal install, with just m3core and libm3, then you must<BR>buildship and you must do it in dependency order. (I just derived this rule, might be wrong.)<BR>
<BR>It only matters for certain types of changes, and then it can really matter.<BR>
<BR>You might change the format of some compiler-produced runtime-consumed data.<BR>
<BR>You might have a bunch of .sos/.dlls. They can only work with each other<BR> if they match in certain ways. Again, ways which don't change that often,<BR> but sometimes do -- like changing public types.<BR>
<BR>
This is why you can get "fingerprint mismatches" -- when code has different<BR>
notions as to a type definition.<BR>
I guess that is when the "ship checking" is either inadequate or circumvented.<BR>
<BR>
It makes me wonder.<BR>
What if there was a compilation mode in which all types were opaque.<BR>
If all record field access to records defined in other packages were implemented<BR>
by non-inlined dynamically linked getter/setter functions.<BR>
It would be slow.<BR>
<BR>
It would be much more amenable to type changes -- removal/renaming/retyping of<BR>
existing fields being the remaining "problems".<BR>
Actually adding would be a problem too, clients of the new could not run against the old.<BR>
<BR> - Jay<BR><BR><br /><hr />Shed those extra pounds with MSN and The Biggest Loser!! <a href='http://biggestloser.msn.com/' target='_new'>Learn more.</a></body>
</html>