Well I'm not sure if this is a good idea or not, but here goes. I'm wondering if the SDK could be included in the next RC of C::B.
I think it would be easier to use this way. I'm not saying that it should be forced on the user to install the SDK, but merely given the option if they desire to install it. Also if you use Windows you have to download another app that can decompress .tar.gz files this really isn't a big deal because 7-zip is free and it will decompress .tar.gz files This way people won't have to download three different things the C::B installer, the SDK, and possibly a file archiver. Maybe this is a bad idea, but I thought I would get it out there. :wink:
Given that perhaps 20% of users develop actually for C::B, and most of them compile from CVS anyway, I don't think it's worth the effort (moreover, there are people on dial up, so you must keep the size small).
It hink it is a good idea, but indeed you also need to keep it small :? perhaps you should use an other format for the SDK (zip?)
I agree with keeping size small because I used to have dial-ip :). Anyways maybe the SDK could be at least in .zip form, if not included in the installer.
I think .tar.bz2 it's better than .zip or .tar.gz as it compresses more (specially small files ie. source code), and it's rather a very common format today in the sourceforge projects. And even for windows, most programs can open them (ie. 7-zip, WinRAR, etc).
But I've noticed that most projects on sf.net use double releases, most of them release in both formats, .tar.bz2 and .zip, and some are distributing now in .7z also.
If needed I am willing to help releasing the SDK in different formats...
It would make more sense to create Packages, which can be installed under %code blocks%/.
So if you need the SDK, or a Compiler, you download the package, and install or copy it...
We can use devpacks for that...
if you want to make the setup smaller, you should perhaps use NSIS (http://nsis.sourceforge.net/) as installer.
Yeah NSIS is awesome.
I agree, NSIS is really great.
However there are at least three good reasons against using it:
1. The major benefit of NSIS it is the builtin LZMA compression, which is very superior.
Recent versions of Inno Setup have that, too, and the Code::Blocks installer already uses it.
The only possible gains are thus due to the installer's stub size, i.e. neglegible.
2. The present setup with InnoSetup works. There is no actual reason ot spend time
in creating a new setup (at the risk of introducing an error).
3. The developers are comfortable with Inno Setup, this is not necessarily true for NSIS.
They might actually have to spend time learning a different syntax.
Thomas is right on everything he said.
Quote from: Florianx on October 09, 2005, 02:42:08 PM
if you want to make the setup smaller, you should perhaps use NSIS (http://nsis.sourceforge.net/) as installer.
Have you created a similar C::B setup with NSIS and you 've seen a difference in size?
Or did you read somewhere that NSIS can produce smaller setups and you 're reproducing it here?
On the other hand side, you could of course make a NSIS installer script (wait until RC2 is out, though) and present it to Yiannis.
If you present him with an actual working, functionally identical version of a NSIS install script which produces an installer that is indeed 200-300k smaller, then it might really be worth to consider migrating.
Right, I 'm not bashing NSIS in any way here.
Quote from: mandrav on October 09, 2005, 04:39:22 PM
Have you created a similar C::B setup with NSIS and you 've seen a difference in size?
Or did you read somewhere that NSIS can produce smaller setups and you 're reproducing it here?
I have used NSIS in a few projects now, its really small. The installer (without data) ist normally smaller than 100kB.
I have created an nsis-script with basic futures and one language (english) for cvs head (a few days old).
It includes all normal plugins, but not the ones in the contrib-diir.
The installer is 3.02 MB. (11,9MB data + 87kB installer compressed to 25,1%)
Whats the size of the InnoSetup install.exe?
The 1.0rc2 setup file being prepared now, is 3.3Mb including all plugins (standard, contrib *and* off-site).
You might not know it, but it uses LZMA compression so, as Thomas pointed out, the only real difference (if any) is the stub size which is negligible...
There is nearly no difference, so no need to change the installer.
If anyone want to see or test my nsis-script, here it is:
(to build the exe, but the file in ./src/setup)
[attachment deleted by admin]
Quote from: mandrav on October 09, 2005, 11:26:35 PM
The 1.0rc2 setup file being prepared now, is 3.3Mb including all plugins (standard, contrib *and* off-site).
You might not know it, but it uses LZMA compression so, as Thomas pointed out, the only real difference (if any) is the stub size which is negligible...
This is Off-Topic a bit but does this mean rc2 is coming out soon? :wink:
Hopefuly ;)
After breeding over this subject for a couple of days, I was owned by curiosity. So I actually tried recompressing a freshly installed Code::Blocks distro.
The result is, unless I have done something seriously wrong, quite disappointing.
The installer was made using the HM NSIS editor wizard, includes everything inside the Code::Blocks installation directory, "modern" GUI, no branding bitmaps, one language (English). LZMA compression and relative filenames were used, standard uninstaller, no extras, no start menu entries, no bells no whistles.
(N.B.: NSIS could shave off a few kilobytes using the "classic" UI rather than "modern", but we have to compare apples to apples - the Inno installer uses "modern" style, too. Further, note that the Inno Installer uses branding bitmaps which I omitted.)
| Original installer: | 3.474.193 |
| NSIS 2.10: | 4.024.380 |
This is counterintuitive because it reads everywhere that NSIS builds the smallest installers, but I guess the numbers are quite clear.
UPDATE:Everybody knows that compressing compressed data is a really stupid idea.
Anyway, I said "what the heck", and ran UPX before building the installer.
exchndl.dll and
mingwm10.dll do not like being UPXed at all, you will need to reboot your PC to remove file locks and reinstall Code::Blocks to get it to work again (
upx -d will not restore functionality).
Everything else works just fine, though. Running
upx -9 codeblocks.dll codeblocks.exe wx*.dll before building the installer results in 3.863.688 bytes. Not much, but we're getting closer ;)
do you really used the best compression?:
SetCompressor /FINAL /SOLID LZMA
SetCompressorDictSize 32
But you're right, InnoSetup gots really small in one of the last versions.
I've tested InnoSetup a few years ago and there it has and overhead of more than 1MB and no 7z.
Ah indeed, it did not have solid compression. Did not watch out for that.
With the exact parameters given by you, it produces 3.426.439 bytes, about 48k less than Inno.
Note however, that this does not include the branding images (~160k uncompressed).
So it is not as disappointing as it seemed before, but you couldn't say it is really better, either.