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

Don't understand why C::B used a monolithic build

<< < (3/4) > >>

mosfet:
Waouuu!
It works and the new wxAUI is really great!
Thanks to C::B debeloppers !!!!






--- Quote from: mosfet on January 10, 2006, 07:17:44 pm ---Good news : while I am posting C::B is compiling on my Mandriva 2006.
My error was to follow the wiki.

I have just added wxWidgets rpm for my distrib instead of building a new one as indicated and
after bootstrap, ./configure, make.
So indeed C::B compiles fine with any version.

My mistake




--- Quote from: mandrav on January 10, 2006, 07:00:27 pm ---You don't have to use a monolithic wx lib. When I wrote the instructions at the wiki, wx2.6 wasn't even standard in distros so I just used the windows-build-howto as a starting point.
The thing is that in linux wx-config is used, so no matter how you compile it, it will still work correctly.
The only place we "force" you to use a monolithic wx build is the project file. But nothing's stopping you from changing it to use a non-monolithic version.

Finally, I don't understand why people think that *I* make it hard to build C::B in linux :shock:.
I 've put every effort to make the process as easy as in windows, at least. To me, the linux build is *much* easier than the windows one...

--- End quote ---





--- End quote ---

takeshimiya:

--- Quote from: thomas on January 10, 2006, 07:11:14 pm ---Why though? It works fine the way it is, there's no benefit in changing it. The more complex and non-standard you make it, the more likely you make an error.

--- End quote ---

Well,
1) wxWidgets: If I want to build C::B with non-monolithic wxWidgets, I would have to change all the projects, which is cumbersone (the project files changes very often in SVN), and no one-would do.
Maintaining two different projects (monolithic-nonmonolithic) is not an option neither, because in the past always when tried to make support to more than one, the rest is not updated (remember CodeBlocks-NewBuild.cbp, CodeBlocks-unix.cbp, CodeBlocks-wx2.6.0.cbp, CodeBlocks-wx2.4.cbp, CodeBlocks-NewBuild-Unicode.cbp, CodeBlocks-unix-wx2.4.cbp ?). And this will happen again everytime C::B wants to support multiple versions or configurations of libraries it uses.

2) Other projects: Any project that uses a configure script in linux (SDL, GTK, wx, QT,  etc), and even personal projects, will benefit from the concept "./configure" in Windows.
Having to choose manually what to compile instead of relying on a configure-does-the-job is not easy to do.

The only simmilar thing I can see in windows is MSYS.
But the principal problem is that it weights, very few people have it installed, and the thing I'm trying to make a point: configure scripts.
They are written by hand, I don't understand them fully, neither most windows users.

That's why my proposal of creating something like a SIMPLE little configure script, integrated and with a GUI in Code::Blocks, so that any project made in C::B can use that concept.

In one line: C::B currently replaces the makefile system (not so a year ago) which is a good thing, but does not yet replace the configure system which is what is lacking.

rickg22:

--- Quote from: thomas on January 10, 2006, 06:38:34 pm ---That's right. It's that way because it is the least painful way.

--- End quote ---

And don't forget about XRC. By registering all handlers, C::B (or XRC actually) automatically requires all the widgets to be loaded.

takeshimiya:
And adding a real example:

When you compile wxWidgets with MinGW for example, it creates a file in wxWidgets-2.6.2\lib\gcc_dll\mswu called build.cfg.

The contents of build.cfg is as following:

--- Code: ---WXVER_MAJOR=2
WXVER_MINOR=6
WXVER_RELEASE=2
BUILD=release
MONOLITHIC=1
SHARED=1
UNICODE=1
WXUNIV=0
CFG=
VENDOR=cb
OFFICIAL_BUILD=0
DEBUG_FLAG=default
DEBUG_INFO=default
RUNTIME_LIBS=dynamic
MSLU=1
USE_EXCEPTIONS=1
USE_THREADS=1
USE_GUI=1
USE_HTML=1
USE_ODBC=0
USE_OPENGL=0
USE_QA=1
COMPILER=gcc
CC=gcc
CXX=g++
CFLAGS=
CPPFLAGS=
CXXFLAGS=
LDFLAGS=

--- End code ---

which could be easily parsed from C::B, and reading the values up in C::B Global Variables, obviously adapting the project files to reflect the changes.

thomas:
You are very welcome to contribute a system that implements a function similar to configure for Code::Blocks.

With GUI if you like.

Navigation

[0] Message Index

[#] Next page

[*] Previous page