I did find this, and it seems along the same lines.
I can pull this code on another server and run it without any problems. Plus, I've had a build working, tared up the files and moved them and untared them on another server and hit random similar errors. This seems like a compiler issue, but I'm not sure how to make sure I'm getting a clean run.
Do you have both an .mxml and an .fxg file with the same name? That might confuse the compiler.
Thanks, but I don't.
Additional information is that when I change the names and get it to run, as described above, I can get it to fail again by changing them back.
Maybe if you post more code we can better understand what your scenario is.
I can post more code, but the code isn't the issue, exactly. We've seen this happen in differnt code locations, with similar behaviour. Since this problem began, I've pulled the exact same code on a different server and compiled it without issue. And as I said, if I change the names on the "bad" server, it will compile fine. What I'm iterested in knowing is what, if anything, the compiler caches when running in non-incrimental mode. I went so far as to use lsof to see what was going on when the compile took place and I found that /Users/hudson/Library/Saved Application State/com.apple/javajdk16.cmd.savedState/data.data is getting hit. I'm wondering what kind of information the compiler might be hanging onto.
1 person found this helpful
I don’t know the compiler well enough to know if it caches stuff or not. The compiler source code is available in the Apache Flex repository if you want to try to look yourself. I’ve seen some compiler code that implies there are three ways of running a compile:
1. incremental: when editing and saving in FB
2. full: when cleaning and building in FB
3. standalone: when running mxmlc from ant or command line
I’m pretty sure stuff is cached between builds for #1. It is possible that there is caching between builds in #2. There should not be caching between builds in #3, but I would not put money on it. When you say you are not using incremental compile, are you using #2 or #3 or both?
What does happen in #3 (and hopefully #2) is that SWCs found in the library path are read in and parsed and all of their classes go in a lookup mechanism to be used when trying to resolve symbols from other compilation units. Plenty of folks have been burned when there is some stale SWC in some folder of SWCs pointed to by some configuration file that is supplying a competing definition. And that’s what makes it machine specific.
Using #3. Thanks for the response. I'll digest it, see about looking at the source code, and respond with results.