The 16 September 2014 build (9916) is out.

[killerbot]

Get quick announcements through the RSS feed http://www.codeblocks.org/nightly/CodeBlock_RSS.xml

Before you use a nightly make sure you understand how it works.

A link to the unicode windows wxWidget dll for Code::Blocks : http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/Prerequisites/wxmsw28u_gcc_cb_wx2812_gcc481-TDM.7z

For those who might need this one (when no MingW installed on your system) : the mingw10m.dll : http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/Prerequisites/mingwm10_gcc481-TDM.7z

The 16 September 2014 build is out.
  - Windows :
   http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/2014/CB_20140916_rev9916_win32.7z
  - Linux :
   none

Resolved Fixed:

• merged scinitlla_3_5_0 branch into trunk, main new features:
  ** make use of MVC principle in scintilla
  ** timers are used for each type of periodic activity
  ** VHDL enhancement by danselmi
  ** lexer added for Windows registry files.
  ** a lot of fixes
  ** C::B: send wxEVT_SCI_CLIPBOARD_PASTE event to allow clients to change clipboard data
• added registry lexer
• CC: apply patch by Huki, this mainly fixes two things:
  1) Nested unnamed (struct or union) within unnamed: all the members should be invokable from the parent class or struct.
  2) Show tooltips for members of unnamed / enum within class invoked directly (also for nested cases).
  See details in the C::B forum post: http://forums.codeblocks.org/index.php/topic,18315.msg133712.html#msg133712
• CppCheck: Fix the text control in the config panel
• CC: skip the C++ style comment correctly if reading doxygen style document is enabled, thus partially fix the bug: https://sourceforge.net/p/codeblocks/tickets/41/, the synchronization issue about the Token and the document still exists yet.
• CppCheck: Add support for macros in the path of the cppcheck executable, clean up the code a bit
• CC: Apply patch by Huki to improved calltips support for macro and typedef. See detailed description in http://forums.codeblocks.org/index.php/topic,19278.msg133989.html#msg133989, add documents for Tokenizer::SplitArguments() function.
• CC: Apply patch by Huki, this improved parsing support for func ptr, also add some comments about how to parse the pattern "AAA BBB(...);"
  
  Both the four patterns of the function/variable will be recognized:
  void(*foo)(int a); // func ptr
  void *(*foo)(int a); // func ptr with ptr return type
  void foo(int a); // function decl
  AAA foo(5); // var initialized with ctor (only supported for local block)
  
  For the Pattern "AAA BBB(...);", we need to distinguish the token type by where the statement locates, if it locates in a local block, such as a function body, we recognize it as a variable named BBB with type AAA, otherwise, it is a function declaration. This is just a hack since our parser don't use semantic checking. Details in: http://forums.codeblocks.org/index.php/topic,19278.msg134068.html#msg134068.

Regressions/Confirmed/Annoying/Common bugs:

[Jenna]

As usual:
Debian packages (binaries and sources) for 32-bit and 64-bit systems can be found in my debian-repo.
Fedora packages (binaries and sources) for 32-bit and 64-bit systems (fc19, fc20, fc21 and rawhide), RedHat/CentOS 5 and 6 packages (also 32-bit and 64-bit) and RedHat/CentOS 7 packages (only 64-bit at the moment) can be found in my rpm-repo.

[eckard_klotz]

Hello Everybody.

How can folding be configured to folde only if the indicator symbol is used and not simply by clicking between the text-window and the line number column ? Or is it possible to place the folding collumn left from the line column or to place an inactive column between the text-window and the folding collumn?

The reason I ask is that nearly every time I try to place the cursor on the beginning of a line (using the mouse), the containing block will be folded even the line it self has no folding indicator. This means I have to open the block again and to search the line I want to edit again. The onnly posibility I know until now, is to deactivate folding completly.

Has somebody a tip for me?

Best regards,
                   Eckard.

[shurick]

Packages for openSUSE (binaries and sources) for 32-bit and 64-bit.

[damorin]

Hi,

just noticed the cursor is blinking erratically almost all the time. I tried to change the period, change it to a block but nohing seems to affect it.

Windows XP SP3.

[raynebc]

I'm seeing the same issue with the cursor, running Windows XP x64.  The July 6, 2014 nightly does not exhibit this behavior on the same computer.  If it helps track down the offending change, let me know and I'll test each of the nightly releases in between.

I'm finding that an old bug still occurs where CodeBlocks correctly reports the file size of a source file in my project, but reports the line count as 0 and when I double click on the file from the manager window, it opens the file as if it was empty:
http://forums.codeblocks.org/index.php/topic,18580.msg128907.html#msg128907
I copied the file to the root of my project and added that new copy to the project, but it also opens as if it was empty.  I copied a file that opens properly in CodeBlocks to that path (\src\alogg\src\) and it opens and displays normally.  It seems CodeBlocks has some kind of issue with this file in particular, which is available here:
https://editor-on-fire.googlecode.com/svn/trunk/src/alogg/src/alogg.c

[White-Tiger]

raynebc, well if that file is a problem, the uploaded one seems fine to me... so because of line ending conversation done by SVN and FTP, etc., can you maybe ZIP it or something?

@CB:
I've got one question myself.. is it possible to add scopes / more scope to the codecompletion?
IIRC it can handle normal scopes {}, but what about "global" variables declared static in one file? Currently I see every static variable or function in every file... this doesn't only make it hard for me to find variables for the current file, it's also confusing functions... I've got multiple files with functions with the same name (one file per dialog subpage), and when I try to open the declaration/implementation I end up being thrown to a different file... sometimes it doesn't even detect all functions in the current file.. (not sure if it's related)

So please let the parser respect the "static" keyword.. Since it does know about scopes, it shouldn't be too hard to handle it as one.

[scarphin]

I think the behavior of cursor blink is like it's scanning the whole blink period range with a certain increment, after that decrement the period range and then loop over again and again. At least on Windows.

[raynebc]

raynebc, well if that file is a problem, the uploaded one seems fine to me... so because of line ending conversation done by SVN and FTP, etc., can you maybe ZIP it or something?

Here's the zipped file:
http://www.mediafire.com/download/sdnbmgggd9m7duc/alogg.zip

[Aleksandr]

Hi,
found a couple of things related to doxygen that I think are incorrect.

Looking ahead to say, the project directory tree looks like this:

Code

project/
  bin/
    debug/
    release/
  build/
    doxygen/
  doc/

In the build/ directory is a project file project.cbp. In the doxygen/ directory is a file doxyfile. debug/ and release/ is the directory in which the executable files are placed. And directory doc/ where doxygen generates html.

Firstly, perform the menu item DoxyBlocks→Doxywizard...

When the project has just opened and when menu item performed in the tab DoxyBlocks displays the following output:

Code: "doxyblocks tab output"

Running doxywizard...
Process 16240 (C:\Program Files\doxygen\bin\doxywizard.exe C:\Users\Aleksandr\Code\C++\project\build\doxygen\doxyfile) launched.

And in the opened dialog one can see that the file doxyfile was successfully readed.

But after has been run one of the targets (debug or release) the output changed to the following:

Code: "doxyblocks tab output"

Running doxywizard...
Process 22804 (C:\Program Files\doxygen\bin\doxywizard.exe C:\Users\Aleksandr\Code\C++\project\bin\debug\doxygen\doxyfile) launched.

or

Code: "doxyblocks tab output"

Running doxywizard...
Process 17736 (C:\Program Files\doxygen\bin\doxywizard.exe C:\Users\Aleksandr\Code\C++\project\bin\release\doxygen\doxyfile) launched.

respectively. It is obvious that the file is not readed. But, perform the menu item DoxyBlocks→Extract documentation is still correct.

Secondly... well, it probably does not apply to the C::B, but to the plugin DoxyBlocks. I don't know.
So, as you can see the directory tree before, doxygen is configured to put everything in the directory doc/. Nevertheless, after extracting documentation path in a message about the location of the generated document is invalid:

Code: "doxyblocks tab output"

----------------------------------------------------------------------------------------------------
Extracting documentation for project.
DoxyBlocks is working, please wait a few moments...
Found existing doxyfile...
Success.
Your documents are in: C:\Users\Aleksandr\Code\C++\project\build\doxygen\

Done.

And perform the menu item DoxyBlocks→Run HTML fails:

Code: "doxyblocks tab output"

Index.html not found at C:\Users\Aleksandr\Code\C++\project\build\doxygen\html/index.html.

Thats it.

[cacb]

Hi, I am running the 9916 Nightly on two platforms
Win7: Downloaded pre-built Nightly 9916 from this forum thread
Kubuntu 14.04 64bit: Downloaded Jens Lody's tarball and built Nightly 9916 from source

I observe on Windows that the compiler options dialog has been redesigned, it seems to work (no detailed checking done).
However, on Kubuntu, the compiler options dialog is completely empty, no options shown.

See attachments. Is this a known problem?

[Alpha]

Does the folder ~/.codeblocks/share/codeblocks/compilers/ exist?  Does it contain anything?

[cacb]

Does the folder ~/.codeblocks/share/codeblocks/compilers/ exist?  Does it contain anything?

Yes, it exists. It contains options_gcc.xml  with lots of options inside.

[Jenna]

My build seems to work on my debian wheezy test-vm with gnome-shell.

[Alpha]

Yes, it exists. It contains options_gcc.xml  with lots of options inside.

Try moving that file elsewhere, then launch C::B.  If your options are back, could you please (compress and) post the .xml here?  Also, is it only GCC, or do all compilers not have options?

[White-Tiger]

Since this is about that (ugly) new options dlg, may I suggest you to fix its size?
This isn't usable^^


Also, it would be nice if it would remember its previous size^^
I have to resize it every time I use it... didn't had to with the old one...

[cacb]

Yes, it exists. It contains options_gcc.xml  with lots of options inside.

Try moving that file elsewhere, then launch C::B.  If your options are back, could you please (compress and) post the .xml here?  Also, is it only GCC, or do all compilers not have options?

Thank you....that solved the problem! I am only writing in C++ so I guess it is really g++ we are talking about. The other compilers show options after the fix (if I try the "Selected compiler" choice)

The offending XML (before the fix) is attached, zipped.

[Alpha]

The offending XML (before the fix) is attached, zipped.

Definitely the culprit. ...  May take some time to figure out what caused C::B to generate this file in a flawed state, though...

[ollydbg]

Since this is about that (ugly) new options dlg, may I suggest you to fix its size?
This isn't usable^^


Also, it would be nice if it would remember its previous size^^
I have to resize it every time I use it... didn't had to with the old one...

Yes, I see the same issue too. A bit annoying, since the default dialog size is too small. I would recommend you to write a ticket on SourceForge, thanks.

[stahta01]

Yes, I see the same issue too. A bit annoying, since the default dialog size is too small. I would recommend you to write a ticket on SourceForge, thanks.

Not always, I have had it be too wide to shown on my screen; but, it seems to be hard to figure out why it happens.

Tim S.

[scarphin]

I've been experiencing the weird error in the attachment. 'mingw-builds' is my default compiler which is also in the system path. I also have a tdm-4.8.1 installation which has its own entry in CB compiler settings. Steps to reproduce:

1- Load the 'CodeBlocks.cbp'
2- Change compiler to the tdm-4.8.1 for the whole project
3- Save project

It keeps popping up until I close CB and everything goes back to normal if I revert 'CodeBlocks.cbp' to its default. I do have the 'libiconv-2.dll' in tdm binary folder if that should help anything. I can't come up with any reason why the 'cc1plus.exe' is launched after saving the project?

Win7 SP1 x64
I'm using the official 9916 nightly

[ollydbg]

I've been experiencing the weird error in the attachment. 'mingw-builds' is my default compiler which is also in the system path. I also have a tdm-4.8.1 installation which has its own entry in CB compiler settings. Steps to reproduce:

1- Load the 'CodeBlocks.cbp'
2- Change compiler to the tdm-4.8.1 for the whole project
3- Save project

It keeps popping up until I close CB and everything goes back to normal if I revert 'CodeBlocks.cbp' to its default. I do have the 'libiconv-2.dll' in tdm binary folder if that should help anything. I can't come up with any reason why the 'cc1plus.exe' is launched after saving the project?

Win7 SP1 x64
I'm using the official 9916 nightly

when you save project，codecompletion will fire a reparse which call compiler to fetch proprocessor directs.

[scarphin]

when you save project，codecompletion will fire a reparse which call compiler to fetch proprocessor directs.

Now it makes sense. CC launches the designated compiler for the project but it cannot find the needed files to run as it is not in the system path (I just confirmed that the needed dll is not in my default compilers bin folder). Is there a way to overcome this like launching the designated compiler with its own path when CC calls it?

[danselmi]

This is a bug in CC plugin.

The compiler plugin is able to call the compiler correctly.

[scarphin]

Good to hear that as embedded compilers not in system path might result in the same error.

[danselmi]

Good to hear that as embedded compilers not in system path might result in the same error.

I have seen this problem with embedded compilers too.
Discussed (internally) here:
http://forums.codeblocks.org/index.php/topic,19377.msg132453.html#msg132453

[White-Tiger]

I had mentioned that CC problem within my post scriptum as well: http://forums.codeblocks.org/index.php/topic,19695.msg134492.html#msg134492
Though the problem is my 64bit GCC as my 32bit GCC is in my path. I thought the problem was that the 64bit GCC tries to use 32bit DLLs xD But if CC doesn't even set the path, it makes sense^^

P.S. that link of yours is really "internal" danselmi^^ No access for others

[ollydbg]

Yeah, it looks like CC don't set the PATH environment to run the gcc or g++ command.
The related code:

Code

void NativeParser::AddGCCCompilerDirs(const wxString& masterPath, const wxString& compilerCpp, ParserBase* parser)
{
    wxFileName fn(wxEmptyString, compilerCpp);
    wxString masterPathNoMacros(masterPath);
    Manager::Get()->GetMacrosManager()->ReplaceMacros(masterPathNoMacros);
    fn.SetPath(masterPathNoMacros);
    fn.AppendDir(_T("bin"));

    const wxArrayString& gccDirs = GetGCCCompilerDirs(fn.GetFullPath());
    TRACE(_T("NativeParser::AddGCCCompilerDirs(): Adding %lu cached gcc dirs to parser..."), static_cast<unsigned long>(gccDirs.GetCount()));
    for (size_t i=0; i<gccDirs.GetCount(); ++i)
    {
        parser->AddIncludeDir(gccDirs[i]);
        TRACE(_T("NativeParser::AddGCCCompilerDirs(): Adding cached compiler dir to parser: ") + gccDirs[i]);
    }
}

Run the command to fetch the GCC's include paths.

Code

// These dirs are the built-in search dirs of the compiler itself (GCC).
// Such as when you install your MinGW GCC in E:/code/MinGW/bin
// The buildin search dir may contains: E:/code/MinGW/include
const wxArrayString& NativeParser::GetGCCCompilerDirs(const wxString &cpp_compiler)
{
    // keep the gcc compiler path's once if found across C::B session
    // makes opening workspaces a *lot* faster by avoiding endless calls to the compiler
    static std::map<wxString, wxArrayString> dirs;
    if (!dirs[cpp_compiler].IsEmpty())
        return dirs[cpp_compiler];

    // wxExecute can be a long action and C::B might have been shutdown in the meantime...
    // This is here, to protect at re-entry:
    if (Manager::IsAppShuttingDown())
        return dirs[cpp_compiler];

    TRACE(_T("NativeParser::GetGCCCompilerDirs(): Enter"));

    // for starters , only do this for gnu compiler
    //CCLogger::Get()->DebugLog(_T("CompilerID ") + CompilerID);
    //
    //   Windows: mingw32-g++ -v -E -x c++ nul
    //   Linux  : g++ -v -E -x c++ /dev/null
    // do the trick only for c++, not needed then for C (since this is a subset of C++)


    // let's construct the command
    // use a null file handler
    // both works fine in Windows and Linux

    wxString Command(cpp_compiler + _T(" -v -E -x c++ /dev/null"));
    if (platform::windows)
      Command = cpp_compiler + _T(" -v -E -x c++ nul"); // on Windows, its different

    static bool flag = false;
    if (flag)
        return dirs[cpp_compiler];

    // action time  (everything shows up on the error stream
    wxArrayString Output, Errors;
    flag = true;
    if ( wxExecute(Command, Output, Errors, wxEXEC_SYNC | wxEXEC_NODISABLE) == -1 )
    {
        TRACE(_T("NativeParser::GetGCCCompilerDirs(): GetGCCCompilerDirs::wxExecute failed!"));
        flag = false;
        return dirs[cpp_compiler];
    }
    flag = false;

    // wxExecute can be a long action and C::B might have been shutdown in the meantime...
    // This is here, to protect a long run:
    if ( Manager::IsAppShuttingDown() )
        return dirs[cpp_compiler];

    // start from "#include <...>", and the path followed
    // let's hope this does not change too quickly, otherwise we need
    // to adjust our search code (for several versions ...)
    bool start = false;
    for (size_t idxCount = 0; idxCount < Errors.GetCount(); ++idxCount)
    {
        wxString path = Errors[idxCount].Trim(true).Trim(false);
        if (!start)
        {
            if (!path.StartsWith(_T("#include <...>")))
                continue;
            path = Errors[++idxCount].Trim(true).Trim(false);
            start = true;
        }

        wxFileName fname(path, wxEmptyString);
        fname.Normalize();
        fname.SetVolume(fname.GetVolume().MakeUpper());
        if (!fname.DirExists())
            break;

        dirs[cpp_compiler].Add(fname.GetPath());

        CCLogger::Get()->DebugLog(_T("NativeParser::GetGCCCompilerDirs(): Caching GCC default include dir: ") + fname.GetPath());
    }

    TRACE(_T("NativeParser::GetGCCCompilerDirs(): Leave"));
    return dirs[cpp_compiler];
}

[ollydbg]

This is a bug in CC plugin.

The compiler plugin is able to call the compiler correctly.

Think it more.
If I remember correctly, in compiler plugin, when it want to call the g++.exe. (suppose it is under D:/mingw32/bin/g++.exe), the compiler just add the path "D:/mingw32/bin" to the environment variable PATH as the first place search path. After finish compiling, it just remove the first search path from PATH variable.

Do we need to such things in CC? Should Compiler plugin supply an API to do this?

[White-Tiger]

I think a better way would be to set the path once so it's used everywhere^^

Just update the path and other settings when the target changes... Though this doesn't work out of the box with virtual targets because they could contain more then one compiler (from different real targets)

Generally the virtual target stuff need a rewrite Maybe switch on compile time to each and every real target (ignoring the first as it should already be set, so the first real target of a virtual target is internally selected, after compiling that, select to the other ones and finally revert back the the first)

[nasty_wolverine]

Somehow, all the nightlies archives i am downloading are corrupt. I am trying to open them with 7-zip, but throws the error "could not open as archive". Tried downloading back to 9854, still the same. other archives on my system behave fine.

can some one maybe post a CRC of a proper archive and i can check?

[raynebc]

The hashes for this nightly:
MD5:  7639E8E7726CF6C03FE214B95915BBEA
CRC32:  3146396098
SHA1:  5483CE117A0CD4A4BCF1D8E1001E5495897315BC

[nasty_wolverine]

Files to signature:  1.
--------------------
[001/001] D:\Development\CB_20140916_rev9916_win32.7z
   Size:   9,199,104
   CRC-32:   4502CDEE
   MD-5:   ce0b4ad1890d56405c038ccfa658a11d
-------------------- FILE SIGNATURE COMPLETE --------------------

This is what i got from this nightly using GUI File Signature Widget. I have tried downloading multiple times from multiple mirrors. Always says archive is corrupt.

[raynebc]

Best bet is to try another mirror on Sourceforge.  I just downloaded it from the TCPdiag mirror and it works fine.  Otherwise you may have to try something like another browser, because it seems your download is either being corrupted during transit, or at your computer (ie. malware).

[Jenna]

You can to try if downloading it from my server (https://apt.jenslody.de/downloads/cb_nightly_9916/) works.
md5 hashes:

Code

7639e8e7726cf6c03fe214b95915bbea  CB_20140916_rev9916_win32.7z
71e005f599ee9cd2b78b2fc7eb6ffa84  mingwm10_gcc481-TDM.7z
f8c3640e7b55df11d0e0aacb36450019  wxmsw28u_gcc_cb_wx2812_gcc481-TDM.7z

crc32 hashes:

Code

bb8a31c2	CB_20140916_rev9916_win32.7z
a7612ce4	mingwm10_gcc481-TDM.7z
ea91c474	wxmsw28u_gcc_cb_wx2812_gcc481-TDM.7z

sizes:

Code

9200027	CB_20140916_rev9916_win32.7z
5683	mingwm10_gcc481-TDM.7z
1565385	wxmsw28u_gcc_cb_wx2812_gcc481-TDM.7z

[nasty_wolverine]

You can to try if downloading it from my server (https://apt.jenslody.de/downloads/cb_nightly_9916/) works.
md5 hashes:

Code

7639e8e7726cf6c03fe214b95915bbea  CB_20140916_rev9916_win32.7z
71e005f599ee9cd2b78b2fc7eb6ffa84  mingwm10_gcc481-TDM.7z
f8c3640e7b55df11d0e0aacb36450019  wxmsw28u_gcc_cb_wx2812_gcc481-TDM.7z

crc32 hashes:

Code

bb8a31c2	CB_20140916_rev9916_win32.7z
a7612ce4	mingwm10_gcc481-TDM.7z
ea91c474	wxmsw28u_gcc_cb_wx2812_gcc481-TDM.7z

sizes:

Code

9200027	CB_20140916_rev9916_win32.7z
5683	mingwm10_gcc481-TDM.7z
1565385	wxmsw28u_gcc_cb_wx2812_gcc481-TDM.7z

Yes!!! thank you, works like a charm.

I doubt its malware or the browser, coz i have been downloading other things and they have been fine. Maybe some one can check the integrity of the sourceforge files, i doubt that is the issue. Not really sure what happened.

[Xaviou]

Hi

Maybe some one can check the integrity of the sourceforge files, i doubt that is the issue. Not really sure what happened.

I've juste re-downloaded the 7z archive, and the SHA1 checksum is correct :

Code

5483ce117a0cd4a4bcf1d8e1001e5495897315bc  CB_20140916_rev9916_win32.7z

Regards
Xav'

[Jenna]

I doubt its malware or the browser, coz i have been downloading other things and they have been fine. Maybe some one can check the integrity of the sourceforge files, i doubt that is the issue. Not really sure what happened.

I downloaded the files directly from sourceforge to my server (via console), so the archives should be okay.

[nasty_wolverine]

looks like its a sourceforge problem. cant download the latest nightly. get the same error. tried different browsers too.