You got it! Scott
-----Original Message----- From: [EMAIL PROTECTED] on behalf of John Grden Sent: Fri 3/17/2006 4:47 PM To: Open Source Flash Mailing List Cc: Subject: Re: [osflash] [Flasc] New version of FLASC ah ok, I see what you're saying Scott - I'll have to test it out, but I do believe I know what you're saying. A simple class reference will take care of making sure the class is compiled so long as it's living in the same cp - yes? On 3/17/06, Scott Hyndman <[EMAIL PROTECTED]> wrote: > > cp is not recursive, but class dependencies are > > I'm spamming the list, sorry guys :) > > Scott > > -----Original Message----- > From: [EMAIL PROTECTED] on behalf of John Grden > Sent: Fri 3/17/2006 4:38 PM > To: Open Source Flash Mailing List > Cc: > Subject: Re: [osflash] [Flasc] New version of FLASC > > Ok, so, CP's are what I've said they where, right? A cp is just a path to > where classes *might* be located that mtasc finds while compiling the > classes. it's not recursive though from what I experienced. > > IE: if I have > > classes/com/blitzagency/Main.as and it references/uses > com.blitzagency.controls.GraphicButton.as it won't find it unless I have > classes/com/blitzagency/controls listed as a possible cp - at least, > that's > what I experienced in my testing. Sometimes it seemed to work fine, and > others it didn't find it at all. I couldn't get a straight answer on the > mtasc list, so that's why I've had to go with the assumption that it's NOT > recursive. Plus the wording on Nicolas' site indicates that you can add > as > many cp's as you want - why would I need to if it's recursive? I mean, > yeah, I know I can add CP's for other locations on a hard drive, but my > testing did lead me to the conclusion that it was recursive at all. > > Plus, i swear I read a post from nicolas that said it wasn't recursing > based > on a CP. > > thoughts? > > On 3/17/06, Till Schneidereit <[EMAIL PROTECTED]> wrote: > > > > John Grden wrote: > > > then why have packs then? i thought a CP was just the same idea as a > > pack. > > > > A codepath is just that: A path in which mtasc should look for code. The > > way this works is that mtasc parses the classes you supply as arguments > and > > includes all other classes referenced by these recursively. If it > doesn't > > find one of these classes in the current directory, it starts looking in > > each of the directories supplied by using the -cp argument. > > The -pack argument on the other side instructs mtasc to > (non-recursively) > > pack all the classes in the given directory into the swf. AFAIK, it's > > primarily meant for people that use lots of linked symbols with classes > > registered to them that aren't referenced anywhere else and don't get > > compiled by mtasc if they aren't specifically included, be it by > supplying > > the as individual arguments or by using -pack. I think the reason for > not > > making -pack recurse is to prevent the inclusion of unneeded classes. > > (Though I'm not so sure of whether that's a good decision ...) > > > > cheers, > > till > > > > > > _______________________________________________ > > osflash mailing list > > [email protected] > > http://osflash.org/mailman/listinfo/osflash_osflash.org > > > > > > -- > John Grden - Blitz > > > > > _______________________________________________ > osflash mailing list > [email protected] > http://osflash.org/mailman/listinfo/osflash_osflash.org > > > -- John Grden - Blitz
<<winmail.dat>>
_______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org
