Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

start modeling a tool based on boot, gulp, gradle instead of lein #5

Open
eginez opened this issue Dec 17, 2016 · 9 comments
Open

start modeling a tool based on boot, gulp, gradle instead of lein #5

eginez opened this issue Dec 17, 2016 · 9 comments

Comments

@eginez
Copy link
Owner

eginez commented Dec 17, 2016

No description provided.

@arichiardi
Copy link
Contributor

I would definitely take inspiration from boot about task options: https://github.com/boot-clj/boot/wiki/Task-Options-DSL

@arichiardi
Copy link
Contributor

arichiardi commented Feb 6, 2017

So I have had this idea for a while, what if we specify tasks and their options with data? I am trying to push this in boot as well, but, I think it would be valuable in any (clojure) build tool.

This is what is looks like (I have a macro ready for parsing this and creating boot tasks, but of course it would need some change for calvin tasks).

@eginez
Copy link
Owner Author

eginez commented Feb 6, 2017

that's an interesting idea. How do you envision we would share configurations from different tasks, when one or more keys need to be different, would there be any sort of inheritance/reuse?

@arichiardi
Copy link
Contributor

Basically at the moment there is one simple convention: a key in the shared conf contains options for the task it names. Every task is passed the content of the map.

If tasks have same options you will have a shared var (see env which is shared in there). This is also good because you can share with tasks that have different option names but accept basically the same thing ( : dependency vs :dependencies).

@arichiardi
Copy link
Contributor

I think this is what we were looking for 😀 https://github.com/juxt/mach

@eginez
Copy link
Owner Author

eginez commented Feb 7, 2017

In essence yes. I think it's a good idea to follow the target/task philosophy. However one of my goals is to have a pure cljs compiler and the above project seems to be relying on the jvm to do the actual build?.
But overall I like your idea of have options for each task and the developer can create new tasks or use the core ones

@eginez
Copy link
Owner Author

eginez commented Feb 7, 2017

FYI I just pushed a branch where I am using the bootstrapped compiler to compile very simple forms, so far so good, however I am still researching if we are going to need to use this https://github.com/google/closure-compiler-js

@arichiardi
Copy link
Contributor

arichiardi commented Feb 7, 2017 via email

@eginez
Copy link
Owner Author

eginez commented Feb 8, 2017

right building clojurescript without relying on the java . Sounds good let me know how it goes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants