Author Topic: custom defined Compiler sets  (Read 11616 times)

Offline tiwag

  • Developer
  • Lives here!
  • *****
  • Posts: 1196
  • sailing away ...
    • tiwag.cb
custom defined Compiler sets
« on: November 21, 2005, 02:05:14 pm »
since the new xml-file based configuration has been introduced, i can't use any of my custom defined compiler set's, because all standard entries are restored after the next restart, if they have been deleted in this particular compiler set.

but this disturbs a proper operation:

my example:
i need a compiler-set which basically consists of a regular expressions -set for compiler- and linker- errors and warnings and a dummy compiler executable. my project file consists of a target which type is specified as "Commands only" and invokes the build process via a batch-file, where all my files and options for compiling and linking are defined - only the output is captured by C::B and the compiler & linker messages are regexed and interpreted in the build-log.

this is what i've been using for that whith the older registry-based configuration
Code
Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Code::Blocks\Code::Blocks v1.0\compiler_gcc\compiler_sets\256]
"_name"="IAR H8 make script"
"_parent"=dword:00000001
"compiler_options"=""
"linker_options"=""
"include_dirs"=""
"res_include_dirs"=""
"library_dirs"=""
"libraries"=""
"commands_before"=""
"commands_after"=""
"master_path"="D:\\TOOLS\\"
"extra_paths"="D:\\TOOLS;"
"c_compiler"="iar_dum.bat"
"cpp_compiler"=""
"linker"=""
"lib_linker"=""
"res_compiler"=""
"make"=""
"debugger"=""

[HKEY_CURRENT_USER\Software\Code::Blocks\Code::Blocks v1.0\compiler_gcc\compiler_sets\256\macros]
"Compile single file to object file"=""
"Generate dependencies for file"=""
"Compile Win32 resource file"=""
"Link object files to executable"=""
"Link object files to console executable"=""
"Link object files to dynamic library"=""
"Link object files to static library"=""

[HKEY_CURRENT_USER\Software\Code::Blocks\Code::Blocks v1.0\compiler_gcc\compiler_sets\256\regex]

[HKEY_CURRENT_USER\Software\Code::Blocks\Code::Blocks v1.0\compiler_gcc\compiler_sets\256\regex\001]
"description"="Compiler warning"
"type"=dword:00000001
"regex"="\"..\\\\([^\"]+)\",([0-9]+).*(Warning.*)"
"msg1"=dword:00000003
"msg2"=dword:00000000
"msg3"=dword:00000000
"filename"=dword:00000001
"line"=dword:00000002

[HKEY_CURRENT_USER\Software\Code::Blocks\Code::Blocks v1.0\compiler_gcc\compiler_sets\256\regex\002]
"description"="Compiler error"
"type"=dword:00000002
"regex"="\"..\\\\([^\"]+)\",([0-9]+).*(Error.*)"
"msg1"=dword:00000003
"msg2"=dword:00000000
"msg3"=dword:00000000
"filename"=dword:00000001
"line"=dword:00000002

[HKEY_CURRENT_USER\Software\Code::Blocks\Code::Blocks v1.0\compiler_gcc\compiler_sets\256\regex\003]
"description"="Linker warning"
"type"=dword:00000001
"regex"="(Warning\\[[0-9]+\\]:.*)"
"msg1"=dword:00000001
"msg2"=dword:00000000
"msg3"=dword:00000000
"filename"=dword:00000000
"line"=dword:00000000

[HKEY_CURRENT_USER\Software\Code::Blocks\Code::Blocks v1.0\compiler_gcc\compiler_sets\256\regex\004]
"description"="Linker error"
"type"=dword:00000002
"regex"="(Error\\[[0-9]+\\]:.*)"
"msg1"=dword:00000001
"msg2"=dword:00000000
"msg3"=dword:00000000
"filename"=dword:00000000
"line"=dword:00000000

[HKEY_CURRENT_USER\Software\Code::Blocks\Code::Blocks v1.0\compiler_gcc\compiler_sets\256\switches]
"includes"=""
"libs"=""
"link"=""
"define"=""
"generic"=""
"objectext"=""
"deps"=dword:00000000
"forceCompilerQuotes"=dword:00000000
"forceLinkerQuotes"=dword:00000000
"logging"=dword:00000000
"buildMethod"=dword:00000001
"libPrefix"=""
"libExtension"=""
"linkerNeedsLibPrefix"=dword:00000000
"linkerNeedsLibExtension"=dword:00000000


you see alot of "empty" entries ("") and only four regular expressions defined.

when i try to define this with the actual C::B's CVS-version, it works after definition, but when i close and restart C::B , all the "empty" entries i.e entries which are not defined compared versus the standard gcc-compiler configuration are automagically added and then the regular expressions don't work any longer with my custom compiler set !

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: custom defined Compiler sets
« Reply #1 on: November 21, 2005, 02:59:22 pm »
Not sure if I understand the problem correctly, but this sounds like the ConfigManager functions are called with an explicit default value provided.

The T Read(wxString name) functions in ConfigManager return wxEmptyString (or zero/false, whichever is suitable for T) if it can't find a key, it does not load anything from defaults. The respective bool Read(wxString name, T* type) functions return false if a key is not found, the T* argument is not modified.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline kisoft

  • Almost regular
  • **
  • Posts: 194
Re: custom defined Compiler sets
« Reply #2 on: November 21, 2005, 03:03:03 pm »
since the new xml-file based configuration has been introduced, i can't use any of my custom defined compiler set's, because all standard entries are restored after the next restart, if they have been deleted in this particular compiler set.
...
I have this problem too, I submit bug report on SF now. On Friday CVS this problem is absent, all worked normally.
OS: WinXPSP3
wxWidgets: 2.8.12
CodeBlocks: Master github cbMakefileGen plugin:
https://github.com/kisoft/cbmakefilegen

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: custom defined Compiler sets
« Reply #3 on: November 21, 2005, 03:07:26 pm »
On Friday CVS this problem is absent, all worked normally.
If that is the case, it should be easy to locate with Diff :)
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline tiwag

  • Developer
  • Lives here!
  • *****
  • Posts: 1196
  • sailing away ...
    • tiwag.cb
Re: custom defined Compiler sets
« Reply #4 on: November 21, 2005, 03:24:59 pm »
Not sure if I understand the problem correctly ...
the problem is, that you can only CHANGE entries but can't delete them - on the next restart the "missing" == deleted entry is substituted by the default value.

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: custom defined Compiler sets
« Reply #5 on: November 21, 2005, 03:39:56 pm »
Quote from: void Compiler::LoadSettings(const wxString& baseKey)
    m_MasterPath = cfg->Read(tmp + _T("/master_path"), m_MasterPath);
    m_ExtraPaths = GetArrayFromString(cfg->Read(tmp + _T("/extra_paths"), _T("")), _T(";"));
    m_Programs.C = cfg->Read(tmp + _T("/c_compiler"), m_Programs.C);
    m_Programs.CPP = cfg->Read(tmp + _T("/cpp_compiler"), m_Programs.CPP);
    [...]

That's probably it. Read is given explicit default values, so if it can't find a value, the default is used.

I'd wait until Yiannis had had a word on it though, because that is probably intentional for some good reason.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline kisoft

  • Almost regular
  • **
  • Posts: 194
Re: custom defined Compiler sets
« Reply #6 on: November 21, 2005, 04:52:44 pm »
Quote from: void Compiler::LoadSettings(const wxString& baseKey)
    m_MasterPath = cfg->Read(tmp + _T("/master_path"), m_MasterPath);
    m_ExtraPaths = GetArrayFromString(cfg->Read(tmp + _T("/extra_paths"), _T("")), _T(";"));
    m_Programs.C = cfg->Read(tmp + _T("/c_compiler"), m_Programs.C);
    m_Programs.CPP = cfg->Read(tmp + _T("/cpp_compiler"), m_Programs.CPP);
    [...]

I found a strange thing:
Code
    ConfigManager* cfg = Manager::Get()->GetConfigManager(_T("compiler"));

    wxString tmp;
    tmp.Printf(_T("%s/set%3.3d"), baseKey.c_str(), (int)m_ID);
    if (!cfg->Exists(tmp + _T("/name")))
        return;
searched for: "/sets/set256/name" and found it.
And:
Code
        group.Printf(_T("%s/regex/re%3.3d"), tmp.c_str(), index++);
        if (!cfg->Exists(group))
            break;
group not exists. Here search for: "/sets/set256/regex/re001" group.
Analogically for all compilers. :o

"Interesting" a next:

The set: "/sets/setXXX" read normally, for ex. "/sets/setXXX/master_path" is OK.
And the set: "/sets/setXXX/..." - is wrongly, for ex. "/sets/setXXX/macros/...", "/sets/setXXX/switches/..."

I look configmanager.cpp too, but while I can't debug CB.  :(
OS: WinXPSP3
wxWidgets: 2.8.12
CodeBlocks: Master github cbMakefileGen plugin:
https://github.com/kisoft/cbmakefilegen

Offline kisoft

  • Almost regular
  • **
  • Posts: 194
Re: custom defined Compiler sets
« Reply #7 on: November 21, 2005, 06:12:07 pm »
I found this:

Into sdk/configmanager.h
Code
    /* -----------------------------------------------------------------------------------------------------
    *  Set and unset keys, or test for existence. Note that these functions cannot be used to remove paths
    *  or test existence of paths (it may be used to implicitely create paths, though).
Code
    */
    bool Exists(const wxString& name);
    void Set(const wxString& name);
    void UnSet(const wxString& name);

hmm, test on existence of paths.
I patch compiler.cpp, method LoadSettings:

Code
        group.Printf(_T("%s/regex/re%3.3d"), tmp.c_str(), index++);
        if (!cfg->Exists(group))
            break;
        else if (!cleared)
        {
            cleared = true;
            m_RegExes.Clear();
        }
I change to:
Code
        group.Printf(_T("%s/regex/re%3.3d"), tmp.c_str(), index++);
        if (!cfg->Exists(group+_T("/description")))
            break;
        else if (!cleared)
        {
            cleared = true;
            m_RegExes.Clear();
        }
After it regex loaded.

But it's wrong way, I think, method Exists, used anywhere.
OS: WinXPSP3
wxWidgets: 2.8.12
CodeBlocks: Master github cbMakefileGen plugin:
https://github.com/kisoft/cbmakefilegen

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: custom defined Compiler sets
« Reply #8 on: November 23, 2005, 03:18:23 pm »
Yes, Exists() is used incorrectly here. It will always return false because it is given a pathname, but it looks for keys.

The config manager has a function EnumerateSubPaths() which returns all direct subpaths in a wxArrayString. This is a lot more convenient and less error-prone than iterating through numbers and checking for existence. It will also work reliably if your subpaths are numbered in a non-continguous manner.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline tiwag

  • Developer
  • Lives here!
  • *****
  • Posts: 1196
  • sailing away ...
    • tiwag.cb
Re: custom defined Compiler sets
« Reply #9 on: November 25, 2005, 02:29:14 pm »
...I'd wait until Yiannis had had a word on it though, because that is probably intentional for some good reason.

Any ideas ? what should be the intended behaviour ?
it is not possible to use custom compiler set's whenever the default gcc-defaults are restored after a restart of C::B !

Offline kisoft

  • Almost regular
  • **
  • Posts: 194
Re: custom defined Compiler sets
« Reply #10 on: December 12, 2005, 04:33:53 pm »
...I'd wait until Yiannis had had a word on it though, because that is probably intentional for some good reason.

Any ideas ? what should be the intended behaviour ?
it is not possible to use custom compiler set's whenever the default gcc-defaults are restored after a restart of C::B !

To tiwag:
Thanks for fix. Trouble is gone. Rev 1490.  8)
Really the Exist method need change on a correct method. I have no time for search it. :(

Good luck!
OS: WinXPSP3
wxWidgets: 2.8.12
CodeBlocks: Master github cbMakefileGen plugin:
https://github.com/kisoft/cbmakefilegen