Deciphering development branches, llvm33 and futures branches

[jasonsturges]

llvm33 and futures branches have become stale:

branch	behind	ahead	objective
llvm33	581	266	Upgrade to LLVM 3.3
futures	581	269	Upgrade to LLVM 3.2(?) and switch to Clang from GCC

futures branches from llvm33. Are these branches still expected to merge in to master?

master-dev branch is slightly behind master.

Also in play in conversion to new build system, libbuildtool.

As I become familiar and get up to speed, I'd like to work on documentation. Which branch should I work on? Or, should I focus on completing futures, merging back to llvm33?

[JoeDupuis]

Libbuildtool branch is on a fork at https://github.com/anhero/crossbridge

For the branch, we talked about renaming them to follow the git-flow convention in this thread #72

Once ported to libbuildtool the install step will be a bit more "modular" so it should be easier to port it to llvm 3.3/clang or later.

Also rewriting the build system, a bit less hardcoded to osx and cygwin should help solve some of the problem preventing a linux build.

There is no doc at the moment for libbuildtool. I wanted to write one before merging back into the project. It's not really hard to grasp just by looking at the code.

If you want to work on the project you can make your own feature branch or work on the dev branch. Following the git flow convention http://nvie.com/posts/a-successful-git-branching-model/

Or you can fork my fork and try to help with the libbuildtool port if you feel adventurous :-P

I want to keep a makefile that call libbuildtool to hide the tool so people would not have to know the behind the scene unless they want to.

[vpmedia]

futures and llvm33 are separated branches and should NOT be merged into master.
Originally adobe devs started the futures branch and I've made an attempt to update the LLVM compiler infrastructure but it seemed a huge effort for myself.

master-dev branch should be renamed to develop as we've aggreed with @twistedjoe to comform the git-flow workflow.
also commits from master should be merged back to develop I think.

[vpmedia]

Also this pull request is still important I think - if it really fixes compiling on newer OSX hosts without breaking anything:
#62
It would be great if someone could review this changeset and eventually merge it.
Right now its quite complicated to setup an OSX dev. env. to build CB. with GCC.

[JoeDupuis]

Yeah, and future dev should be made on develop until a release. The gitflow tool (or sourcetree which I recommend) handle that automatically.

[JoeDupuis]

The pull request was not building on my system, there were still some problems which I don't remember, but if @jasonsturges want to try (I think he is on OSX), maybe it's something with my system(I will try tonight). On my fork I was trying to remove everything that would make it break on a particular compiler and removing the "hardcoded" compiler selection. Allowing you to build it with whatever is already on your system (clang or gcc).

[jasonsturges]

@twistedjoe Yeah, I'm on OS X. This makes sense.

Mac build from master branch:

• Hardcodes the FP15 player from the AIR SDK.
• With Xcode 6.1.1, OS X target platform options CC=gcc-4.2, CXX=g++-4.2 are not installed
• Fails on llvm Makefile:316: recipe for target 'all_with_local_make' failed

I need to MacPorts dependencies, unless I should focus on using Libbuildtool.

[vpmedia]

Last docs about futures branch status and changes:
https://github.com/adobe-flash/crossbridge/blob/futures/overview_of_compiler_stages.md
https://github.com/adobe-flash/crossbridge/blob/futures/LLVM_UPGRADE.md

Some notes by me about dependencies:
https://github.com/crossbridge-community/crossbridge/blob/master/INSTALL.md

While building the SDK you can find useful .log files in the build folder to debug build issues..

Also you can try make LIGHTSDK=1 to NOT build extralibs which takes a lot of time..

[jasonsturges]

After switching to apple-gcc42, it made it to pkg-config which errors due to embedded glib dropped from pckconfig v0.26.

I'll log that in a separate ticket.

Per this ticket, I think I understand branches, build, and general strategy past and future. From here I'll implement git flow branching strategy and submit pull requests to review my commits.