Clojurians
#cljs-dev
<
2015-12-23
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

thheller00:12:21

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

thheller00:12:54

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"]

thheller00:12:19

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

thheller00:12:38

I have a demo repo if you want one

thheller01:12:07

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

thheller01:12:43

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

dnolen01:12:59

@thheller: just sounds like a different ticket but ok

dnolen01:12:12

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

dnolen01:12:54

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

dnolen02:12:05

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

dnolen02:12:23

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

dnolen03:12:07

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

dnolen03:12:19

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

thheller04:12:57

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

thheller04:12:07

the project file is compiled today

thheller04:12:39

alpha10 and alpha25 jars are both older

thheller04:12:09

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

thheller04:12:46

gets more complicated the more dependencies a project has

thheller04:12:46

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

thheller04:12:55

if anything changes the cache is not used

dnolen04:12:48

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

dnolen04:12:59

I don’t think you looked at the changeset

dnolen04:12:12

we don’t do < or > anymore

dnolen04:12:41

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

thheller04:12:42

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

dnolen04:12:00

@thheller: all that matters is that it is different

thheller04:12:13

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

dnolen04:12:22

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

thheller04:12:57

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

thheller04:12:41

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

thheller04:12:03

against alpha10 of om which has timestamp A

thheller04:12:21

then again against alpha25 which has timestamp B

thheller04:12:34

app.cljs timestamp has not changed

thheller04:12:32

from what I can tell this behavior is still in there

thheller04:12:53

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

dnolen04:12:58

yeah that stuff doesn’t matter at all

dnolen04:12:02

because of deterministic builds

dnolen04:12:16

if some parent ns gets recompiled that trumps everything

dnolen04:12:28

just pushed what appears to me to be the fix

dnolen04:12:52

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

dnolen04:12:30

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

thheller05:12:13

appears fixed in the test repo