case in point http://dev.clojure.org/jira/browse/CLJS-1487

@dnolen there is still the issue that the files that DEPEND on files in jars are not recompiled

so say I compile my project against [org.omcljs/om "1.0.0-alpha10"] and then bump it to [org.omcljs/om "1.0.0-alpha25"]

the files not in jars (a.k.a the project) are not recompiled

I have a demo repo if you want one

https://github.com/thheller/cljs-broken-cache

I'll leave it to you whether you regard this as an issue or not

wait, just noticed that om/next.cljs is also not recompiled so the build is mixing alpha10 code with alpha25

@thheller: just sounds like a different ticket but ok

@thheller: I haven’t seen the mixing problem as that’s what I was testing

testing anything with lein is not recommended and not something I will look at

@martinklepsch: bigger namespaces take longer to compile, which is to be expected

not going to bother with anything that isn’t at the file level

@thheller: ah ok after poking around some more I do see what you mean

somehow the recompile dependents thing doesn’t work for sources in JARs for some reason

@dnolen as I tried to explain the last time, the issue is that a single timestamp is not accurate enough

the project file is compiled today

alpha10 and alpha25 jars are both older

so when the timestamps are compared the project file appears newer and is not recompiled

gets more complicated the more dependencies a project has

I settled on creating a map for each namespace with entries where each dependency is recorded with a timestamp

if anything changes the cache is not used

@thheller: I don’t really understand your assessment of the issue

I don’t think you looked at the changeset

we don’t do < or > anymore

all we do is mark the last modified to whatever the original source was on disk

doesn't matter if it is < or > or =

https://github.com/clojure/clojurescript/compare/e1892f6928...96a1615d4e#diff-41c825eb516618c6b81bfcb40f84a54dR158

@thheller: all that matters is that it is different

I admit that I do not understand what is going on any longer

= is fine, you haven’t explained any reasoning that I can follow

just see the same symptom I saw in shadow-build and how I fixed it

say you compile app.cljs with timestamp X (which is now)

against alpha10 of om which has timestamp A

then again against alpha25 which has timestamp B

app.cljs timestamp has not changed

still X

from what I can tell this behavior is still in there

but it is 6am over here and I haven't slept yet, so I might be totally off

yeah that stuff doesn’t matter at all

because of deterministic builds

if some parent ns gets recompiled that trumps everything

just pushed what appears to me to be the fix

I just tested with transit and verified that that changing the dependency should trigger dependent namespaces to recompile

@thheller: still thanks for the sanity check and happy to hear if you run into issues with master

appears fixed in the test repo

cool!