News:

When registered with our forums, feel free to send a "here I am" post here to differ human beings from SPAM bots.

Main Menu

Release 15.12, RC1 has arrived

Started by killerbot, November 22, 2015, 09:15:53 PM

Previous topic - Next topic

dcorbit

My default Watcom 64 bit Fortran compiler location:
c:\Watcom\binnt64\wfl386.exe

My default Watcom 64 bit C/C++ compiler location:
C:\WATCOM\binnt64\wcl386.exe

MortenMacFly

Quote from: dcorbit on December 11, 2015, 03:05:53 AM
Run a batch file to set the environment for a given compiler.
You know that you can setup environment variables per personality and per project using the envvars plugin? I don't think such feature is needed because you can do so already.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: [url="https://www.codeblocks.org/docs/main_codeblocks_en.html"]https://www.codeblocks.org/docs/main_codeblocks_en.html[/url]
C::B FAQ: [url="https://wiki.codeblocks.org/index.php?title=FAQ"]https://wiki.codeblocks.org/index.php?title=FAQ[/url]

darmar

There are problems with parsing Gfortran v5.* compiler messages because in v5.* the format of some messages was a little bit changed. The patch attached solves this problem.

Another older problem is that -fopenmp option should be added to the compiler and to the linker when user selects "Enable the OpenMP extensions" compiler option. The patch solves this problem also.

MortenMacFly

Quote from: darmar on December 12, 2015, 04:12:34 PM
There are problems with parsing Gfortran v5.* compiler messages because in v5.* the format of some messages was a little bit changed. The patch attached solves this problem.

Another older problem is that -fopenmp option should be added to the compiler and to the linker when user selects "Enable the OpenMP extensions" compiler option. The patch solves this problem also.
I've applied this on trunk. Before I move it to the release branch: Is it backwards compatible? Meaning what happens to older GFortran compiler messages now?
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: [url="https://www.codeblocks.org/docs/main_codeblocks_en.html"]https://www.codeblocks.org/docs/main_codeblocks_en.html[/url]
C::B FAQ: [url="https://wiki.codeblocks.org/index.php?title=FAQ"]https://wiki.codeblocks.org/index.php?title=FAQ[/url]

darmar

Quote from: MortenMacFly on December 13, 2015, 07:07:10 AM
Is it backwards compatible?

Yes, GFortran 4.* messages are recognized as before.


killerbot

I am planning on preparing an RC2 today or tomorrow, or should we wait a little bit longer ?

Krice

I'm wondering why virtual folders can be created only outside sources and headers folders? Wouldn't it be more logical to create them inside the source structure to divide files into thematic groups.

MortenMacFly

Quote from: killerbot on December 13, 2015, 09:53:15 AM
I am planning on preparing an RC2 today or tomorrow, or should we wait a little bit longer ?
Nope, feel free to do. I would go gold already, but if you do a RC2 today it should be fine.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: [url="https://www.codeblocks.org/docs/main_codeblocks_en.html"]https://www.codeblocks.org/docs/main_codeblocks_en.html[/url]
C::B FAQ: [url="https://wiki.codeblocks.org/index.php?title=FAQ"]https://wiki.codeblocks.org/index.php?title=FAQ[/url]

killerbot

gold is also OK, is there any blocking bug ? (I could think of one, the editor tabs splitup up, seems to happen sometimes during project reload ?) ?

Pecan

Quote from: killerbot on December 14, 2015, 07:21:53 AM
gold is also OK, is there any blocking bug ? (I could think of one, the editor tabs splitup up, seems to happen sometimes during project reload ?) ?

You might want to ignore the editor tabs splitup bug until after 15.12.
Just disable the bug for now with something like this:
--- src/sdk/projectlayoutloader.cpp (revision 10603)
+++ src/sdk/projectlayoutloader.cpp (working copy)
@@ -236,12 +236,12 @@

     if (major >= 1)
     {
-        elem = root->FirstChildElement("EditorTabsLayout");
-        if (elem)
-        {
-            m_NotebookLayout = cbC2U(elem->Attribute("layout"));
-        }
-        // else ?!
+// FIXME (ph#): //(pecan 2015/10/29)causes split window when loading second project //(ICC 2015/10/29)
+//        elem = root->FirstChildElement("EditorTabsLayout");
+//        if (elem)
+//        {
+//            m_NotebookLayout = cbC2U(elem->Attribute("layout"));
+//        }         // else ?!
     }

     return true;


MortenMacFly

Quote from: Pecan on December 14, 2015, 04:46:16 PM
Just disable the bug for now with something like this:
I wasn't aware this bug still exists. What else do we loose with this "work-around"? Any meaningful functionality?

And btw: How can I reproduce this split bug?
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: [url="https://www.codeblocks.org/docs/main_codeblocks_en.html"]https://www.codeblocks.org/docs/main_codeblocks_en.html[/url]
C::B FAQ: [url="https://wiki.codeblocks.org/index.php?title=FAQ"]https://wiki.codeblocks.org/index.php?title=FAQ[/url]

Jenna

Quote from: MortenMacFly on December 14, 2015, 08:11:16 PM
I wasn't aware this bug still exists. What else do we loose with this "work-around"? Any meaningful functionality?
The whole layout restoring of single projects is lost.

Krice

Another problem with virtual folders is that you can move a file from the list into a virtual folder only if it's visible on screen. If the list of files is too long it doesn't scroll up when you try to move the file.

l_inc

Quote from: MortenMacFly on December 14, 2015, 08:11:16 PM
I wasn't aware this bug still exists.
Not sure if it's related, but I actually reported that the bugfix had been done improperly.

Jenna

Quote from: l_inc on December 14, 2015, 11:51:16 PM
Quote from: MortenMacFly on December 14, 2015, 08:11:16 PM
I wasn't aware this bug still exists.
Not sure if it's related, but I actually reported that the bugfix had been done improperly.
I just answered there, I do not see where we read values from unallocated memory.