[M3devel] status report on Windows XP

[Randy Coleburn]

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

>>> <jay.krell at cornell.edu> 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" <rcoleburn at scires.com> wrote:



>>> Jay K <jay.krell at cornell.edu> 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
 

CONFIDENTIALITY NOTICE:  This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation.  If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments.  If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments.

EXPORT COMPLIANCE NOTICE:  This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR).  Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer.  In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization.  By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090721/13b998b3/attachment-0002.html>