Use rake-pipeline to build #533

Closed
wants to merge 4 commits into
from

2 participants

@xdissent

This is an attempt at unifying ember builds with rake-pipeline, with some caveats:

It still needs to generate an ember-runtime.js if that's important, and the license is only added during the rake task which I could see being a problem. And the way I faked out minispade so it doesn't complain about missing modules when not testing the spade distribution is pretty lame.

I also added a dist query param to the tests page that allows you to test the different dist builds. It allows spade and min as possible values, falling back to the main build if empty.

@wagenet
Ember.js member

Can you send a pull request for this? Would love to get it properly reviewed and into master.

Yeah, but there are a couple of things that I know need to be done. I'd love to get the conversation going though.

It still needs to generate an ember-runtime.js if that's important, and the license is only added during the rake task which I could see being a problem. And the way I faked out minispade so it doesn't complain about missing modules when not testing the spade distribution is pretty lame. Otherwise, I've been using it for a couple days now with no problems. I'll send a pull request tomorrow morning.

@wagenet
Ember.js member

@xdissent, am I correct in thinking that the version of Ember you're creating with this has minispade requires in it?

@xdissent

Yes and no. The Assetfile builds 3 different ember distributions: one with minispade requires stripped (ember.js), one with mini spade requires stripped and minified (ember.min.js), and one with minispade requires intact (ember.spade.js).

There's a rake-pipeline helper called neuter.rb that handles walking the minispade dependency chain to make sure the order of compilation is correct, and then it strips the requires and concatenates.

@wagenet
Ember.js member

Ah cool, I haven't been keeping up with the new rake-pipeline features. How does ember.js compare to what we have currently?

@xdissent

There are a couple of chunks that are included in a different order, but it passes all the tests and I haven't had any problems. I think the order is different because IIRC the sproutcore compiler would only order files based on dependencies one sub-module deep and anything after that would just include the whole directory (alphabetically maybe?). I think I had to add a require or two in my repo to get all of the files included since I'm not relying on including a whole directory - only the files that are require()d.

@wagenet
Ember.js member

Sounds good. I'll try to give it a go soon. While you're at it, would you mind rebasing so it merges cleanly?

@xdissent

I rebased, but I can't push it to the same branch because it would obviously screw up the history. Newly rebased branch is at https://github.com/xdissent/ember.js/commits/rake-pipeline-rebase

Let me know if you'd like a new PR or whatever! Thanks

@wagenet
Ember.js member

Personally, I don't care if you overwrite the history in a PR branch, nor does Github. However, if you suspect anyone else has branched from you then it's probably better to avoid. In this case, I'd just recommend merging in master. Thanks!

@xdissent

I'm using that branch as a submodule in a couple of things right now, so I'd just be screwing myself =)
Also, I wasn't sure how github would handle the PR since the referenced commits would no longer exist (or would at least have different SHA's)

@wagenet
Ember.js member

@xdissent Github just redoes the commit list. Since rebasing isn't an option can you merge master? If not, one of us can do the merge manually.

@wagenet
Ember.js member

I've pushed this to the rake-pipeline branch with some additional fixes. I'll merge it to master as soon as I make sure it does fine on Travis.

@wagenet wagenet closed this Mar 7, 2012
@xdissent

💘

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment