I have a strange problem. When I try and compile the application, I get two errors, one of which is below, but they are essentially the same.
If I edit FaqEventMapButtonSkin.mxml and update ButtonSecondaryDefault to ButtonSecondaryDefaultTEST, and change the corresponding ButtonSecondaryDefault.fxg to ButtonSecondaryDefaultTEST.fxg, everything works fine.
The compiler must be caching something. I've looked and looked for information on this topic without any luck. I'm not using incremental compile. Any ideas on how to clear things out?
FaqEventMapButtonSkin.mxml(44): Error: In initializer for 'source', type com.thomson.convene.ui.assets.ButtonSecondaryDefault is not assignable to target type 'Object'.
[compc] <assets:ButtonSecondaryDefault width="100%" height="100%" />
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.
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.
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.