<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>Besides getting truncated, newlines often get stripped from my emails.<BR>
I wish for working email..<BR><BR><BR>
<BLOCKQUOTE>
<HR id=EC_stopSpelling>
<BR>
From: jayk123@hotmail.com<BR>To: m3devel@elegosoft.com<BR>Subject: buildlocal vs. buildglobal vs. buildship explanation<BR>Date: Sat, 19 Jan 2008 00:47:11 +0000<BR><BR>
<META content="Microsoft SafeHTML" name=Generator>
<STYLE>
.ExternalClass .EC_hmmessage P
{padding:0px;}
.ExternalClass EC_body.hmmessage
{font-size:10pt;font-family:Tahoma;}
</STYLE>
I'm not sure I can explain this well or if I fully understand it.<BR><BR>
<BR>"Ship" means "Install"<BR><BR>
<BR>
Let's say your install is at<BR>c:\cm3<BR><BR>
<BR>and your source is at<BR><BR>
<BR>c:\dev2\cm3<BR><BR><BR>
(I would use dev, but Unix took it.)<BR><BR>
<BR>Depending on the state of things, you probably two of many things:<BR><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>
<BR>You will have more in \dev2\cm3\m3-libs\libm3\nt386.<BR><BR>
<BR>When you build stuff, you can use the installed dependencies or the just built dependencies.<BR><BR>
<BR>buildlocal uses the just built dependencies.<BR><BR>
<BR>buildglobal uses the installed dependencies<BR><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><BR>
and NOT <BR> build pkg1<BR> build pkg2<BR> ship pkg1<BR> ship pkg2<BR><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>
<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>
<BR>It only matters for certain types of changes, and then it can really matter.<BR><BR>
<BR>You might change the format of some compiler-produced runtime-consumed data.<BR><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>
<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>
<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>
<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>
<BR> - Jay<BR><BR></BLOCKQUOTE><br /><hr />Climb to the top of the charts! Play the word scramble challenge with star power. <a href='http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan' target='_new'>Play now!</a></body>
</html>