$ camp new myapp
This should:
- create a new directory
- add a .gitignore
- add a project.clj
- includes lein-esque deps
- add src/myapp/core.clj
- fetch deps from nuget
- be able to gather all target framework compatible libs, content, and tools.
$ camp deps
- fetch deps in not already there
- Oops, forgot about this part. I’ll get to it later.
- construct a Clojure.Compiler command line
- output goes in targets dir
$ camp compile
- Give vision
- Show example
- Mention road map
- nuget package
- update: I actually don’t think this is necessary. Choco package is needed anyway, and consists of a nuget package already.
- chocolatey package
- This is easy and will add a lot of value in not making people have to futz with their PATH.
- I like the way leiningen templates work. Something like that…
- just fire up a repl with the project loaded for now.
- Make chocolatey stop complaining about missing icon.
- Tried adding an icon URL, but that appears to be for the chocolatey website, not shimgen.
- screen casts
- clojure-clr google group
- seajure
- lobste.rs/hackernews, …
- I want this now, since tools.nrepl has no nuget package yet
- Must handle project names like org.clojure.clr/tools.nrepl
- maybe this should be called org.coljure.clr.tools.nrepl?
- See Deploy Task Package Naming
- It’s going to pick up the Clojure.dll in the camp.exe directory.
- Maybe switch to doing something like what the camp build script does, where tools are copied into a working directory from deps, and use the Clojure.Compiler.exe from deps?
- Try different testing libs and see which one works.
- Strategy: 0.1.0 is a spike. Need to think about maintenance from 0.1.1 on wards.
- read somewhere that it “almost works”
- based on experience with lein test and whatever I learn doing tests for camp itself.
- ILMerge has issues.
- Maybe try Jeffery Richter idea
- have a stub EXE with assemblies embedded as resources
- there was some problem with that, though, too, AFAIR.
- Try using GenContext and Compiler directly, with one context, generating one assembly.
- Especially version attributes
- Looks like it might be a pain.
- Check with MSOT: if I can sign contrib agreement, maybe just send a patch.
- But then I’m dependent on a future release of ClojureCLR nuget package.
Need a way to embed resources in assemblies.
- resource compiler
- lots of JVM projects depend on resources and I imagine CLR ones will too.
- Is it even needed?
- Should be pretty simple to get going.
- This is probably really important
- Just don’t do anything that won’t run on mono - keep it simple.
- Less worried about building camp itself on mono.
- Research how platform works in nuget with mono
- Maybe making some bad assumptions in deps.clj?
- C#, F#
- Similar to how leiningen compiles java
- For people that have private repos
- So project :nuget-repository would be a vector or something
- defcontroller?
- You can go crazy and :require all the things (Winnebago), or travel light and keep it simple.
- You can create one project, then take what you want for it and go on up the mountain to the next project, establishing a new camp.
- Mountaineering with a base camp and camp I, camp II, …
- Vague…I am really thinking about being able to quickly re-use assets (think: “I have bootstrap over there already. Just use that!”, or “On a plane. Can’t restore packages. Please re-use package I already downloaded over there.”, like maven.)
- Also like the George Carlin sketch about going to Honolulu with a bunch of stuff, then taking less stuff for a couple of days to Maui, then even less stuff somewhere else…
- Leverage app domains to make it easier to eval-in-project
Camp needs to use other tools, like the clojure compiler, nuget, etc. Is it better to use those other tools as executables, as a rule, or use as a library when available?
For example, to restore dependencies, camp could generate a packages.config file and shell out to nuget.exe to restore them.
- Compiling and loading in ClojureCLR
- `clojure.core/compile’ calls /load, then eventually,
`clojure.lang.RT/load’.
- clojure.core/compile also binds compile-files true.
- If the .clj file is newer than the .clj.dll, it compiles the source file.
- It looks at `Compiler.CompileFilesVar.’ to determine if it wants to Compile or LoadScript.
- The clojure symbol for CompileFilesVar is `clojure.core/*compile-files*’ and it defaults to false.
- Eventually this makes it’s way to clojure.lang.Compiler.Compile.
- This uses a GenContext, a TypeBuilder, and a CljILGen to generate IL into the context, then finally save it to an assembly with GenContext::SaveAssembly.
- GenContext::SaveAssembly uses the DLR to actually write out the assembly.
- compile-path is where the assemblies go, not where it expects to find src files.
- When looking for source files, the compiler looks at the environment
variable CLOJURE_LOAD_PATH, in addition to a bunch of other places.
- CLOJURE_LOAD_PATH can contain multiple paths delimited by Path.PathSeparator.
- clojure.core/*compiler-options*
- {:elide-meta #{:some-key :some-other-key} :disable-locals-clearing true|false{}
- I would hate working on this if I hadn’t NGen’d Clojure.Compile…so fast!
- x64 vs. x32
- If we make a nuget package for it, we could make a camp task to compile ClojureScript.
- In emacs, with projectile, clojure-mode
- I have my compile command set to something like:
msbuild /t:CampExe /verbosity:minimal && targets\camp.main.exe ...
- When I was making the new task, I created a scratch project like:
targets\camp.main.exe new scratch-project
- For other tasks, I just cd into the scratch project and run camp
out of targets. Like right now, working on compile task:
msbuild /t:CampExe /verbosity:minimal && \ cd scratch-project && \ ..\targets\camp.main.exe compile
- With the NGen’d compiler being so fast, I have been using println debugging and just looking at the compilation buffer output. That has been working pretty well so far.
- Many times, I’ve really wanted to use a repl, though.
- I don’t know how well nrepl works with ClojureCLR yet, but it’s on my TODO list to investigate this.
- I’m not that interested in a plain-old REPL, I want to be able to use the REPL in emacs and eval forms while I am working.
I added build targets for testing, so “msbuild /verbosity:minimal /t:TestCompile”, etc.
- NuGet Guidance on Package Id Conventions
- Like .NET namespaces
- Don’t use dashes, use dots instead
- Maybe camp itself could turn slashes in dependency specs into dots?
- This would look more like clojure
- Not finding much else in the way of guidance or specification of legal package ids.
- IncludeReferencedProjects option to nuget pack
- Configuration option to nuget pack
- Seems related to profiles
- tools files
- Might make sense to support designating some files as tools
- tools is how chocolatey works, so maybe this would be a nice way to unify application and library packaging.
- content
- Gets copied to root of application, so need to support paths.
- Coming around to the idea that this is where most of the things packaged
into jars as resources on JVM clojure belong.
- Of course there are other kinds of resources, like the ones that belong
in .NET assembly resources.
- Deploying web applications this way makes a lot of sense.