How-to: Build CDT and Cocotron Frameworks on Yosemite (Xcode 6.4)

[fsix]

Build CDT

- Download „The Cocotron“

—> git clone https://github.com/cjwl/cocotron.git

- Download „Homebrew“

—> ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

- Download  „GCC-4.9“

—> brew -v install homebrew/versions/gcc49

*** take a coffee ***

- Setup GCC-4.9 environment

—> cd /usr/bin && sudo mv gcc gcc-backup

—> sudo ln -s /usr/local/Cellar/gcc49/4.9.3/bin/gcc-4.9 gcc

- Create the following folder(s) (as root)

—> /Library/Application Support/Developer/Shared/Xcode/Specifications

- Switch to cocotron

—> cd cocotron/git/folder

—> cd InstallCDT

- Replace „gnutar“ through „bsdtar“ in the following files:

—> install.sh

—> Resources/scripts/unarchiveFiles.sh 

- Jump to „configureAndInstall_binutils()“ inside install.sh and replace „-Wno-error=deprecated-declarations“ through

—> -Wno-error

- Install CDT

—> sudo chmod u+x install.sh

—> sudo ./install.sh

*** take a coffee ***

- Add privileges:

—> sudo chmod -R a+rwx /Developer/Cocotron/

- Cleanup

—> cd /usr/bin

—> sudo mv gcc-backup gcc

—> brew uninstall homebrew/versions/gcc49 (optional)

Build Cocotron Frameworks (Foundation)

Windows

- Download updated pbcompspec

—> Cocotron-1.0-Windows-i386-gcc-4.3.1.pbcompspec

- Copy it to the Specifications folder

—> sudo cp -v Downloads/Cocotron-1.0-Windows-i386-gcc-4.3.1.pbcompspec /Library/Application\ Support/Developer/Shared/Xcode/Specifications  

- Fix ExecPath

—> sudo vim /Library/Application\ Support/Developer/Shared/Xcode/Specifications/Cocotron-1.0-Windows-i386-gcc-4.3.1.pbcompspec

—> replace "i386-mingw32msvc-gcc" with "i386-pc-mingw32msvc-gcc"

Now you should be able to build the windows scheme from Foundation.xcodeproj.

Darwin

- Fix pthread build error

—>  remove the spaces from < pthread.h > statement 

- Fix NSAutoreleasePool build error

—> Add the following private category to NSAutoreleasePools implementation file

@interface NSAutoreleasePool ()

id objc_autorelease(id object);
void *objc_autoreleasePoolPush();
void objc_autoreleasePoolPop(void *poolX);
void objc_autoreleasePoolAdd(struct objc_autoreleasepool *pool, id object);

@end

- Fix ObjCException build error

—> Remove its import statement

- Fix _NSGetExecutablePath build error

—> Add #include <mach-o/dyld.h> between #if defined(__APPLE__) and the following #endif

#if defined(__APPLE__)

#import "OBJCRegisterModule_Darwin.h"
#include <mach-o/dyld.h>

#endif

Happy Coding ;)

[cycl...@gmail.com]

Thank you for your installation minutes. It helped me a lot for getting started again with Cocotron now on Mac OS X 10.10.4  + Xcode 6.4.

Please allow me to add some findings:

1. I got installed MacPorts on my Mac, and instead of Homebrew I used sudo port install gcc49 and that worked out also fine.
   
   
2. I had an old Cocotron installation from 2011 in /Developer/Cocotron, and with that in place, The Cocotron master from github did build only with your modifications. However, once I moved the old frameworks out of the way, The Cocotron Master did almost build out of the box.
   
   
3. Almost means, only one minor modification was needed, namely objc/objc_exception.c had to be renamed to objc/objc_exception.m, otherwise it would not build, since the source contains some Objective-C syntax.
   

I am going to revamp my application from 2011. It builds against the latest Cocotron, but I have to resolve some issues, namely:

1. NSTextFields are not editable and some fields disappear when programmatically changing the text in an adjacent other one.
   
2. NSTableHeaderViews do not display the column titles
   
3. NSTabViews merely react on the first click
   
4. Moving and sizing of windows appears to be slow
   
5. The application crashes upon quitting.
   

Some work to do now. If some of said issues are known and perhaps resolved, please let me know your findings.

Best regards

Rolf

[Christopher Lloyd]

Hey Rolf,

Welcome back! Glad you are up and running again.

The clarify, the 'master' branch is new development, it contains the previous main branch from Google Code plus all significant changes outstanding on the former Google Code clones from everyone. The expectation is that there are regressions, I merged all the changes but have not done much testing.

The 'v1.0" branch was the stable, but not containing many new patches, main branch from the Google Code repo.

Going forward the plan is to get 'master' in good shape and then create a stable 1.1 release, and then repeat that going forward for progressive improvements. Feel free to setup a fork on github and issue pull requests or file issues.

Chris

[cycl...@gmail.com]

Hello Chris!

Am Mittwoch, 5. August 2015 21:56:24 UTC-3 schrieb Christopher Lloyd:

Hey Rolf,

Welcome back! Glad you are up and running again.

Thank you for the welcome, and for keeping Cocotron alive.

 

The clarify, the 'master' branch is new development, it contains the previous main branch from Google Code plus all significant changes outstanding on the former Google Code clones from everyone. The expectation is that there are regressions, I merged all the changes but have not done much testing.

The 'v1.0" branch was the stable, but not containing many new patches, main branch from the Google Code repo.

All very well, and thank you for merging also my old clone into the master. As a matter of fact, I was investigating the last weekend which branch would be the best to start over again.

In the meantime, with a few simple tweaks in cocotron-master, I resolved some of the issues that I mentioned in my other post. The problem of disappearing adjacent NSTextFields seems to be related to the view re-drawing optimizations by plasq. The construction of the dirtyrect using NSUnionRect() of some distant frames of respectively changed NSTextFields looks to me to be a too simple concept, because other non-changed NSTextFields, by chance sitting in the middle of the changed ones, would be cleared by the opaque ancestor but not re-drawn. Perhaps this prevents also the display of the column titles in a NSTableHeaderView. 

Going forward the plan is to get 'master' in good shape and then create a stable 1.1 release, and then repeat that going forward for progressive improvements. Feel free to setup a fork on github and issue pull requests or file issues.

I want to go a little bit deeper into the re-drawing issue of cocotron-master. Options are, to either substitute the dirty-(union)-rect concept by dirtyregions (sort of a set of non-collated dirtyrects), or to find out if there are other views intersecting the dirty-(union)-rect, which need to be re-drawn as well. If I fail with these efforts, then I would go back to v1.0, otherwise, I will submit my local changes for addition to v1.1. In either case, I would like to setup my own fork based on this upcoming stable release.

Best regards

Rolf

[Airy André]

Hi Rolf,

> Le 7 août 2015 à 03:21, cycl...@gmail.com a écrit :
>
> I want to go a little bit deeper into the re-drawing issue of cocotron-master. Options are, to either substitute the dirty-(union)-rect concept by dirtyregions (sort of a set of non-collated dirtyrects), or to find out if there are other views intersecting the dirty-(union)-rect, which need to be re-drawn as well. If I fail with these efforts, then I would go back to v1.0, otherwise, I will submit my local changes for addition to v1.1. In either case, I would like to setup my own fork based on this upcoming stable release.

I've not played yet with the recently merged master, but I think our code from the plasqdev fork about optimized views redrawing has been merged into it.
That code seems to work pretty well, at least with our app which is using optimized view redraws
Note that it's very probably only working properly when using AGG contexts (O2Context_AntiGrain plugin enabled)

In case there are issues about that with the master, you can check the clone we are using in our shipping app there : https://github.com/plasq/cocotron/tree/plasqdev-cocotron

Airy

[Airy ANDRE]

> Le 7 août 2015 à 03:21, cycl...@gmail.com a écrit :
>

> I want to go a little bit deeper into the re-drawing issue of cocotron-master. Options are, to either substitute the dirty-(union)-rect concept by dirtyregions (sort of a set of non-collated dirtyrects), or to find out if there are other views intersecting the dirty-(union)-rect, which need to be re-drawn as well. If I fail with these efforts, then I would go back to v1.0, otherwise, I will submit my local changes for addition to v1.1. In either case, I would like to setup my own fork based on this upcoming stable release.
>

[cycl...@gmail.com]

Hello Airy, many thanks for your kind response!

Following your suggestion, I just tested my application against the plasqdev clone, and as a matter of fact, with that one I do not experience the re-drawing issue of adjacent views. Also the titles in table headers are displayed. However, now I got other issues, most of which I know how to resolve, but one issue does give me headache, because this showed-up also with v1.0, namely starting editing of text cells in NSTableViews freezes the application. Later I will try O2Context_AntiGrain with cocotron-master. I will report the findings in another post.

Rolf

[cycl...@gmail.com]

I experienced major problems when trying to install O2Context_AntiGrain, and in addition I found out, that O2Context_AntiGrain was not enabled during my tests with plasqdev-cocotron. Therefore I simply replaced NSView.m in cocotron-master with the version of plasqdev-cocotron and that alone resolved the re-drawing problem. Actually this one does not contain your optimization changes from Feb 24, 2014 -- Fix double-redraw of some views. For the time being (until I get AntiGrain to work) I rolled back that change set in my local clone of master. This resolved the re-drawing issue of adjacent views. Column titles in the table header are still not displayed, so this is a different issue, that I am going to resolve next.

PS:

My trial to install of O2Context_AntiGrain has been forcibly stopped by the following compilation errors. I am quite rusty in C++ and I got only a very vague idea of what these messages wanting to tell me, at least not enough for me resolving this.

In file included from /Users/rolf/Desktop/NB/Cocotron-Debug/cocotron-master/O2Context_AntiGrain/agg_font_win32_tt.mm:17:

/Users/rolf/Desktop/NB/Cocotron-Debug/cocotron-master/O2Context_AntiGrain/agg_font_win32_tt.h:216: error: 'm_curves16' was not declared in this scope

/Users/rolf/Desktop/NB/Cocotron-Debug/cocotron-master/O2Context_AntiGrain/agg_font_win32_tt.h:216: error: template argument 2 is invalid

/Users/rolf/Desktop/NB/Cocotron-Debug/cocotron-master/O2Context_AntiGrain/agg_font_win32_tt.h:216: error: template argument 1 is invalid

/Users/rolf/Desktop/NB/Cocotron-Debug/cocotron-master/O2Context_AntiGrain/agg_font_win32_tt.h:217: error: 'm_curves32' was not declared in this scope

/Users/rolf/Desktop/NB/Cocotron-Debug/cocotron-master/O2Context_AntiGrain/agg_font_win32_tt.h:217: error: template argument 2 is invalid

/Users/rolf/Desktop/NB/Cocotron-Debug/cocotron-master/O2Context_AntiGrain/agg_font_win32_tt.h:217: error: template argument 1 is invalid

/Users/rolf/Desktop/NB/Cocotron-Debug/cocotron-master/O2Context_AntiGrain/agg_font_win32_tt.mm: In constructor 'agg::font_engine_win32_tt_base::font_engine_win32_tt_base(bool, HDC__*, unsigned int)':

/Users/rolf/Desktop/NB/Cocotron-Debug/cocotron-master/O2Context_AntiGrain/agg_font_win32_tt.mm:386: error: class 'agg::font_engine_win32_tt_base' does not have any field named 'm_curves16'

/Users/rolf/Desktop/NB/Cocotron-Debug/cocotron-master/O2Context_AntiGrain/agg_font_win32_tt.mm:387: error: class 'agg::font_engine_win32_tt_base' does not have any field named 'm_curves32'

/Users/rolf/Desktop/NB/Cocotron-Debug/cocotron-master/O2Context_AntiGrain/agg_font_win32_tt.mm:393: error: 'm_curves16' was not declared in this scope

/Users/rolf/Desktop/NB/Cocotron-Debug/cocotron-master/O2Context_AntiGrain/agg_font_win32_tt.mm:394: error: 'm_curves32' was not declared in this scope

/Users/rolf/Desktop/NB/Cocotron-Debug/cocotron-master/O2Context_AntiGrain/agg_font_win32_tt.mm: In member function 'bool agg::font_engine_win32_tt_base::prepare_glyph(unsigned int)':

/Users/rolf/Desktop/NB/Cocotron-Debug/cocotron-master/O2Context_AntiGrain/agg_font_win32_tt.mm:558: warning: enumeration value 'glyph_ren_native_mono' not handled in switch

/Users/rolf/Desktop/NB/Cocotron-Debug/cocotron-master/O2Context_AntiGrain/agg_font_win32_tt.mm:692: error: 'm_curves32' was not declared in this scope

/Users/rolf/Desktop/NB/Cocotron-Debug/cocotron-master/O2Context_AntiGrain/agg_font_win32_tt.mm:700: error: 'm_curves16' was not declared in this scope

/Users/rolf/Desktop/NB/Cocotron-Debug/cocotron-master/O2Context_AntiGrain/agg_font_win32_tt.mm:722: error: 'm_curves32' was not declared in this scope

/Users/rolf/Desktop/NB/Cocotron-Debug/cocotron-master/O2Context_AntiGrain/agg_font_win32_tt.mm:730: error: 'm_curves16' was not declared in this scope

/Users/rolf/Desktop/NB/Cocotron-Debug/cocotron-master/O2Context_AntiGrain/agg_font_win32_tt.mm: In member function 'void agg::font_engine_win32_tt_base::write_glyph_to(agg::int8u*) const':

/Users/rolf/Desktop/NB/Cocotron-Debug/cocotron-master/O2Context_AntiGrain/agg_font_win32_tt.mm:749: warning: enumeration value 'glyph_data_invalid' not handled in switch

 

[cycl...@gmail.com]

Am Mittwoch, 5. August 2015 21:56:24 UTC-3 schrieb Christopher Lloyd:

Hey Rolf,

... Feel free to setup a fork on github and issue pull requests or file issues.

 Hello Chris,

I setup a fork of cocotron-master on https://github.com/cyclaero/cocotron.git. I already applied some essential changes in order to make this to work with my application. I separated thematically my commits to my fork. Do you prefer a pull request of all commits together, or would you like seperate pull requests?

Best regards

Rolf

[Airy André]

> Le 8 août 2015 à 01:48, cycl...@gmail.com a écrit :
>
> My trial to install of O2Context_AntiGrain has been forcibly stopped by the following compilation errors. I am quite rusty in C++ and I got only a very vague idea of what these messages wanting to tell me, at least not enough for me resolving this.
>

No idea why it's going wrong for you.
I guess you've installed AGG first using the install_AntiGrain.sh script from the InstallCDT directory and it ran without error ?
There are a few optionlal scripts there that can install some optional libraries that might be needed by some Cocotron features.

Airy

[robert...@plasq.com]

As a follow-up to Airy, I'd remind everyone that you can't build AntiGrain debug. The compiler will crash. A release build is fine (though it sweats a lot).

We also noted that Microsoft's portability "project" is using Cairo instead of AntiGrain. It might be good at some point to revisit that integration in Cocotron

as AntiGrain is not being moved forward (and you can't get a debug build!)

Robert.

[Dr. Rolf Jansen]

 Yes, before anything else, I ran ./install_AntiGrain.sh from within InstallCDT of the local working copy of cocotron-master. I am running Mac OS 10.10.4 + Xcode 6.4, and I had to fix some search paths and furthermore manually edit the file O2Context_AntiGrain/O2Context_AntiGrain.xcodeproj/project.pbxproj for adding some directives in order to suppress passing of clang warnings to the win32 cross compiler:

   CLANG_WARN_CXX0X_EXTENSIONS = IGNORE;

   CLANG_WARN__EXIT_TIME_DESTRUCTORS = IGNORE;

   GCC_WARN_ABOUT_MISSING_PROTOTYPES = IGNORE;

Without these measures, any Antigrain building attempt bailed out long before the C++ syntax issue. Unfortunately, I am not save enough in C++ for debugging something like 'm_curves16' was not declared in this scope, while seeing the declaration right above the incriminated line. Maybe our cross compiler is too picky???

For the time being I continue without Antigrain.

Best regards

Rolf

[Christopher Lloyd]

Skip (skia.org) is another option here, it is Android's and Chrome's 2d rasterizer. The license is more flexible and it is maintained.

[Christopher Lloyd]

I have no strong preference with how the pull requests are organized at this time, do them how you want and we'll see how it goes.

Chris

[Dr. Rolf Jansen]

I am still in the warming-up phase with this distributed revision control stuff. When I did the commits to my fork of Cocotron, I was under the impression, that I later on could create pull requests for each commit separately. This does not seem to be possible. So, there comes a pull request of all my changes, also some of which were not meant to go into the master. I am sorry for the code bomb. Next time, I will try doing it better.

Rolf

[Markus Hitter]

Am 11.08.2015 um 13:03 schrieb Dr. Rolf Jansen:
> I am still in the warming-up phase with this distributed revision control
> stuff. When I did the commits to my fork of Cocotron, I was under the
> impression, that I later on could create pull requests for each commit
> separately. This does not seem to be possible.

Not an unusual experience, this "Pull Request" thing is a big mess. A maintainer can't even fix a typo, much less do simple regression tests before pulling via the web interface. And sending patches is prohibited by Github.

As maintainer (of another project hosted on Github) I usually add the requesting repo as another remote to my local repo, then copy the commits with cerry-pick. Another, less known feature of Github is that one can add ".patch" to the Github URL of a commit to receive the commit as a patch, ready to be applied with 'git am'. Seen in this light, a PR is a nice notification to the maintainer in the sense of "I think these commits are fine to be picked".

I also add collaborators to the project very liberally. Due to the nature of distributed version control I always have my local copy, so if one of these collaborators messes up, I can restore a sane state with a simple forced push. I ask these collaborators to contribute into their own branches. Branches are very cheap in Git, so they come and go as needed, often several ones for an issue handled. I found it important for community development to keep people together in a single repo; forks all to easily make them forget to send a Pull Request, so their work gets lost.


Markus

--
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. (FH) Markus Hitter
http://www.jump-ing.de/