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

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.

Offline stahta01

  • Lives here!
  • ****
  • Posts: 6898
    • 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)