<HTML><HEAD>
<STYLE>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</STYLE>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-15">
<META content="MSHTML 6.00.6000.16850" name=GENERATOR></HEAD>
<BODY class=hmmessage>
<DIV>>>> Jay K <jay.krell@cornell.edu> 7/21/2009 4:05 AM >>><BR>>Bear in mind some features:><BR>> do-pkg (via sysinfo) does a good job of finding compiler/linker<BR>> You can copy that, but I also intend to move it into the config files if I can.<BR>> Though not sure e.g. path/lib/include-search is easy there.<BR>> And I don't want the config files every time to launch a bunch of processes to do the probing.<BR>> Maybe move the logic to cm3 itself. Maybe.<BR><STRONG><FONT color=#0000ff size=3>My cm3SetupCmdEnv.CMD takes care of finding the compiler/linker via proper path setups etc. This is done once per command prompt session.</FONT></STRONG></DIV>
<DIV> <BR>> sets the version defines when building cm3, by reading the version file<BR>> The python, .sh, and preexisting .cmd do that. You can copy the code out though.<BR><FONT color=#0000ff size=3><STRONG>I thought the version information was built into the compiler?</STRONG></FONT></DIV>
<DIV> <BR>>Is a little more easily extended -- no builtin list of package groups, but not a big deal.<BR>>Look at how do-cm3-std.sh and do-cm3-std.cmd are both just a few lines that wrap do-pkg.sh and do-pkg.cmd.<BR>>Ditto for do-cm3-std.py wrapping do-pkg.py.<BR><STRONG><FONT color=#0000ff size=3>This is a matter of opinion. The do-cm3-std.CMD was not working for me. Neither did the python. I don't know python, so troubleshooting it is a problem for me. Also, if you don't have a list of packages and the correct build order, how do you ensure it is done correctly? As for the wrapping, I did my script all in one file because the only difference in the various do-cm3-* scripts seems to be the group you want to compile--I just made this a required parameter. If we add more groups, it is a simple one line change to my script.</FONT></STRONG></DIV>
<DIV> <BR>>The structuring is not all that natural I agree, I copied the structuring of the .sh files fairly faithfully,<BR>>and then improved things by introducing pkginfo.txt.<BR><FONT color=#0000ff size=3><STRONG>My script depends on accuracy of PkgInfo.txt, so I hope this is being kept up-to-date.</STRONG></FONT></DIV>
<DIV> <BR>>Some of the generalizations aren't useful.<BR>>I'm going to remove the purported support for PM3 and M3 from pylib.py for example.<BR> <BR>>My Python code is still missing a nifty feature that Olaf added to the .sh where you can<BR>>pass extra parameters on to cm3.<BR><FONT color=#0000ff size=3><STRONG>My script allows you to pass multiple mode arguments to CM3 in the order you want them performed.</STRONG></FONT></DIV>
<DIV> <BR>>Yeah we do need to filter out more packages.<BR>>The package list has grown since I last used the .cmd files and pylib.py has its own list,<BR>>so I might not be building those packages on any platform.<BR>>I'll see about filtering in the m3makefiles. That is shared across all the .sh/.py/.cmd.<BR> <BR>>.cmd code is generally a maintenance nightmare. The more you write, the bigger the problem.<BR>>Again you might want to try writing JScript. It is much more natural. It can be slow<BR>>but you aren't likely to notice here. And it is very portable to Windows.<BR>>You can wrap it up within a .cmd file if you want, or have a one liner .cmd that calls cscript foo.js.<BR><STRONG><FONT color=#0000ff size=3>Again, this is a matter of opinion. I tried to put enough comments in my script that someone can figure it out and maintain it. In contrast, your CMD scripts are pretty much void of useful comments. You could be right about JScript, but then I don't know JScript and don't have it installed on my computer. CMD is built-in to Windows and I know it, so for me it is more natural. --Randy</FONT></STRONG></DIV>
<DIV> </DIV></BODY></HTML>