Reader Conditionals

[hypirion]

http://dev.clojure.org/display/design/Reader+Conditionals contains information about upcoming changes in Clojure (presumably 1.7). Right now, the only thing that's of importance seems to be supporting reading/compiling .cljc files.

Enabling/disabling feature sets would only require the user to update the :jvm-opts, so there should be no issues there. However, merging these options would be messy (#878 might remedy this problem).

[jenanwise]

Right now lein completely ignores .cljc files (e.g., lein test will not pick them up) because bultitude does not recognize them. I added partial support in of Raynes/bultitude#27 but leiningen's use of bultitude.core/path-for will have to modified/removed since the 1-to-1 namespace-to-possible-filename assumption is now broken.

[sfnelson]

With Clojure 1.7 nearing release, this issue should be a priority. Reader conditional support is a huge boon for full stack clj/cljs developers, so it would be good to know that leiningen will be ready before 1.7 lands.

[technomancy]

Issues become prioritized when someone chooses to work on them. The best way to make sure something happens is to make it happen.

[sfnelson]

#1911

(also Raynes/bultitude#28)

[technomancy]

Nice! Could we get some clojurescript users to try this out and leave feedback?

[sfnelson]

@technomancy: there is one function that I have not updated to support cljc that probably needs to be updated, but I don't understand its purpose. I was hoping you could explain what source-in-project? (src/leiningen/compile.clj#L68) is intended to do?

It's only use is in the following function, class-in-project?, where it is called on the parent of a class file. The function itself adds ".clj" to the parent and looks for the result in source dirs:

=> (class-in-project? project /path/to/target/classes/pkg/file.class)
=> (source-in-project? /path/to/target/classes/pkg compile-path source-path)
=> (.exists? /path/to/src/pkg.clj)

Is there a clojure compilation pattern that results in class files created in a subdirectory named after the compiling namespace?

[sfnelson]

#1911 is ready for testing now. It's only somewhat relevant to Clojurescript users, it's most relevant to users who previously shared code between Clojurescript and Clojure using CLJX, particularly if they have shared tests or need AOT support.

[technomancy]

there is one function that I have not updated to support cljc that probably needs to be updated, but I don't understand its purpose. I was hoping you could explain what `source-in-project?`

This exists in order to support :clean-non-project-classes, which is a workaround for a problem in the Clojure compiler where there is no way to AOT-compile a class without compiling all the namespaces it requires. So we need a way to know whether a given class in :target-path came from a source file in the project or whether it came from the source of one of its dependencies.

[sfnelson]

Thanks. I understand the reason to want to clean non-project class files, but I don't understand how the third clause of class-in-project? correctly identifies namespaces for project classes. Given the file target/classes/foo/bar/baz__init.class it looks like the third clause will attempt to resolve src/foo/bar.clj, when I would expect it to attempt to resolve src/foo/bar/baz.clj. In all causes that I've been able to produce it doesn't matter because one of the first two clauses finds the correct project source file.

Is there a case I'm not familiar with where src/foo/bar.clj will generate src/foo/bar/*.class? If not, I think that the third clause is incorrect.

[technomancy]

I see; sorry, I misread you. I believe that clause is in there to support gen-class declarations that live inside a namespace but not in the `ns` clause. Of course, gen-class accepts any class name; it doesn't require it to be "under" the namespace containing the gen-class call, so this is more of a convention than anything else. Anyway, I would call this a safety net for gen-class in projects where you need more than one class generated for a given namespace; as long as the generated class is directly "under" the namespace that generated it, we won't delete it.

[sfnelson]

Thanks. I've updated the merge request to support this use case.

[hypirion]

This is out in 2.5.2. I assume that if we don't hear too much about this not working, then this could be closed.

[sfnelson]

Verified working for crossover code ported from cljx, including an extensive test suite.

[interstar]

Stupid question, but what do I need to do exactly to get lein to recognise cljc files?

I just renamed a bunch of cljx files to cljc and put them into a directory called cljc/myproject/*cljc

I removed all the cljx plugin references from my project.clj file.

I pulled the latest lein 2.5.2. Did a lein clean and then a lein test and got the compiler blowing up, complaining that it can't find the first of my cljc files.

java.io.FileNotFoundException: Could not locate myproject/maths__init.class or myproject/maths.clj on classpath., compiling:(core.clj:1:1)

Anything else I need to do? Is there a particular place lein is looking for the cljcs?

[danielcompton]

@interstar is the cljc folder in your :source-paths?. Are you using Clojure 1.7?

[interstar]

Ah yes, that was it. (No cljc in :source_paths ). I presumably didn't need to explicitly state that when I was using the cljx plugin to put clj files into src so there was nothing explicit. Thanks

[chadharrington]

This is working for me with lein 2.5.2. I suggest closing the issue.

[hypirion]

I've tested it to some extent myself with the same results, so I'll close this. Thanks for verifying.