<html><body bgcolor="#FFFFFF"><div>The system used/uses symlinks under the covers. I don't think cm3 historically supported shared libs on hpux probably because the bundled compiler does not. Granted my exposure to hpux is only in recent times. 'standalone' as you define is useful but I think that reason isn't applicable to anything 'within cm3 itself'. Maybe more to say later. In particular I think this design we have is flawed. It's goals are good but can be better achieved slightly differently. In particular the unshipped and shipped directory layout should be 'the same' but just differently rooted. Not in this release though. That let's $origin work better, among other advantages. Related and possibly solved same IMHO we don't adequately separate source and output - it should separate across multiple packages not just one at a time. But again, not on this release.<span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.265625); -webkit-composition-fill-color: rgba(175, 192, 227, 0.199219); -webkit-composition-frame-color: rgba(77, 128, 180, 0.199219); "> </span></div><div><br> - Jay (phone<span class="Apple-style-span" style="-webkit-composition-fill-color: rgba(175, 192, 227, 0.231373); -webkit-composition-frame-color: rgba(77, 128, 180, 0.231373); ">)</span></div><div><br>On Jul 2, 2009, at 4:14 PM, "Randy Coleburn" <<a href="mailto:rcolebur@scires.com">rcolebur@scires.com</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div>
<div>I thought it might be helpful to highlight some of what I've always understood as the design for the CM3 package system. So, I pulled out my old documentation from Critical Mass as reference. </div>
<div> </div>
<div>I offer the following information to see if this discussion thread concurs and/or wants to make any changes going forward, esp. as we prepare for a new CM3 release.</div>
<div> </div>
<div>1. CM3 takes care to separate source and derived files because doing so (a) isolates source files for backup, revision control, and searching; and (b) enables sharing the same source tree across operating systems and architectures, without confusing object files from different platforms.</div>
<div> </div>
<div>2. Each package resides in a directory, with sources in a source subdirectory ("src"), and generated files in a derived subdirectory named to denote the platform on which the sources were built, e.g., "ALPHA_OSF", "HPPA", "NT386", "SPARC", etc.</div>
<div> </div>
<div>3. Each developer can have multiple private packages, each stored wherever desired in the filesystem. A private package named "foo" would have the following filesystem structure:</div>
<div>
<div><font face="Courier New"> +---foo</font></div>
<div><font face="Courier New"> | +---src</font></div>
<div>
<div><font face="Courier New"> | +---NT386</font>
<div><font face="Courier New"> | +---HPPA</font>
<div><font face="Courier New"> | \---(...)</font></div></div></div></div></div>
<div> </div>
<div>4. For each CM3 installation, there is one public package repository that is available to all developers. When you ship a [private] package, you make that package available to other packages (and developers) via this public package repository. The idea is that as a developer you would test your package in your private repository before shipping it to the public repository. (Sometimes m3overrides were needed when testing several related private packages before shipping them.) </div>
<div> </div>
<div>5. A typical CM3 installation is rooted at a given point in the file system and contains the following folder structure:</div>
<div><font face="Courier New"> CM3</font></div>
<div><font face="Courier New"> +---bin</font></div>
<div><font face="Courier New"> +---doc</font></div>
<div><font face="Courier New"> | +---help</font></div>
<div><font face="Courier New"> | +---pics</font></div>
<div><font face="Courier New"> | +---reference</font></div>
<div><font face="Courier New"> | +---src_reports</font></div>
<div><font face="Courier New"> | \---tutorial</font></div>
<div><font face="Courier New"> +---examples</font></div>
<div><font face="Courier New"> +---lib</font></div>
<div><font face="Courier New"> +---pkg</font></div>
<div><font face="Courier New"> | +---bitvector</font></div>
<div><font face="Courier New"> | | +---src</font></div>
<div>
<div><font face="Courier New"> | | +---NT386</font>
<div><font face="Courier New"> | | +---HPPA</font>
<div><font face="Courier New"> | | \---(...)</font></div></div></div></div>
<div>
<div><font face="Courier New"> | +---cm3ide</font></div>
<div><font face="Courier New"> | | +---src</font></div>
<div>
<div><font face="Courier New"> | | +---NT386 </font>
<div><font face="Courier New"> | | +---HPPA </font>
<div><font face="Courier New"> | | \---(...)</font></div></div></div></div></div>
<div>
<div>
<div><font face="Courier New"> | +---(...)</font></div>
<div><font face="Courier New"> | | +---src</font></div>
<div>
<div><font face="Courier New"> | | +---NT386 </font>
<div><font face="Courier New"> | | +---HPPA </font>
<div><font face="Courier New"> | | \---(...)</font></div>
<div> </div></div></div></div></div>6. In the past, the environment variable INSTALL_ROOT pointed to the root of the CM3 tree in the file system. I think this variable is ambiguously named and that we should change it to CM3_INSTALL_ROOT. Using this approach, if one had multiple CM3 installations (perhaps for different releases), one would simply need to change the CM3_INSTALL_ROOT variable to point to the desired installation for use at any particular point in time. For this to work, all other variables cue off of CM3_INSTALL_ROOT. I know that for the old cm3.cfg file, this was indeed the behavior. Then, if someone had a special situation, they could override the "cueing" behavior for any particular variable simply by changing its definition on the fly.</div>
<div> </div>
<div>7. Now, I also understand some (but not all) of what Jay is saying about the library paths. Back in the old cm3 v4.1 days, I had both HPPA and NT386 derived files for the same set of sources. For Windows, the shipped exe and dll files went into the public repository and you needed to have the CM3/bin folder on your path. For private exe and dlls, you typically just ran them out of the private package's derived NT386 folder. On HPPA, there were some places in the file system that contained static libraries and shared libraries, plus then you had the libraries built using CM3. Again, the CM3 libraries went to the public repository and there were environment variables to facilitate finding the rest, including LD_LIBRARY_PATH. Now, from what Jay is saying, the variety of operating environments seems to cloud up all this. I know I'm a bit rusty wrt all the various unix variants out there, but I recall that v4.1 worked out-of-the-box for both NT386 and HPPA with respect to all this library path stuff and I didn't have to make any symbolic links nor any hard links to make it work. IMO, links are bad and too easily broken.</div>
<div> </div>
<div>8. As for "build_standalone", I know there are various build/bootstrap reasons why some parts of CM3 had to be built this way. But, for me, I've often used this feature for utility-type programs to make it easier to distribute them. I can simply distribute the one executable file without having to worry that the target system might not have the right DLLs or the right shared libraries in the right locations. For production code, I've always built an installation program or an installation script that installed all my executables and shared libraries in a folder structure rooted at a particular point chosen by the end user. Then, my programs always launched and used relative paths from the install location to find everything they needed.</div>
<div> </div>
<div>Hope this info is helpful.</div>
<div> </div>
<div>Regards,</div>
<div>Randy Coleburn</div>
<div> </div></div></blockquote></body></html>