[M3devel] buildlocal vs. buildglobal vs. buildship explanation

[Jay]

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