[M3devel] do-cm3.cmd for Windows

[jay.krell at cornell.edu]

Upgrade skips m3core and libm3, builds up to cm3, copies cm3, then  
clean and build in order from the bottom. You could say it starts  
after libm3 or at sysutils, but there is also import-libs. In future  
if released cm3 can build current m3core and libm3 then just build  
from the bottom and on up, nothing tricky. Thinking about this now I  
think we should have just done the trick once and then declared the  
resulting cm3 as the baseline, instead of this 'institutionalization'  
of the 'workaround' that seems to confuse everyone, and leaves compat  
hacks in to deal with older releases. I think we should abandon 5.4 as  
a base before this release so this can be cleaned up.

  - Jay (phone)

On Jul 20, 2009, at 10:08 PM, jay.krell at cornell.edu wrote:

> Do-pkg.cmd does the same thing as do-pkg.sh and do-pkg.py.
>
> - Jay (phone)
>
> On Jul 20, 2009, at 9:50 PM, "Randy Coleburn" <rcoleburn at scires.com>  
> wrote:
>
>> Jay:
>>
>> I'm not quite sure what all the various "do-pkg.cmd" and "do-cm3- 
>> *.cmd" scripts actually do.  Some of the code is pretty complex and  
>> I decided it would take me longer to figure it out than to just  
>> write a new script.
>>
>> Anyway, you didn't answer my questions, so I've experimented to  
>> come up with something that seems to work for the current cases in  
>> PkgInfo.txt.
>>
>> I've uploaded a new file "do-cm3.cmd" that processes the  
>> "PkgInfo.txt" file based on my understanding of that file's  
>> format.  I've tested it locally and it seems to work for me.
>>
>> This one .CMD file is meant to be an alternative to all of the  
>> various "do-pkg.cmd" and "do-cm3-*.cmd" files.
>>
>> Here are examples of how it could be called:
>> cd "scripts\win"
>> do-cm3 std buildship
>> do-cm3 game clean buildship
>> do-cm3 game realclean build ship
>> do-cm3 comm depends
>> do-cm3 all buildship
>>
>> There is a block of code labeled "SetupCM3" in "do-cm3.CMD" that  
>> expects to call my "cm3SetupCmdEnv.cmd" file, but if you don't use  
>> this file, simply comment-out this block of code or set  
>> CM3_DoneSetup=TRUE at the beginning of the block to prevent it from  
>> running.
>>
>> If anyone tries my new script, let me know if you experience any  
>> problems and I'll try to fix them.
>>
>> Finally, if I want to adapt my "do-cm3.cmd" script to also handle  
>> the work of "upgrade.cmd", I'm going to need someone to explain to  
>> me the compilation and shipping order for the upgrade process.
>>
>> Regards,
>> Randy Coleburn
>>
>> >>> <jay.krell at cornell.edu> 7/20/2009 9:56 PM >>>
>> do-pkg.cmd already does this doesn't it?
>> It is looking for substring matches against paths or somesuch like
>> the .sh code.
>> Not actually package names.
>>
>>  - Jay (phone)
>>
>> On Jul 20, 2009, at 5:42 PM, "Randy Coleburn" <rcoleburn at scires.com>
>> wrote:
>>
>> > I am nearing completion of a "do-cm3.cmd" script for Windows 2000/ 
>> XP
>> > that operates based on the "scripts/PkgInfo.txt" file.
>> >
>> > I have a question about the format of the "scripts/PkgInfo.txt"  
>> file.
>> >
>> > Most of the lines in this file identify a package by name as the
>> > first entry on the line.  A few of them also provide a relative  
>> path
>> > to this package.
>> >
>> > If the source tree is rooted at "sandbox\cm3", we have subfolders
>> > "m3-sys", "m3-games", etc.
>> >
>> > How do we know in which unique subfolder each package is located?
>> >
>> > For example, "m3cc" is in "sandbox\cm3\m3-sys\m3cc"
>> > while, "netobj" is in "sandbox\cm3\m3-comm\netobj"
>> >
>> > Then we have in PkgInfo.txt lines like:
>> > "paneman/kemacs" which is in "sandbox\cm3\caltech-parser\paneman
>> > \kemacs"
>> > "m3-games/badbricks" which is in "sandbox\cm3\m3-games\badbricks"
>> >
>> > I can see the need for the relative path for "paneman/kemacs", but
>> > "m3-games/badbricks" seems to break with the established pattern.
>> > Is this an error in the current PkgInfo.txt  file?
>> >
>> > Regards,
>> > Randy Coleburn
>>
>