Author Topic: The 21 february 2006 build is out.  (Read 12438 times)

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5317
The 21 february 2006 build is out.
« on: February 21, 2006, 06:07:31 pm »
Get quick announcements through the RSS feed http://www.codeblocks.org/nightly/CodeBlock_RSS.xml
A link to the unicode windows wxWidget dll for Code::Blocks : http://download.berlios.de/codeblocks/wxmsw26u_gcc_cb.7z
For those who might need this one (when no MingW installed on your system) : the mingw10m.dll : http://download.berlios.de/codeblocks/mingwm10.7z

For support of ansi builds, a link to the ansi windows wxWidget dll for Code::Blocks : http://download.berlios.de/codeblocks/wxmsw26_gcc_cb.7z

The 21 February 2006 build is out.
  - Windows : http://download.berlios.de/codeblocks/CB_20060221_rev2056_win32.7z
  - Linux : not supported yet


Resolved Fixed:

  • Added ability to add hooks (callbacks) for when a project is loaded/saved. Can be used to add extensions to the project file. Everything goes in <Extensions> (under <Project> tag). Full documentation can be found in sdk/projectloader_hooks.h
  • Removed translations where none should be
    - cbThrow / cbException
    - cbAssert
    - MessageManager::DebugLog
    - a few compiler flags
  • Image Update

Regressions/Confirmed/Annoying/Common bugs:

  • DDE bug : clicking in windows explorer on a CB registered file throws an error message box
  • toolbar-images-not-changing-state (is a wx problem)


Offline Vampyre_Dark

  • Regular
  • ***
  • Posts: 255
  • Hello!
    • Somewhere Over The Rainbow...
Re: The 21 february 2006 build is out.
« Reply #1 on: February 22, 2006, 02:20:51 am »
Quote
Added ability to add hooks (callbacks) for when a project is loaded/saved. Can be used to add extensions to the project file. Everything goes in <Extensions> (under <Project> tag). Full documentation can be found in sdk/projectloader_hooks.h
  :?: Why would someone want to do this? (meant that in the way of not understanding the potential uses, not in the way of saying the feature is useless!)

Quote
DDE bug : clicking in windows explorer on a CB registered file throws an error message box
I've seen it written that people get this messagebox, and then the file opens anyways. This is the behaviour I used to see before. If the file opens anyways, could it just be the messagebox itself that comes up in error?  :lol: Just user speculation.
C::B Wishlist
~BOYCOTT THE EVIL YELLOW BOXES~

Offline takeshi miya

  • Lives here!
  • ****
  • Posts: 1487
Re: The 21 february 2006 build is out.
« Reply #2 on: February 22, 2006, 03:02:30 am »

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: The 21 february 2006 build is out.
« Reply #3 on: February 22, 2006, 08:37:28 am »
Quote
Added ability to add hooks (callbacks) for when a project is loaded/saved. Can be used to add extensions to the project file. Everything goes in <Extensions> (under <Project> tag). Full documentation can be found in sdk/projectloader_hooks.h
  :?: Why would someone want to do this? (meant that in the way of not understanding the potential uses, not in the way of saying the feature is useless!)

In a nutshell: to allow plugins to load/save custom per-project configuration from/to the project file.
Be patient!
This bug will be fixed soon...

Offline Fizick

  • Multiple posting newcomer
  • *
  • Posts: 13
Re: The 21 february 2006 build is out.
« Reply #4 on: February 22, 2006, 01:09:58 pm »
Is any chance to restore "export makefile" command?

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: The 21 february 2006 build is out.
« Reply #5 on: February 22, 2006, 01:53:08 pm »
Is any chance to restore "export makefile" command?

Yes but probably not in the near future.
It has to be rewritten from scratch...
Be patient!
This bug will be fixed soon...

Offline takeshi miya

  • Lives here!
  • ****
  • Posts: 1487
Re: The 21 february 2006 build is out.
« Reply #6 on: February 22, 2006, 02:10:52 pm »
Yes but probably not in the near future.
It has to be rewritten from scratch...

Yiannis, do you think that (after the compiler redesign), instead of adding support for hardcoded makefiles, would be easier/better to add bakefile export support (among that the format is easier and it's xml)?

Currently with a bakefile you can generate:
-MS Visual C++ projects
-MS eMbedded Visual C++ projects
-Borland C++ Builder X projects
-Xcode 2 projects
-MS Visual C++ makefiles
-MinGW makefiles
-GNU GCC makefiles
-Symbian makefiles
-Borland makefiles
-Digital Mars makefiles
-Open Watcom makefiles
-Autoconf support
-Experimental, Code::Blocks projects, among others :o

Of course, that's for long-term future and after the compiler redesign. :)

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: The 21 february 2006 build is out.
« Reply #7 on: February 22, 2006, 02:21:38 pm »
Quote
Yiannis, do you think that (after the compiler redesign), instead of adding support for hardcoded makefiles, would be easier/better to add bakefile export support (among that the format is easier and it's xml)?

Quite possibly, yes.
The exporting will be abstracted so it can export to more than Makefiles, just by writing a new exporter and plugging it in.
So, I guess it 'd be possible to create exporters for Makefiles, Qt project files, bakefiles and (who knows?) maybe even autotools.
We will initially just provide the interfaces and the Makefile exporter. After that we 'll be accepting contributions/patches ;)
Be patient!
This bug will be fixed soon...

Offline takeshi miya

  • Lives here!
  • ****
  • Posts: 1487
Re: The 21 february 2006 build is out.
« Reply #8 on: February 22, 2006, 02:33:06 pm »
Quote
Yiannis, do you think that (after the compiler redesign), instead of adding support for hardcoded makefiles, would be easier/better to add bakefile export support (among that the format is easier and it's xml)?

Quite possibly, yes.
The exporting will be abstracted so it can export to more than Makefiles, just by writing a new exporter and plugging it in.
So, I guess it 'd be possible to create exporters for Makefiles, Qt project files, bakefiles and (who knows?) maybe even autotools.
We will initially just provide the interfaces and the Makefile exporter. After that we 'll be accepting contributions/patches ;)

That's good to hear :D

Offline Kagan

  • Single posting newcomer
  • *
  • Posts: 3
Re: The 21 february 2006 build is out.
« Reply #9 on: February 22, 2006, 03:21:02 pm »
Hi,

I am rather new user of codeblocks. The first remark I have to make is: Great Job!!!

To this nightly build I have a remark and a question.

The question is about the compiler warnings using MinGW. I installed QT Library version 4.1 and compiled the above micro project with the option "Enable standard compiler warnings [W]". I get 13 warnings, all from some QT Header files. A small QT Application with a main window and a few widgets creates easily hundreds of warnings, that means the warnings about my code are somewhere inbetween and get flooded among all the other warnings. The performance also suffers a lot.

So, one could say this is a QT Problem. On the other hand, QT is very successfull, so I assume these guys know what they do and they probably have their reasons to implement their stuff as it is. What I am looking for is a way to supress warnings that come out of QT Headers. Is there a compiler option or a code blocks mechanism to supress warnings from a certain directory?

The funny thing is, when I use the option to show all warnings instead of the standard ones, I don't get any warnings at all! So, there must be something wrong here...

I have installed this nightly build of codeblocks under Windows XP and created a QT Project using the template. As soon as I compile the main.cpp, the compiler complains about the QT Specific include files. The template usese $QTDIR to point to the correct include directories. This is an environment variable that I set correctly and it was working fine with the RC2. I realised, replacing $QTDIR with $(QTDIR) solves the problem. But this is quite boring to do using the IDE 10 times. Editing the code blocks project file with a text editor was easier, but ideally, one should not do that. Accesing the environment variable as $QTDIR is somewhat more sympathic to me, but there are probably reasons for this change. Maybe to make it more look like in a Makefile?

thanks,

Kagan