Author Topic: The 16 September 2014 build (9916) is out.  (Read 34402 times)

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5234
The 16 September 2014 build (9916) is out.
« on: September 16, 2014, 09:40:30 pm »
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:



    Offline jens

    • Administrator
    • Lives here!
    • *****
    • Posts: 7253
      • Jens' unofficial debian-repository for the Code::Blocks - IDE
    Re: The 16 September 2014 build (9916) is out.
    « Reply #1 on: September 17, 2014, 07:47:34 am »
    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.

    Offline eckard_klotz

    • Almost regular
    • **
    • Posts: 159
    Re: The 16 September 2014 build (9916) is out.
    « Reply #2 on: September 17, 2014, 10:06:37 am »
    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.

    Offline shurick

    • Multiple posting newcomer
    • *
    • Posts: 35
    Re: The 16 September 2014 build (9916) is out.
    « Reply #3 on: September 17, 2014, 01:18:24 pm »
    Packages for openSUSE (binaries and sources) for 32-bit and 64-bit.
    Packages for openSUSE http://codeblocks.esy.es  (binaries and sources) for 32-bit and 64-bit.

    Offline damorin

    • Multiple posting newcomer
    • *
    • Posts: 44
    Re: The 16 September 2014 build (9916) is out.
    « Reply #4 on: September 17, 2014, 02:02:24 pm »
    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.
    One problem at a time and we will get there.

    Offline raynebc

    • Almost regular
    • **
    • Posts: 216
    Re: The 16 September 2014 build (9916) is out.
    « Reply #5 on: September 18, 2014, 12:18:00 am »
    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

    Offline White-Tiger

    • Multiple posting newcomer
    • *
    • Posts: 83
    Re: The 16 September 2014 build (9916) is out.
    « Reply #6 on: September 18, 2014, 12:21:51 pm »
    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.
    Windoze 8.1 x86_64 16GiB RAM, wxWidgets-2.8x (latest,trunk), MinGW-builds (latest, posix-threads)
    Code::Blocks (x86 , latest , selection length patch , build option fixes/additions , toggle comments)

    Offline scarphin

    • Lives here!
    • ****
    • Posts: 644
    Re: The 16 September 2014 build (9916) is out.
    « Reply #7 on: September 18, 2014, 02:24:13 pm »
    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.

    Offline raynebc

    • Almost regular
    • **
    • Posts: 216
    Re: The 16 September 2014 build (9916) is out.
    « Reply #8 on: September 18, 2014, 06:46:40 pm »
    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

    Offline eMan.Lived

    • Multiple posting newcomer
    • *
    • Posts: 21
    Re: The 16 September 2014 build (9916) is out.
    « Reply #9 on: September 20, 2014, 06:38:49 pm »
    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: [Select]
    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 DoxyBlocksDoxywizard...

    When the project has just opened and when menu item performed in the tab DoxyBlocks displays the following output:
    Code: Text
    1. Running doxywizard...
    2. 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: Text
    1. Running doxywizard...
    2. Process 22804 (C:\Program Files\doxygen\bin\doxywizard.exe C:\Users\Aleksandr\Code\C++\project\bin\debug\doxygen\doxyfile) launched.
    or
    Code: Text
    1. Running doxywizard...
    2. 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 DoxyBlocksExtract 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: Text
    1. ----------------------------------------------------------------------------------------------------
    2. Extracting documentation for project.
    3. DoxyBlocks is working, please wait a few moments...
    4. Found existing doxyfile...
    5. Success.
    6. Your documents are in: C:\Users\Aleksandr\Code\C++\project\build\doxygen\
    7.  
    8. Done.

    And perform the menu item DoxyBlocksRun HTML fails:
    Code: Text
    1. Index.html not found at C:\Users\Aleksandr\Code\C++\project\build\doxygen\html/index.html.
    Thats it.
    [AAAA|+}

    Offline cacb

    • Regular
    • ***
    • Posts: 425
    Re: The 16 September 2014 build (9916) is out.
    « Reply #10 on: September 24, 2014, 10:03:17 pm »
    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?

    Offline Alpha

    • Developer
    • Lives here!
    • *****
    • Posts: 1513
    Re: The 16 September 2014 build (9916) is out.
    « Reply #11 on: September 24, 2014, 10:15:11 pm »
    Does the folder ~/.codeblocks/share/codeblocks/compilers/ exist?  Does it contain anything?

    Offline cacb

    • Regular
    • ***
    • Posts: 425
    Re: The 16 September 2014 build (9916) is out.
    « Reply #12 on: September 24, 2014, 10:16:57 pm »
    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.


    Offline jens

    • Administrator
    • Lives here!
    • *****
    • Posts: 7253
      • Jens' unofficial debian-repository for the Code::Blocks - IDE
    Re: The 16 September 2014 build (9916) is out.
    « Reply #13 on: September 24, 2014, 10:23:05 pm »
    My build seems to work on my debian wheezy test-vm with gnome-shell.

    Offline Alpha

    • Developer
    • Lives here!
    • *****
    • Posts: 1513
    Re: The 16 September 2014 build (9916) is out.
    « Reply #14 on: September 24, 2014, 10:36:25 pm »
    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?

    Offline White-Tiger

    • Multiple posting newcomer
    • *
    • Posts: 83
    Re: The 16 September 2014 build (9916) is out.
    « Reply #15 on: September 24, 2014, 10:48:24 pm »
    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...
    Windoze 8.1 x86_64 16GiB RAM, wxWidgets-2.8x (latest,trunk), MinGW-builds (latest, posix-threads)
    Code::Blocks (x86 , latest , selection length patch , build option fixes/additions , toggle comments)

    Offline cacb

    • Regular
    • ***
    • Posts: 425
    Re: The 16 September 2014 build (9916) is out.
    « Reply #16 on: September 24, 2014, 10:52:39 pm »
    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.

    Offline Alpha

    • Developer
    • Lives here!
    • *****
    • Posts: 1513
    Re: The 16 September 2014 build (9916) is out.
    « Reply #17 on: September 25, 2014, 02:07:24 am »
    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...

    Offline ollydbg

    • Developer
    • Lives here!
    • *****
    • Posts: 5234
    • OpenCV and Robotics
      • Chinese OpenCV forum moderator
    Re: The 16 September 2014 build (9916) is out.
    « Reply #18 on: September 25, 2014, 06:41:15 am »
    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.
    If some piece of memory should be reused, turn them to variables (or const variables).
    If some piece of operations should be reused, turn them to functions.
    If they happened together, then turn them to classes.

    Online stahta01

    • Lives here!
    • ****
    • Posts: 6896
      • My Best Post
    Re: The 16 September 2014 build (9916) is out.
    « Reply #19 on: September 25, 2014, 06:44:48 am »
    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.
    C Programmer working to learn more about C++ and Git.
    On Windows 7 64 bit and Windows 10 32 bit.
    On Debian Stretch, compiling CB Trunk against wxWidgets 3.0.
    --
    When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

    Offline scarphin

    • Lives here!
    • ****
    • Posts: 644
    Re: The 16 September 2014 build (9916) is out.
    « Reply #20 on: October 06, 2014, 01:35:19 am »
    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

    Offline ollydbg

    • Developer
    • Lives here!
    • *****
    • Posts: 5234
    • OpenCV and Robotics
      • Chinese OpenCV forum moderator
    Re: The 16 September 2014 build (9916) is out.
    « Reply #21 on: October 06, 2014, 03:07:39 am »
    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.
    If some piece of memory should be reused, turn them to variables (or const variables).
    If some piece of operations should be reused, turn them to functions.
    If they happened together, then turn them to classes.

    Offline scarphin

    • Lives here!
    • ****
    • Posts: 644
    Re: The 16 September 2014 build (9916) is out.
    « Reply #22 on: October 06, 2014, 08:26:12 am »
    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?

    Offline danselmi

    • Developer
    • Almost regular
    • *****
    • Posts: 202
    Re: The 16 September 2014 build (9916) is out.
    « Reply #23 on: October 06, 2014, 08:27:41 am »
    This is a bug in CC plugin.

    The compiler plugin is able to call the compiler correctly.

    Offline scarphin

    • Lives here!
    • ****
    • Posts: 644
    Re: The 16 September 2014 build (9916) is out.
    « Reply #24 on: October 06, 2014, 09:32:32 am »
    Good to hear that as embedded compilers not in system path might result in the same error.

    Offline danselmi

    • Developer
    • Almost regular
    • *****
    • Posts: 202
    Re: The 16 September 2014 build (9916) is out.
    « Reply #25 on: October 06, 2014, 10:30:30 am »
    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


    Offline White-Tiger

    • Multiple posting newcomer
    • *
    • Posts: 83
    Re: The 16 September 2014 build (9916) is out.
    « Reply #26 on: October 06, 2014, 11:47:33 am »
    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 :P
    Windoze 8.1 x86_64 16GiB RAM, wxWidgets-2.8x (latest,trunk), MinGW-builds (latest, posix-threads)
    Code::Blocks (x86 , latest , selection length patch , build option fixes/additions , toggle comments)

    Offline ollydbg

    • Developer
    • Lives here!
    • *****
    • Posts: 5234
    • OpenCV and Robotics
      • Chinese OpenCV forum moderator
    Re: The 16 September 2014 build (9916) is out.
    « Reply #27 on: October 06, 2014, 04:56:34 pm »
    Yeah, it looks like CC don't set the PATH environment to run the gcc or g++ command.
    The related code:
    Code: [Select]
    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: [Select]
    // 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];
    }
    If some piece of memory should be reused, turn them to variables (or const variables).
    If some piece of operations should be reused, turn them to functions.
    If they happened together, then turn them to classes.

    Offline ollydbg

    • Developer
    • Lives here!
    • *****
    • Posts: 5234
    • OpenCV and Robotics
      • Chinese OpenCV forum moderator
    Re: The 16 September 2014 build (9916) is out.
    « Reply #28 on: October 08, 2014, 04:24:44 pm »
    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?
    If some piece of memory should be reused, turn them to variables (or const variables).
    If some piece of operations should be reused, turn them to functions.
    If they happened together, then turn them to classes.

    Offline White-Tiger

    • Multiple posting newcomer
    • *
    • Posts: 83
    Re: The 16 September 2014 build (9916) is out.
    « Reply #29 on: October 08, 2014, 08:10:25 pm »
    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 :P 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)
    Windoze 8.1 x86_64 16GiB RAM, wxWidgets-2.8x (latest,trunk), MinGW-builds (latest, posix-threads)
    Code::Blocks (x86 , latest , selection length patch , build option fixes/additions , toggle comments)

    Offline nasty_wolverine

    • Multiple posting newcomer
    • *
    • Posts: 12
    Re: The 16 September 2014 build (9916) is out.
    « Reply #30 on: October 10, 2014, 11:32:46 pm »
    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?

    Offline raynebc

    • Almost regular
    • **
    • Posts: 216
    Re: The 16 September 2014 build (9916) is out.
    « Reply #31 on: October 11, 2014, 12:16:24 am »
    The hashes for this nightly:
    MD5:  7639E8E7726CF6C03FE214B95915BBEA
    CRC32:  3146396098
    SHA1:  5483CE117A0CD4A4BCF1D8E1001E5495897315BC

    Offline nasty_wolverine

    • Multiple posting newcomer
    • *
    • Posts: 12
    Re: The 16 September 2014 build (9916) is out.
    « Reply #32 on: October 11, 2014, 01:26:44 am »
    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. :(

    Offline raynebc

    • Almost regular
    • **
    • Posts: 216
    Re: The 16 September 2014 build (9916) is out.
    « Reply #33 on: October 11, 2014, 01:47:25 am »
    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).

    Offline jens

    • Administrator
    • Lives here!
    • *****
    • Posts: 7253
      • Jens' unofficial debian-repository for the Code::Blocks - IDE
    Re: The 16 September 2014 build (9916) is out.
    « Reply #34 on: October 11, 2014, 01:48:59 am »
    You can to try if downloading it from my server (https://apt.jenslody.de/downloads/cb_nightly_9916/) works.
    md5 hashes:
    Code: [Select]
    7639e8e7726cf6c03fe214b95915bbea  CB_20140916_rev9916_win32.7z
    71e005f599ee9cd2b78b2fc7eb6ffa84  mingwm10_gcc481-TDM.7z
    f8c3640e7b55df11d0e0aacb36450019  wxmsw28u_gcc_cb_wx2812_gcc481-TDM.7z

    crc32 hashes:
    Code: [Select]
    bb8a31c2 CB_20140916_rev9916_win32.7z
    a7612ce4 mingwm10_gcc481-TDM.7z
    ea91c474 wxmsw28u_gcc_cb_wx2812_gcc481-TDM.7z

    sizes:
    Code: [Select]
    9200027 CB_20140916_rev9916_win32.7z
    5683 mingwm10_gcc481-TDM.7z
    1565385 wxmsw28u_gcc_cb_wx2812_gcc481-TDM.7z

    Offline nasty_wolverine

    • Multiple posting newcomer
    • *
    • Posts: 12
    Re: The 16 September 2014 build (9916) is out.
    « Reply #35 on: October 11, 2014, 11:14:14 am »
    You can to try if downloading it from my server (https://apt.jenslody.de/downloads/cb_nightly_9916/) works.
    md5 hashes:
    Code: [Select]
    7639e8e7726cf6c03fe214b95915bbea  CB_20140916_rev9916_win32.7z
    71e005f599ee9cd2b78b2fc7eb6ffa84  mingwm10_gcc481-TDM.7z
    f8c3640e7b55df11d0e0aacb36450019  wxmsw28u_gcc_cb_wx2812_gcc481-TDM.7z

    crc32 hashes:
    Code: [Select]
    bb8a31c2 CB_20140916_rev9916_win32.7z
    a7612ce4 mingwm10_gcc481-TDM.7z
    ea91c474 wxmsw28u_gcc_cb_wx2812_gcc481-TDM.7z

    sizes:
    Code: [Select]
    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.

    Offline Xaviou

    • Regular
    • ***
    • Posts: 314
      • X@v's wxStuff
    Re: The 16 September 2014 build (9916) is out.
    « Reply #36 on: October 11, 2014, 01:57:14 pm »
    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: [Select]
    5483ce117a0cd4a4bcf1d8e1001e5495897315bc  CB_20140916_rev9916_win32.7z
    Regards
    Xav'
    The french wxWidgets site : http://www.wxdev.fr
    My wxWidgets's stuff : https://wxstuff.xaviou.fr/

    Offline jens

    • Administrator
    • Lives here!
    • *****
    • Posts: 7253
      • Jens' unofficial debian-repository for the Code::Blocks - IDE
    Re: The 16 September 2014 build (9916) is out.
    « Reply #37 on: October 11, 2014, 02:26:02 pm »
    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.

    Offline nasty_wolverine

    • Multiple posting newcomer
    • *
    • Posts: 12
    Re: The 16 September 2014 build (9916) is out.
    « Reply #38 on: October 12, 2014, 02:28:09 am »
    looks like its a sourceforge problem. cant download the latest nightly. get the same error. tried different browsers too.