[M3devel] status report on Windows XP

Jay K jay.krell at cornell.edu
Wed Jul 22 00:39:34 CEST 2009


I use the Python all the time on various platforms. It works.
The .cmds I wrote I rarely use, and then, only on Windows.
I thought your list of failures would be down to just m3cc. What are they?
 
 - Jay

________________________________
> Date: Tue, 21 Jul 2009 17:59:47 -0400
> From: rcoleburn at scires.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] status report on Windows XP
>
>
>
>
>
>
>
> Jay,
>
>
>
> Glad to hear the PkgInfo.txt is viable and being maintained.
>
>
>
> Right now, I just don't have the time and motivation to learn jscript.
>
>
>
> I tried using your python scripts and the do-cm3-std.cmd script, but both of them fail for me, even after deleting that PKGS file you referenced. Are you having success with either of these on the Windows platform? If so, there must be something different about your setup from mine.
>
>
>
> The do-cm3.cmd that I wrote seems to build everything for me, except for the files I reported earlier. I ran it again earlier today after a CVS update and noticed that the number of packages that had build errors went down to just 2, so that means some of your recent changes have had an impact here. Thanks.
>
>
>
> Regards,
>
> Randy
>
>>>> 7/21/2009 2:11 PM>>>
>
> Good point do-cm3-foo and do-cm3 foo are isomorphic and user can make the transform.
>
>
>
> The version information in the compiler comes from the scripts/version file. However the m3makefile knows to use the .cmd. It works with either layering order. You don't have to handle it.
>
>
>
> You do have jscript installed and it is pretty easy to read and learn.
>
>
>
> pkginfo.txt is important and maintained, yes.
>
> I need to switch the python to it.
>
>
>
> Comments do not make .cmd maintainable but yes they help. I also have been lulled into thinking .cmd is more viable than it is.
>
>
>
> Sysinfo.cmd tries to see if environment already setup else tries to setup it up for almost anyone. Granted, maybe better to give up and delegate.
>
>
>
> - Jay (phone)
>
>
> On Jul 21, 2009, at 8:02 AM, "Randy Coleburn"> wrote:
>
>
>
>
>
>>>> Jay K> 7/21/2009 4:05 AM>>>
>>Bear in mind some features:>
>> do-pkg (via sysinfo) does a good job of finding compiler/linker
>> You can copy that, but I also intend to move it into the config files if I can.
>> Though not sure e.g. path/lib/include-search is easy there.
>> And I don't want the config files every time to launch a bunch of processes to do the probing.
>> Maybe move the logic to cm3 itself. Maybe.
> My cm3SetupCmdEnv.CMD takes care of finding the compiler/linker via proper path setups etc. This is done once per command prompt session.
>
>
>> sets the version defines when building cm3, by reading the version file
>> The python, .sh, and preexisting .cmd do that. You can copy the code out though.
> I thought the version information was built into the compiler?
>
>
>>Is a little more easily extended -- no builtin list of package groups, but not a big deal.
>>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.
>>Ditto for do-cm3-std.py wrapping do-pkg.py.
> 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.
>
>
>>The structuring is not all that natural I agree, I copied the structuring of the .sh files fairly faithfully,
>>and then improved things by introducing pkginfo.txt.
> My script depends on accuracy of PkgInfo.txt, so I hope this is being kept up-to-date.
>
>
>>Some of the generalizations aren't useful.
>>I'm going to remove the purported support for PM3 and M3 from pylib.py for example.
>
>>My Python code is still missing a nifty feature that Olaf added to the .sh where you can
>>pass extra parameters on to cm3.
> My script allows you to pass multiple mode arguments to CM3 in the order you want them performed.
>
>
>>Yeah we do need to filter out more packages.
>>The package list has grown since I last used the .cmd files and pylib.py has its own list,
>>so I might not be building those packages on any platform.
>>I'll see about filtering in the m3makefiles. That is shared across all the .sh/.py/.cmd.
>
>>.cmd code is generally a maintenance nightmare. The more you write, the bigger the problem.
>>Again you might want to try writing JScript. It is much more natural. It can be slow
>>but you aren't likely to notice here. And it is very portable to Windows.
>>You can wrap it up within a .cmd file if you want, or have a one liner .cmd that calls cscript foo.js.
> 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
>
>


More information about the M3devel mailing list