Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

Binary size reduction - UPX

<< < (2/5) > >>

thomas:
Your remark about TIFF and ODBC is truly a good objection. Those are huge beasts, and I guess you can safely assume nobody would miss them in an IDE. What about joysticks and sounds? :lol:

takeshimiya:
I'd suggest, for now, setting the following to zero:

#define wxUSE_JOYSTICK 0
#define wxUSE_MEDIACTRL 0
#define wxUSE_QUICKTIME 0
#define wxUSE_DIRECTSHOW 0
#define wxUSE_GSTREAMER 0
#define wxUSE_GLCANVAS 0
#define wxUSE_ODBC 0
#define wxUSE_LIBTIFF 0
#define wxUSE_GIF 0
#define wxUSE_PNM 0
#define wxUSE_PCX 0
#define wxUSE_IFF 0

And, try to make C::B compilable with DMars, MSVC, and other compilers (there is anyone working on this?).

thomas:

--- Quote from: takeshimiya on October 15, 2005, 05:56:37 am ---And, try to make C::B compilable with DMars, MSVC, and other compilers (there is anyone working on this?).
--- End quote ---

Hmm... I would not recommed that.

The major reason to use DM is its compilation speed, but gcc is on the order of 4 times faster with precompiled headers, too (thanks to tiwag, I finally managed to get these to work).
Compiling Code::Blocks out of the box (clean rebuild) takes just under 7 minutes for me, so assumed precompiled headers were used, that would be less than 2 minutes -- quite acceptable actually. In particular, during development, one typically changes only one or two files at a time (with maybe 4-5 dependencies), so we are talking about 5-6 seconds, which is nothing, really.

Supporting many compilers is a lot of extra work, very painful (not only to implement and to maintain compatibility, but also to follow the actual code), and brings a lot of disadvantages (guess why wxWindows is such a piece of crap - it is because they support so many compilers that don't know C++).
Of course, supporting only one compiler may be somewhat limiting (but name any half-way modern platform that gcc does not support). On the positive side, however, you have a much happier life and can take advantage of all the strengths the compiler offers while gcc will compile it on almost every platform the same way.

Realistically, most people will just use the plain vanilla binary for Windows anyway - let's face the facts.
Linux users in lack of a binary RPM may need to compile from sources, but they will likely use gcc (or the intel compiler, which is said to be compatible now), so that is fine. The same is true for any other platform. There is no MSVC or DM on Solaris, MacOS, or any other OS, so whether you support these or not, people have to use gcc anyway.
And for those few who really want to compile Code::Blocks themselves on Windows, getting a copy of gcc is really not asked too much, I think.

Execution speed may be another issue, as DM is said to produce faster code, but hey, we're talking about an IDE, not about a realtime MRI reconstruction application ;).

My two cents :)

takeshimiya:
Mm. Little off-topic, but I don't think it's good to only support GCC...

You'd blame wxWidgets for being a crap, but the problem is that wx supports compilers that doesn't know what a standard means. But it is not so with newer compilers.
Just support the compilers that are more or less compliant with the standards (I'm not talking about MSVC4 or GCC1.0).


Aside from that, due to the user doesn't having the GCC compiler or other reasons (libraries onlycompileable with borland).
For example, if C::B can't be compiled with OpenWatcom, you'll loose some specific platforms where it can work: Linux hardware (similar to framebuffer), Win32, X11 and OS/2, QNX, SMX and even DOS, through MGL.

As for precompiler headers, there are a lot of people that doesn't know how to use them, or don't want to (for the side effects).
I can estimate that you can compile with DMars, for example, Code::Blocks entirely in 20 seconds or less without precompiler headers.

Anyways, C::B is written in a very cross-compiler way (ie. trying to not use STL), so I think there would be little things here and there to check, for supporting other compilers.


As a bottom note, GCC isn't the universe, it's slow, bloated, makes big executables, the win32 port of the linker have problems with removing dead code, and more important, GCC is not 100% compliant with the standard (althrough there isn't almost any compiler 100% compliant). But, I still like GCC. :)

thomas:
The point I am having about gcc is that it works on every serious platform (except the C64 and the ZX80 maybe ;)).
Most likely, it even works without changing one line of code. This is no longer true if you support other compilers. As a matter of fact, DM does not work for me at all on anything non-trivial. This may be my fault of course, but as a matter of fact, gcc runs everything I feed to it out of the box.

I think development time and energy is best spent where you get the largest benefit for the largest number of people. Trying to get everything right for everybody can break your neck.
Probably 75% of all people will use the standard Windows executable without ever thinking about compiling their own. Most people use Windows, this is a fact, whether we like it or not, and most people do not want to compile the software they use, they just expect it to run off an installer.
Out of the remaining quarter, a few dozen people will actually be developing Code::Blocks, the vast majority will be Linux/x86 users (and a few FreeBSDers). All other users together might make up around 1-2% of the total population (and most of them will actually have gcc available).

Navigation

[0] Message Index

[#] Next page

[*] Previous page