[M3devel] FW: buildlocal vs. buildglobal vs. buildship explanation

[Jay]

No electronic source? Wow that stinks.
 
cm3 = cm3 -build = "buildglobal"
buildglobal != buildship
buildglobal means to build against global, but not to ship
It is the normal thing to do, I think, when you aren't changing "too much".
If you are building something for which all dependencies have already shipped and aren't changing, a typical little utility.
  Or if you aren't changing the fingerprints of any public types, I think. Certainly if you are only changing code. Not sure about
   changing the revelations of partially opaque types.
But maybe that's a gross simplification of what kind of development occurs.
 
The doubling is mostly good.
It fixes a problem well.
However, I have some criticism, perhaps rooted in an inadequate understanding, I admit.
 
  1) the ban on shipping having used overrides seems overly strict -- what if the fingerprints match?
 
  2) perhaps some global fingerprint (hash) can be inserted after TARGET, enabling multiple versions to coexist in the same install root? But maybe that's just what you create a seperate install root for, since, I guess bin has to match pkg, so the whole tree is "ruined" anyway. x/* vs. */x in terms of directory layout. And maybe such a fingerprint would need too many bits to be reliable and then be annoyingly long.
 
  3) This is the one I have the most confident understanding of -- as long as you are shipping "everything" all at once, I think shipping with overrides is just fine. There is a question as to what "everything" is.
 
 
 - Jay


Date: Fri, 18 Jan 2008 20:35:55 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: Re: [M3devel] FW: buildlocal vs. buildglobal vs. buildship explanation

Jay:
 
I understand the cm3 package and build system.  I just didn't know what "buildglobal" meant.
 
>From your explanation, I take it that buildglobal = (cm3 -build) + (cm3 -ship) together on a per package basis.
If this is true, then buildglobal == buildship; i.e., there is no difference.
 
You stated that the default of the script is buildlocal and I gather buildlocal = (cm3 -build -override).  If so, I now see why I was confused.  The default for the compiler is not to include the overrides file (at least that is my recollection from the 4.1 days--maybe its different now).  So in my way of thinking, buildlocal = (cm3 -build) without doing any shipping.  Perhaps a more self-explanatory option name for (cm3 -build -override) would be "buildoverrides".  The system won't let you ship a package built with overrides, so that is why I ran into trouble trying to get everything installed using do-cm3-std without passing the buildship or buildglobal option.
 
I've always liked the cm3 way of having a private source package tree where folks work on the code and then having a separate public package tree where folks "ship" their finished product.  Yes, I know you wind up having the code in two places, but then you can "clean" up the derived files in your private tree to save space if needed.
 
The old "reactor" documentation did a fairly good job of explaining the cm3 package concept and the idea of public and private repositories.  I'm attempting to convert this document into something we can put back in the cvs repository.  I have to take out all the trademarks and replace the graphics etc so it is a painful process without the original electronic source.  I've resorted to scanning it in via a scanner and making edits.
 
Regards,
Randy>>> Jay <jayk123 at hotmail.com> 1/18/2008 7:56 PM >>>one more try darnit....     


From: jayk123 at hotmail.comTo: jayk123 at hotmail.comSubject: buildlocal vs.Date: Sat, 19 Jan 2008 00:55:31 +0000

  "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.lib         c:\cm3\pkg\libm3\nt386\libm3.dll         c:\dev2\cm3\m3-libs\libm3\nt386\libm3.lib         c:\dev2\cm3\m3-libs\libm3\nt386\libm3.dll               You will have much 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 directory         It does it 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 that      match 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 must      buildship and you must do it in dependncy order.            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.             - Jay   

Climb to the top of the charts! Play the word scramble challenge with star power. Play now! 
_________________________________________________________________
Climb to the top of the charts!  Play the word scramble challenge with star power.
http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080119/9fc867cf/attachment-0002.html>