Versions tag

[JoeDupuis]

As stated in #56 it might be a good idea to tag the version on commits. I wanted to check the diff between two versions, but can't do so without checking each commit individually to find the versions change at the

On my personal and work project, I work with a develop and a master branch following this git workflow:
http://nvie.com/posts/a-successful-git-branching-model/

There is tools that help following this workflow without doing the step manually:
https://github.com/nvie/gitflow (CLI)
http://www.sourcetreeapp.com (GUI not sure if gitflow has been implemented on windows yet, it wasn't last time I check but works great on OSX).

Even if we don't use the proposed workflow (which I think help to keep the repository clean), I still think we should tag versions number on commit that are bundled as version on sourceforge.

[vpmedia]

Yes, previous community releases very a bit ad-hoc and not really organized.
I use SourceTree and I'm familiar with the mentioned branching model, so It's fine for me.

[vpmedia]

I had to close some open work on FreeGLUT integration (it was built with the samples) but it's ready, so hopefully I can switch to feature branches from now.

[vpmedia]

I'll check gitflow for win. because not used before:
https://github.com/nvie/gitflow/wiki/Windows
(mostly i'm working on win.)

[vpmedia]

I've changed the versioning scheme to the same as Adobe does.
So next CrossBridge will be v15.0.0.X, and every time when a new AIR SDK is releases, we can bump the major version also. I see no need for minor and patch versions, I like the simplified concept:
15.0.0.1
....
15.0.0.222 (last number is the build number)

[vpmedia]

https://github.com/crossbridge-community/crossbridge/releases

[JoeDupuis]

Perfect. So the master branch is the release branch, the master-dev is the dev branch? What is the futures branch? I guess that the llvm33 is to update to llvm33 and clang ?

[rtissera]

Getting LLVM 3.3+ working would be a game changer for CrossBridge.

2014-09-15 17:17 GMT+02:00 Joé Dupuis [email protected]:

Perfect. So the master branch is the release branch, the master-dev is the
dev branch? What is the futures branch? I guess that the llvm33 is to
update to llvm33 and clang ?

—
Reply to this email directly or view it on GitHub
#57 (comment)
.

[JoeDupuis]

What are the differences with 3.3 and what's used at the moment?

[vpmedia]

Yes - futures is LLVM 3.1 started by Adobe but unfinished. I've applied most of the patches into the LLVM 3.3 branch, but I'm sure there are missing parts.

I've made tickets with 'Futures' and 'LLVM33' ( #35 ) prefixes with some issues (most of them are show stoppers).

I was thinking about testing a 'Futures' release without SWIG ( #17 ), because that tool which is crashing during compliation.

[vpmedia]

Some docs:
https://github.com/crossbridge-community/crossbridge/blob/futures/LLVM_UPGRADE.md
https://github.com/crossbridge-community/crossbridge/blob/futures/COMPILER.md

In short Futures switched GCC into Clang compiler, but my impression during review was, that It's everything but a drop-in-replacement (as advertised) : ) - Also Clang was noticeable slower than GCC, as I've read some docs, they've improved it in the current 3.4.X+ versions..
And the goal would be to support C++11 code bases, which is unsupported by the master branchs GCC 4.2.

To be honest, I'm okay porting some libs with pure C, I don't code in C++11 but I aknowledge that newer game engines are written in C++.

[JoeDupuis]

I haven't looked at the code for swig yet, but removing the references to LLVM (if possible) might allow us to merge back swig into the main swig project and remove most of the compilation error in futures or llvm3.3

[vpmedia]

I think SWIG is a wonderful tool! Maybe a complete separated language translator would be useful. But I think it's complicated, since the differences between a native desktop app. and a flash web app environment (system APIs).

[JoeDupuis]

I haven't check the code for as3 swig yet, but know the code for the main swig project pretty well and I am not sure that I understand how this is a problem. Since swig run natively and only has to write the bindings of given functions without knowing anything from the target platform (only text generation based on a set of rules).

[rtissera]

Short answer : LLVM 3.3 will make compiler better and SWF execution speed
faster.
Long answer : Clang/LLVM 3.3 brings a modern C/C++ compiler instead of
aging, clunky GCC 4.2, better code generation, and increased performance to
generated IR bytecode, which means better (theorically faster) AVM2
bytecode.

2014-09-15 17:36 GMT+02:00 Joé Dupuis [email protected]:

I haven't check the code for as3 swig yet, but know the code for the main
swig project pretty well and I am not sure that I understand how this is a
problem. Since swig run natively and only has to write the bindings of
given functions without knowing anything from the target platform (only
text generation based on a set of rules).

—
Reply to this email directly or view it on GitHub
#57 (comment)
.

[JoeDupuis]

That's what I thought. I wasn't sure if there was not some hidden perk to llvm3.3 vs the current one.

[JoeDupuis]

I am trying to see what can be done with swig. I am still trying to figure out how things works, so correct me if am wrong, but there is some vanilla untouched package in the packages folder and those packages are then patched with the files from the patches folder before getting compiled ?

[JoeDupuis]

Okay I just cheked the makefile, nevermind.

[vpmedia]

Yes, I've simplified those a lot, because the original adobe repo. contained everything unpacked, so it was like millions of source files.
In the patches I've tried to apply a // CROSSBRIDGE PATCH START comment, but there are still other comments like AVM2 and FLASCC in the patched sources.

[vpmedia]

a complete sdk build takes a lot of time right now.
but you can use: make all LIGHTSDK=1 , which skips the extralibs
or just copy an existing "sdk" folder into the source root, so you can play with different makefile targets..
I've made an INSTALL.md which contains some tips.

[JoeDupuis]

I have two in-house project that might help maintaining the build system, we use them on almost all our projects now. They are also open-source, but I never bother writing docs, but I was planning to do so.

https://github.com/anhero/libbuildtool
https://github.com/anhero/generous

One of them handle exactly this kind of problem (bundling dependencies). Instead of adding the whole dependency to the git repo, (which need more maintenance when updating and bloat the git repo rapidly since it's harder for git to keep diff of binary files) we add small instruction file that tell our tools what to do. Each step (fetching, prebuild, build etc...) is customizable, but most of the time the instruction files are really small since most project use the default settings. So an instruction file looks like this :
https://github.com/anhero/BaconBox/blob/develop/libraries/SDL2.desc

Smaller footprint than bundling the whole project. When we want to update the version we changed the version number in the file and rerun the tool. The tool load the project, check the hash to be sure it downloaded without problem, unpack the project, patch it if needed, build it (if needed) and place it where you want it.

It's really similar to brew or a package manager but package are local to your project instead of local to the system.

It is a bit broken on windows right now, but if it is something that sound useful, I could fix it and create some kind of demo if you'd like to see how it works.

The other project help with makefile (or project) maintenance/generation. Our makefile was a pain to maintain on all our supported platform, so we created a tool similar to premake or cmake, but that doesn't rely on a compiled tool (It is just a ruby script). The configuration file can be a script, but we support yaml file and find it easier to maintain a yaml configuration file instead of a generation script.

Here is an example of a yaml config file:
https://github.com/anhero/BaconBox/blob/develop/generous.project
When we want to build (create the make file) we do so by calling:
generous && make (default)
generous -c Flash && make (flash)
generous -c Android && make (android)
etc...

I could also make a demo/video of how it is used.

Both tools are just ruby scripts so they can easily be bundled with the sdk's sources (no need for a user to download tools when he wan't to build the sdk). I usually wrap the tool with a fake configuration file so that a user that don't want to learn the tool doesn't have to.

I find it easier to maintains things on our projects with those tools, but it is just a proposition, I understand that using new tools means a new learning curve so they are likely to be unwanted.

[vpmedia]

I'm not really familiar with Ruby, but if it works with Windows than fine for me (the SDK already uses Java, Python, AS3, C, C++, Perl, so one more language does not make a big difference : )).