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

[mosfet]

Hi,

I REALLY do not understand why you are using wxWidgets monolithic build.
I am not an linux expert but I think that every distribution provide a non monolithic version and
it forces people like me to recompile a special version of wxWIdgets just to compile C:B.
If someone could correct me because I am sure there is a reason for that( excpet that it's easier).

[mandrav]

How did you come to the conclusion that C::B requires a monolithic wx lib? :shock:

[mosfet]

How did you come to the conclusion that C::B requires a monolithic wx lib? :shock:

Here : http://wiki.codeblocks.org/index.php?title=Compiling_Code::Blocks_in_Linux_%28applies_to_all_distros%29
And Here  from CodeBlocks makefile:

Code

<Linker>
<Add library="wxmsw26"/>
<Add directory="sdk\tinyxml"/>
<Add directory="$(WX_DIR)\lib\gcc_dll\msw"/>
<Add directory="$(WX_DIR)\lib\gcc_dll$(WX_CFG)"/>
</Linker>

It's everywhere CodeBlocks is always linking with wxmsw26 (ie monolithic version).

A non monolithic version would be :

Code

<Linker>
<Add library="wxbase26"/>
<Add library="wxmsw_adv"/>
<Add library="wxmsw_core"/>
...
</Linker>

[thomas]

That's right. It's that way because it is the least painful way.

If you absolutely don't want monolithic, you can of course compile it differently, too. All you need to do is modify a few link libraries and a compiler flag.
Probably (I haven't tried that, but why shouldn't it work...) you can make a static build, too, if you like.

[mosfet]

Hum,

the problem is not it's possible or not (with some time everything is possible). The problem is appreciate C::B a lot and it would be very great if I could easily used it on windows AND Linux. I would like also to participate or to submit patches but if it uses a specific configuration it's not that easy because I need to play with different wxWidgets configurations.

For instance I am following the wiki to build it under linux and I still have issues.

But Actually I found the main problem is I am not patient, so I will do as everyone and I will use a monolithic version.

That's right. It's that way because it is the least painful way.

If you absolutely don't want monolithic, you can of course compile it differently, too. All you need to do is modify a few link libraries and a compiler flag.
Probably (I haven't tried that, but why shouldn't it work...) you can make a static build, too, if you like.

[takeshimiya]

When compiling C::B:
In C::B autotools build system both monolithic and non-monolithic are supported.
In C::B build system only monolithic is supported.

I'm trying to think if there is any easy way to include support to both... :?

[mandrav]

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...

[takeshimiya]

To me, the linux build is *much* easier than the windows one...

I'm little off-topic but I tried to say the same.
 
The fact that linux haves something like wx-config (or sdl-config, or gtk-config, ...) makes changing the build options of any library a lot easier.
But in windows there isn't even the concept of a configure, everything is done by hand.

So I'm thinking if we can do a simple "configure"-like system, to achieve something simmilar to what is in linux, in Windows.
Perhaps some AngelScript here and there, embedded (or not) in the Project files.

[thomas]

So I'm thinking if we can do a simple "configure"-like system, to achieve something simmilar to what is in Windows.
Perhaps some AngelScript here and there, embedded (or not) in the Project files.

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.

[mosfet]

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

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...

[mosfet]

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

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

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...

[takeshimiya]

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.

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]

That's right. It's that way because it is the least painful way.

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= 

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.