last version of C::B Advanced

[toneddu2000]

thanks for the clarification, revelator! Now I uderstood

[revelator]

Your welcome and dont worry your not the first to make this mistake.
New builds are up a bit later than i had planned because sourceforge went down while i was uploading yesterday upkoading the 32 bit build now,
the 64 bit build is allready up so if you got a 64 bit os you can get it now.

[revelator]

https://sourceforge.net/projects/cbadva ... 8-12-2014/ 64 bit Msys2
https://sourceforge.net/projects/cbadva ... 8-12-2014/ 32 bit Msys2

remember to uninstall previous version before installing this one so that the autodetect routine can kick in.

[toneddu2000]

You're awesome, revelator! Thanks a lot for sharing! But, what about Revelation engine? Are you planning to continue developing it?

[revelator]

Aye pace is just a bit slower now since i got a job again but since im also helping on the darkmod cleanups i might be in a good position to make more improvements,

[revelator]

Next release will not have a lot of new libraries but i added the ACE backends for people working with network protocols.
ACE is an adaptive communication environment toolset built in C++ and is targetted at people who want to develop high performance network protocols.
This seems like a nice thing for game developers who allways seem to struggle with less than optimal network performance in various opensource engines like Doom3.

For a more in depth overview look here http://www.cse.wustl.edu/~schmidt/ACE-overview.html

[revelator]

ok new builds are up.

Changes.

added gtkmm and friends.
added the ACE network libraries.
added zenity for gtk.

btw you can now also develop for PSP and other handheld devices with my package as it includes the mesa EGL GLES and GLSLANG libraries.

Also added a real X11 SDK for MinGW64 in case you need to port something that would only compile with X11, use CFLAGS etc to setup paths to the includes in /mingw/include/X11R6 and LIBS to link against libX11.

[revelator]

Next version will split into another package as im preparing a version with the CodeLite IDE (some might prefer that).
Also new Open Watcom Packages are on the way and im working on a replacement C++ standard library based on the apache stdcxx library. This will have to be a cross buils because stdcxx does not have
support for open watcom out of the box so im using the msvc tools to create the build scripts but the watcom compilers to build it. This might not be seamless so it might take me a while to get a working version.

[revelator]

new packages not up yet because of some troble with the new tools which are now mostly fixed.
changes:
iron python added, its a little braindead as the console functions dont work, atm its only used as a plugin for editra and provides enough functionality there.
editra, a python editor that can be used for other doc types as well.
pygtk, fully working now try pygtk-demo from the msys2 shell .
pyreadline a replacement for gnureadline needed by both editra and iron python.
clipboard, a python plugin to allow access to the clipboard needed by iron python.
pyzmq, is a ssh console plugin that was intended to work with iron pythons console but atm it causes a segfault if you try to use ipython console.

[revelator]

new packages up.

readline plugin still broken with iron python though and it seems to bee a cant fix as it would break other packages.
basically what happens is that iron python picks up the real readline library instead of the python version.

pygtk fully working now atleast .

pacman fixed a bug causing timeout messages to spam the console when updating.
updated crt runtimes and libraries and rebuilt gcc compilers.
updated winpthreads.

[revelator]

Open Watcom Compilers now also updated.

Changes:

A lot of stability issues fixed, and a few additions to the CRT (C++ still needs work but its slowly getting there, anyone with C++ knowledge concerning building a new STL from scratch are welcome to submit patches).
Open watcom while now able to operate with 64 bit logic still produces 32 bit executables so work on a 64 bit api would also be welcome.
Atm im trying to draft as many developers as possible to get this beautifull compiler up to speed, why you might ask well for one windows 95 was built with the old watcom compiler and it still has some very nice
optimizations for DOS/OS2 programs but the windows part needs a lot of work and if you help you can one day boast that you helped making this and it would also be a free community driven compiler who could rival the greatest free versions from MS and MinGW64 with better support for the windows platform as well as superb support for older OS like OS/2 and several free DOS clones.
Why not just stick with MinGW and offshots ? well to be frank as explained above this compiler actually kickstarted windows, it sports superior optimizations compared to a lot of even modern compilers but its also
a hard compiler to learn to control which is why many devs swear by it cause it forced them to actually learn how things work. Dont be afraid its not impossible to get this compiler to do what you want but it does
make things a little challenging. Needless to say there are many groups who can and will help you if you get stuck and jiri malak who maintains the source atm will help you as best he can or point you to members who can.

My build uses the intel compiler via msvc2013 which allows better optimization of the bootstrap compiler (saves a lot of time building this) but else its a pure openwatcom build.
If you need ms directx support you can pretty much replace the libraries and headers in h/nt/directx and lib386/nt/directx with the ones from whatever directx sdk you got from ms.

A few things are still a little dodgy like wxwidgets obcd32 support is broken same goes for a dynamically linked wxopengl library which fails with a linker error probably due to some more recent changes.
The thing is that openwatcom uses its own specialized calling convention __watcall which might need patching of some parts of a source to fix building it. Removal of this call would break openwatcoms auto optimization routines so its a between a rock and a hard place scenario. Besides that wxwidgets works fine with open watcom allthough the latest versions from 2.9.0 and up cannot be built with it due to changing more of the code to unsupported C++ routines. wxwidgets 2.8.12 builds just fine with it and the test prgrams work as a charm also.
curl also builds but i noticed i could not use ssl encryption due to some error. zlib ogg vorbis openal works just fine, as well as the png and jpeg libraries.
So all in all the C compiler seems to work for most purposes now the C++ compiler still needs a hand.

[revelator]

Latest build here https://sourceforge.net/projects/cbadva ... 1-02-2015/

[revelator]

just a little hehe moment to make some of you drool

[revelator]

next version will reintroduce gcc with plugin support and i will attempt resurrecting the dragonegg/clang plugin for mingw64.
allready done better patch for plugin support for windows, old one sorta brute forced plugin support mine actually checks to see if the nessesary support is there eg. you need dlfcn_win32 atleast untill i can patch in
a replacement directly in gcc.

dragonegg is a plugin allowing gcc to take advantage of clangs optimizations, the downside to it is that unlike linux where dragonegg can be used as a single module supporting all compilers the windows versions needs several different plugins, so if you compile a C program you need gcc -fuse-plugin=dragonegg-cc1 for C++ -fuse-plugin=dragonegg-cc1plus for fortran -fuse-plugin=dragonegg-f951 etc.
so if setting up an auto tool based project you would have to export CC=gcc -fuse-plugin=dragonegg-cc1 CXX=g++ -fuse-plugin=dragonegg-cc1plus.
Still its worth having

[revelator]

Uploading new version now.

The msys2 compiler was singled out of the main Msys2 paths making sure the MinGW64 compilers will newer pick up the Msys2 api and try to use them instead.
Theres now a MinGW64 version of flex but it does not allways play nice with autotool based environments so its prefixed with the cross prefix to keep it from interfering with normal Msys2 based flex.
GTK2 and GTK3 have been updated to fix a few bugs.
Python GTK fixed a silly bug preventing the demos from running.
Msys2 gcc updated to version 4.9.2 and installed into its own sub directory to keep it from interfering with the MinGW64 compilers.
Python 2 and 3 have also been updated.