New unofficial installer for Code::Blocks available for testing!

[grunerite]

THIS IS NOT THE OFFICIAL INSTALLER OF Code::Blocks!!! I just need some people to try it beforehand.

I tried it. It works. The only complaint I have is on the page where you select the components to install, the window listing all the plugins is way too skinny.

Seems there is plenty of room at the left, if you can get the 1 line of text over to the left to sit up above the box listing all the components.
Cheers

[Conan Kudo]

Alright, I have finished my beta10 of my installer, and I decided to release it today, and it is available for 7 days. It contains Code::Blocks 1.0 April 18st nightly (ANSI).  By the time the seven days are up, I hope to have a new version, which will contain the latest nightly... Well, here it is! YSI says it will last either 7 days or 10 downloads, whichever comes first! So, the really important people should get this build ASAP!

Link: Installer updated - Click here to go to post about latest version!

Featureset:

• Code::Blocks transparent logo at startup
• Variable directory paths and start menu folders
• Componentization of C::B nightly based on RC2
• Quick, speedy installation
• Code::Blocks application logo used as icon for installer
• Basic rewrite complete
• MSI-like functionality written in
• InstallShield-style look, ultrahigh solid LZMA compression
• Repair functionality, allows repairing of installation if corrupt
• Componentized uninstallation
• MinGW included within package to support componentized uninstallation
• Components selection space adequate now
• System key identifies Codeblocks program correctly

Problems/Planned Features/Unfortunate Side-effects:

• Splash is dithered to 256 colours, working on getting it to work properly Limited by GIF format restrictions
• OS detection disabled and ANSI version is installed because installer incorrectly identifies all Windows OSes as Windows 2000, permitting installation of unicode version; still investigating
• Due to overwhelming opposition, hotpatching will NOT be included

EDIT: THIS IS THE NEW RC3rv2 build, containing a new ANSI build and various fixes in the installer script

THIS IS NOT THE OFFICIAL INSTALLER OF Code::Blocks!!! I just need some people to try it beforehand.

[MoonKid]

It contains Code::Blocks 1.0 April 1st nightly (ANSI). 

Please tell us if there is a newer ANSI-build is available by this installer!

[killerbot]

nope, will create a new ansi build tomorrow

[Conan Kudo]

The new ANSI build is included now... Also, various fixes have been applied, including no dependancy on filenames... Hope you like it... Please be very critical and talk about bugs here, and other critiques...

[troels]

Alright, I have finished my Release Candidate 3 of my installer....

It works fine here. Very goodlooking. Notes:

1. I look in vain for mingw32-make.exe. Is it hiding under some other name? (I need it to build wxWidgets!)
2. Repair doesn't seem to repair
3. Why Ansi? Unicode is probably better for the majority of users.

EDIT: Ad. 1: A fully-fledged CB workspace for building wxWidgets would be better, render make redundant. Is anybody sitting on a nice wxWidgets workspace?
Ad. 2: Try removing some files, eg. Codeblocks\bin\mingw32-c++.exe etc, and then do a repair.
The files does not reappear! (at least not on my system)

• about MinGW, you should know that it's not certain that the next release will include it.

What a pity if it isn't. CB+MinGW is one extraordinary bundle.
Like all other software CB comes over better if it works right out of the box.
(Without a compiler it doesn't. Windows people at least expects the full treatment :) )
Also, the bundle signals quite clearly which (version of the) compiler CB is intended for/most tested together with/endorsed by you.
Speaking of which, is gcc 3.4.5 (the version included here) the best known version? Isn't 4.0.1 ready for prime time?

Sidenote:
Sadly the upgrade from 3.4.4 (CB RC2) to 3.4.5 (April 18st nightly installer) didn't help me any, same result.
http://forums.codeblocks.org/index.php?topic=2212.msg17478#msg17478
I've been scanning global scope for bad initialization, removing XRCID("") from global static variables, still no luck.
EDIT: Guess I'm ready for 4.x....

Greetings
Troels

[Michael]

• about MinGW, you should know that it's not certain that the next release will include it.

What a pity if it isn't. CB+MinGW is one extraordinary bundle.
Like all other software CB comes over better if it works right out of the box.
(Without a compiler it doesn't. Windows people at least expects the full treatment :) )
Also, the bundle signals quite clearly which (version of the) compiler CB is intended for/most tested together with/endorsed by you.

IMHO, it is better to install MinGW separately :). It is easy and does not require specific knowledge (there is an installer that do the job). Moreover, I have found more difficult to update the MinGW bundled to C::B.

Speaking of which, is gcc 3.4.5 (the version included here) the best known version? Isn't 4.0.1 ready for prime time?

Well, there is GCC 4.1.0 that Ceniza has made available (look at Ceniza's signature :)). Anyway, AFAIK there is not information on a version 4.x.x. MinGW devs released gcc 3.4.5 not too much time ago... :roll:

Best wishes,
Michael

[Conan Kudo]

I forgot to plug in NASM, whoops... And mingw32-make was accidently writing as an invalid filename, I fixed it now, it has been uploaded... rc3rv2 will be available soon... updating MinGW is easy... It can be done by two ways... One way, simple, is to extract the tarballs onto the CodeBlocks directory... Another way is to create MinGW patches for the installer to handle and update... It is available, but I plugged in a function to disable it... I used an ANSI build so our good Windows 9x users can test it... If a libunicows build is made, then I will replace ANSI with the libunicows build... Otherwise, until I have had sufficient testing and I then transfer the script to C::B devs, I will put ANSI builds because the OS detection plugin doesn't work properly with the script... I'm probably going to strike out the OS detection because it is pointless.. The repair function works, but it looks like it does not work... Just wait, and it will reinstall... If this is confirmed by one more person other than you, I will do some work on it...

[troels]

I used an ANSI build so our good Windows 9x users can test it...

Well, my system is Unicode Windows, running Ansi makes Windows do nonstop string conversions (Ansi<->Unicode<->Ansi), not so great. ['National' chars might even end up garbled.]
Surely the primary target group cannot be Windows 9x users. Secondary target group at best. Deploying one's stuff on Windows 9x is one thing, but to use such an 'operative system' to develop it on is quite another matter. In my experience you cannot expect to do development stuff (esp. running the debugger, a heavyhanded demanding program) [on Windows 9x] - without endless rebooting. IMHO it's better to endorse use of 'proper' operating systems to developers, by providing Unicode builds first, Ansi a - distant - second.

IMHO, it is better to install MinGW separately . It is easy and does not require specific knowledge

It's one more installation job to trust, to deal with. A bulky one IIRC - I like Pharaohs trimmed down MinGW much better, it's lean and mean and does the job.

Well, there is GCC 4.1.0 that Ceniza has made available (look at Ceniza's signature .

Thanks! It's the latest and greatest - but doesn't sound too wx-friendly. Which gcc version is most wx-friendly I wonder?

EDIT: Nice to have: The gcc version used to build CB itself displayed in the CB About dialog box (__GNUC__/__GNUC_MINOR__/__GNUC_PATCHLEVEL__) . EDIT: Oh it's already there, in the start page...

/Troels

[Michael]

IMHO, it is better to install MinGW separately . It is easy and does not require specific knowledge

It's one more installation job to trust, to deal with. A bulky one IIRC - I like Pharaohs trimmed down MinGW much better, it's lean and mean and does the job.

I would tend to agree with you if the Installation of MinGW was hard. But it is easy. Just use the installer and then eventually update it.

Well, there is GCC 4.1.0 that Ceniza has made available (look at Ceniza's signature .

Thanks! It's the latest and greatest - but doesn't sound too wx-friendly. Which gcc version is most wx-friendly I wonder?

I have heard that someone has built GCC 4.2 . Anyway, there is a problem with GCC 4.1 when compiling wxWidgets. GCC 3.4.4 works fine, but I would use instead GCC 3.4.5 with wxWidgets (should be a bit more up to date).

I just wonder if GCC 4.0.x would work with wxWidgets...

Best wishes,
Michael

[troels]

GCC 3.4.4 works fine, but I would use instead GCC 3.4.5 with wxWidgets (should be a bit more up to date).

Thanks! I'll stick with 3.4.5 for the time being then.

Greetings
Troels

[artoj]

As far as I know, Inno Setup does not support web patching

It does: Inno Setup Download DLL

Though, maybe a better solution would be use this wxWidgets autoupdate project: http://wxcode.sourceforge.net/docs/webupdate/index.html

[Conan Kudo]

As far as I know, Inno Setup does not support web patching

It does: Inno Setup Download DLL

Though, maybe a better solution would be use this wxWidgets autoupdate project: http://wxcode.sourceforge.net/docs/webupdate/index.html

Note that I said, "Web Patching", I did not say, "Web downloading"... I am aware of Inno Setup's Download DLL, however, it has problems with proxies, handlers, and system anonymizers... It seems NSIS's plugin NSISdl seems to work perfectly with it... Although, probably the only component planned for web downloading would be MinGW...

I used an ANSI build so our good Windows 9x users can test it...

Well, my system is Unicode Windows, running Ansi makes Windows do nonstop string conversions (Ansi<->Unicode<->Ansi), not so great. ['National' chars might even end up garbled.]
Surely the primary target group cannot be Windows 9x users. Secondary target group at best. Deploying one's stuff on Windows 9x is one thing, but to use such an 'operative system' to develop it on is quite another matter. In my experience you cannot expect to do development stuff (esp. running the debugger, a heavyhanded demanding program) [on Windows 9x] - without endless rebooting. IMHO it's better to endorse use of 'proper' operating systems to developers, by providing Unicode builds first, Ansi a - distant - second.

The final installation script will contain a unicode build, and I hope by then a libunicows build is made so that there can be one build for both Windows 9x and Windows XP...

IMHO, it is better to install MinGW separately . It is easy and does not require specific knowledge

ALL COMPONENTS ARE BEING PACKAGED AS BEING ABLE TO DOWNLOAD FROM THE INTERNET!
I originally planned for only MinGW, but I decided to make everyone's life easier and componentize the packaging itself to allow all the components to be able to be downloaded from the internet and installed...

Problems/Planned Features/Unfortunate Side-effects:

• Splash is dithered to 256 colours, working on getting it to work properly

I figured out the problem with it, unfortunately, I need the someone to build the C::B transparent logo directly from the source image, because the PNG -> GIF conversion makes it dither to 256 colors... It would be great if whoever originally made the new C::B splash logo could make it as a GIF image that is transparent, because the splash plugin only supports GIF images... I know SOMEONE has the original source, I just do not know who...
EDIT: I am most likely going to leave the splash alone, it seems impossible...

[killerbot]

allrigthy some feedback.

this is what I have done :
1) start install (checked codecompletion)
  --> noticed some stuff got into Program files\common files\NSIS Installation Data
2) ran installed CB
3) add/remove programs -> uninstall
---> the installation dir is empty but still containes the complete directpry structure --> BUG
---> that NSis stuff is still there

overall impression : looks good, only downloading that weird named files is confusing for the user I think?

[Conan Kudo]

allrigthy some feedback.

this is what I have done :
1) start install (checked codecompletion)
  --> noticed some stuff got into Program files\common files\NSIS Installation Data
2) ran installed CB
3) add/remove programs -> uninstall
---> the installation dir is empty but still containes the complete directpry structure --> BUG
---> that NSis stuff is still there

overall impression : looks good, only downloading that weird named files is confusing for the user I think?

complete directory stucture bug is fixed, build uploaded shortly... The NSIS Installation Data folder keeps a copy of the installer to retain MSI-level functionality... Clicking on Change or activating the installer manually will cause a special dialog to pop up... The NSIS stuff is being investigated... The names are actually package IDs, the packages have names, but they contain IDs as well... The installer copies them to temp dirs as package IDs...