<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-15">
<META content="MSHTML 6.00.6000.16890" name=GENERATOR></HEAD>
<BODY style="MARGIN: 4px 4px 1px">
<DIV>Jay:</DIV>
<DIV> </DIV>
<DIV>Your message was truncated, and provided much more info than I think I'm asking about.</DIV>
<DIV> </DIV>
<DIV>I simply need to know what packages have to be built, and in what order, to produce the minimal binary distribution for a given platform. In my case right now, platform is Windows XP or Vista.</DIV>
<DIV> </DIV>
<DIV>I had assumed, perhaps incorrectly, that "min" defines that set. But, I'm not sure. In particular, it looked like "front" might be building parts of the compiler that are needed.</DIV>
<DIV> </DIV>
<DIV>Or am I all wrong here, and rebuilding the compiler (i.e., using an old compiler to build a new version of itself) is a different process from building the minimal binary distribution?</DIV>
<DIV> </DIV>
<DIV>I also provided in my email a listing of all the group tags and the packages in each group for everyone's reference. (Sort of a sanity check on the correctness of PkgInfo.txt.)</DIV>
<DIV> </DIV>
<DIV>So, let me ask a concrete yes/no question, if one wanted to perform a complete cm3 installation on Windows, is the 13-step procedure outlined below correct? If not, please advise on changes needed.</DIV>
<DIV> </DIV>
<DIV>1. Install Visual C++ 2008 Express Edition.</DIV>
<DIV> </DIV>
<DIV>2. Download latest minimal binary distribution and unzip to "C:\cm3" so that you have C:\cm3\bin, C:\cm3\pkg, etc..</DIV>
<DIV> </DIV>
<DIV>3. Checkout complete CVS CM3 tree and place in say "C:\cm3\<STRONG>Sandbox</STRONG>", so now Sandbox has m3-sys, m3-libs, scripts, etc.</DIV>
<DIV> </DIV>
<DIV>4. Copy "C:\cm3\Sandbox\<STRONG>doc</STRONG>" folder to "C:\cm3\<STRONG>doc</STRONG>"</DIV>
<DIV> </DIV>
<DIV>5. Copy "C:\cm3\Sandbox\<STRONG>examples</STRONG>" folder to "C:\cm3\<STRONG>examples</STRONG>"</DIV>
<DIV> </DIV>
<DIV>6. Open Visual Studio Command prompt window and put "C:\cm3\bin" on your path.</DIV>
<DIV> </DIV>
<DIV>7. For each file in "Sandbox\m3-sys\cm3install\src\<STRONG>config-no-install</STRONG>" and "Sandbox\m3-sys\cm3install\src\<STRONG>config</STRONG>" delete the corresponding file in "C:\cm3\bin" if it exists.</DIV>
<DIV> </DIV>
<DIV>8. mkdir "C:\cm3\bin\config" if it is missing</DIV>
<DIV> </DIV>
<DIV>9. copy contents of "C:\cm3\Sandbox\m3-sys\cm3install\src\<STRONG>config-no-install</STRONG>" to "C:\cm3\bin\<STRONG>config</STRONG>"</DIV>
<DIV> </DIV>
<DIV>10. (Re)create "C:\cm3\<STRONG>cm3.cfg</STRONG>" to contain the following 2 lines only:</DIV>
<DIV>INSTALL_ROOT = path() & "/.."</DIV>
<DIV>include(path() & "/config/" & HOST)</DIV>
<DIV> </DIV>
<DIV>11. Rebuild the compiler and minimal install using the latest sources in "C:\cm3\Sandbox". The only packages that need to be built are those listed in the "min" group in "Sandbox\scripts\<STRONG>PkgInfo.txt</STRONG>". Build them in the order listed using -realclean -build -ship. (Granted, there may be scripts for this, but is what I am saying here what is actually required?)</DIV>
<DIV> </DIV>
<DIV>12. Repeat step #11 to ensure the new compiler is used to rebuild the core stuff.</DIV>
<DIV> </DIV>
<DIV>13. Now, for any or all packages listed in "Sandbox\scripts\PkgInfo.txt", use cm3 to build and ship those that you want. You could build everything, but for example, if you wanted only a "std" installation, you could simply build and ship only those packages tagged as "std".</DIV>
<DIV> </DIV>
<DIV>I know you've probably got scripts for all of this, but somewhere we need to document exactly what is required. Scripts are an expression of the requirements and they may contain bugs, so knowing what is supposed to happen, versus reading a script, is important.</DIV>
<DIV> </DIV>
<DIV>Regards,</DIV>
<DIV>Randy<BR><BR>>>> Jay K <jay.krell@cornell.edu> 7/29/2009 8:35 PM >>><BR><BR><BR>I'm only going to answer partially for now..<BR><BR><BR>> Are these really all that is needed<BR>> to build the "minimal" binary distribution?<BR><BR><BR>It depends on what you mean.<BR><BR><BR>The answer is more like, what you need to build is cm3, sometimes mklib (Windows), and sometimes cm3cg (non-Windows).<BR><BR><BR>That's it. You don't need any packages at all. You don't need m3core/libm3.<BR><BR><BR>I setup tinderbox a few times recently.<BR>In all cases I setup a new CM3 environment, consisting of exactly cm3, cm3cg, the config directory and the two line cm3.cfg (these were all non-Windows, so far).<BR><BR><BR><BR>What that lets you do is build the whole system, from the bottom of the dependency tree and on up.<BR><BR><BR><BR>HISTORICALLY there have been some wrinkles here.<BR>And it made pretty good sense, I guess, to draw another line.<BR>Whether or not that will happen again, unclear.<BR><BR><BR><BR>The specific wrinkles were:<BR><BR><BR>- Old compiler could not compile a new libm3, if new targets had been added<BR> That has been fixed. Old compiler can build current libm3, current libm3 can build future libm3 with additional targets. Old compiler and current compiler still can't build many past libm3 versions with a different target list than the compiler<BR><BR>- Old compiler cannot compile m3core or libm3 that uses LONGINT.<BR><BR><BR>Now, I have a suspicion that these issues are not extremely rare but just somewhat rare.<BR><BR><BR><BR>All compilation systems written in themselves have a circularity.<BR>The compiler depends on the compiler.<BR><BR><BR><BR>Sometimes the language changes and sometimes you want to or perhaps must use the new language construct in the compiler. At which you have a transition to make.<BR><BR><BR><BR>Let's imagine, crazy, that all the identifiers were changed to lowercase.<BR>If "just" change the compiler, well then, you can't build the compiler.<BR><BR><BR><BR>You have to make the compiler support both forms, keep using the old form, recompile, then change to the new form, and then you could stop accepting the old form.<BR><BR><BR><BR>I feel like I might be missing something though.<BR><BR><BR>In any case..what are the scenarios?<BR>- People who don't want to spend any time compiling anything they didn't write and have a lot of network bandwith.<BR> Give these people "std" or a bunch of binary packages.<BR> These people, in the extreme impatience form, would not even like Olaf's workspace packages.<BR><BR><BR>- People who want to compile as much as possible from source. They don't trust binaries. They want to be sure they can make changes. They want to be sure they can debug through m3core/libm3. They are correctly nervous that if I build cm3 on OpenBSD 4.5, they won't be able to run it on 4.3.<BR> Today you give these people cm3, cm3cg, and config files.<BR> But you can do better, you can give them the assembly for cm3, some uncompiled C for cm3, and "full regular source" for cm3cg. This is almost exactly what DEC SRC 3.6 did and almost exactly (or maybe exactly) what John Polstra's "ezm3" FreeBSD "port" does.<BR> The difference in DEC SRC is that quake was written in C, so the division <BR>was slightly elsewhere, though you could think of it the same, just 1) more C and 2) the "build scripts" were written in Quake. We would not be able to use quake, at least for cm3 itself (pylib.py !already! generates a makefile and *.sh for this purpose).<BR><BR><BR> - Various (infinite) in between situations<BR> such as people don't want to compile anything, but also are writing fairly simple command line programs. "min" actually satisfies in many cases</DIV></BODY></HTML>