flex compiler drunk again

[Paul Hastings <pa...@gmail.com>]

we have a suite of apps that we keep in-synch & compile together (same 
workspace). recently we had users complain that they were seeing a really old 
version of one app--like jan-2015 old--instead of the latest build (jun-2016). i 
checked the SWF timestamp, it had the correct date. but testing the app showed 
it was indeed the jan-2015 version. i thought it was a deployment screw up, so 
re-compiled the app & tested. same jan-2015 version. clean & build, new 
workspace, shut down FB, re-booted w/s, etc. made no difference. same fossilized 
version. i started watching the output dir & saw that the compiler emitted the 
SWF in alphabetical order & the app in question (alluvium) started out with a 
SWF size of 1.318mb. but by the time the whole suite was compiled, that app had 
shrunk to 1.299mb & was the fossil version. re-compiled & grabbed a copy of the 
larger SWF before the suite finished compiling & that was the correct jun-2016 
version. yikes.

its like the compiler is digging up source from God knows where & re-compiling 
that as it works thru the suite. i can't even find that source version anywhere 
but buried in the code repository.

has anybody seen this kind of behavior? any ideas where to start looking to fix it?

FB4.6
flex 4.13 SDK
target flash 14.0

thanks.

Re: flex compiler drunk again

[Paul Hastings <pa...@gmail.com>]

 > if i just delete the reference, will that stop the compiler from compiling it

and the answer appears to be "why yes you can".

fixed.

thanks again.

Re: flex compiler drunk again

[Paul Hastings <pa...@gmail.com>]

On 6/15/2016 11:37 PM, Alex Harui wrote:
> Why do you say "source"?  Are there no SWCs involved?

sure but its clear its the "core" part of the app--the init is completely 
different, the "about" data, etc. are all from the main part of the app. there's 
no lib SWC involved in that bit. that's compiled straight from the source.

> 1) Compare its timestamp in the filesystem of the good one you grabbed
> during the build against the "final-but-fossil" version. Which timestamp
> is newer?  I would imagine the bad one is newer, which means that one of
> the projects in the workspace is generating it.

yup, 1:22pm a modern version is emitted then at 1:23pm it spits out the 
fossilized version.

> 3) Scan the .project and .actionscriptProperties files in the projects.
> It is possible that one of the other projects has been told to generate
> the same output file.

ding ding ding. in .actionscriptProperties file a mystery branch has popped up 
(on me for not digging deeper in the branches).

<application path="alluvium.mxml"/>
<application path="branches/sammy/alluvium.mxml"/>

not sure why that particular code is in that branch but i suppose this is where 
the compiler is finding its fossils (it looks like the same age as what's being 
output).

if i just delete the reference, will that stop the compiler from compiling it 
(need to figure out how/why that's in my source)?

> 6) You could also try building a custom compiler that generates more
> output to help you track it down.

ha ;-)


thanks for the advice.

Re: flex compiler drunk again

[Alex Harui <ah...@adobe.com>]

On 6/15/16, 3:06 AM, "Paul Hastings" <pa...@gmail.com> wrote:

>
>its like the compiler is digging up source from God knows where &
>re-compiling 
>that as it works thru the suite. i can't even find that source version
>anywhere 
>but buried in the code repository.

Why do you say "source"?  Are there no SWCs involved?

>
>has anybody seen this kind of behavior? any ideas where to start looking
>to fix it?

I haven't seen anything like this, but some things to try are:

1) Compare its timestamp in the filesystem of the good one you grabbed
during the build against the "final-but-fossil" version. Which timestamp
is newer?  I would imagine the bad one is newer, which means that one of
the projects in the workspace is generating it.
3) Scan the .project and .actionscriptProperties files in the projects.
It is possible that one of the other projects has been told to generate
the same output file.
4) Do a detailed compare to make sure that the differences between the
good and bad is in fact what you would expect from source code history.
5) You could also scan .project and .actionscriptProperties files for
"ant" to make sure no Ant tasks are doing stuff during the build.
6) You could also try building a custom compiler that generates more
output to help you track it down.

My wild guess is there is some other project in your workspace that has
access to an old SWC that is generating the bad version.

-Alex