Patch #997 2006-04-14 15:07
mortenmacfly
Add support for the LCC compiler- Download
- 997-Add_support_for.patch (13.3 KB)
Index: plugins/compilergcc/compilerLCC.h
===================================================================
--- plugins/compilergcc/compilerLCC.h (revision 0)
+++ plugins/compilergcc/compilerLCC.h (revision 0)
@@ -0,0 +1,24 @@
+#ifdef __WXMSW__
+// this compiler is valid only in windows
+
+#ifndef COMPILER_LCC_H
+#define COMPILER_LCC_H
+
+#include <compiler.h>
+
+class CompilerLCC : public Compiler
+{
+ public:
+ CompilerLCC();
+ virtual ~CompilerLCC();
+ virtual void Reset();
+ virtual void LoadDefaultRegExArray();
+ virtual AutoDetectResult AutoDetectInstallationDir();
+ protected:
+ virtual Compiler* CreateCopy();
+ private:
+};
+
+#endif // COMPILER_LCC_H
+
+#endif // __WXMSW__
Property changes on: plugins\compilergcc\compilerLCC.h
___________________________________________________________________
Name: svn:eol-style
+ LF
Index: plugins/compilergcc/compilerLCC.cpp
===================================================================
--- plugins/compilergcc/compilerLCC.cpp (revision 0)
+++ plugins/compilergcc/compilerLCC.cpp (revision 0)
@@ -0,0 +1,240 @@
+#ifdef __WXMSW__
+// this compiler is valid only in windows
+
+/*
+* This file is part of Code::Blocks Studio, an open-source cross-platform IDE
+* Copyright (C) 2006 Yiannis An. Mandravellos
+*
+* This program is distributed under the terms of the GNU General Public License as published by
+* the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
+*/
+
+#include <sdk.h>
+#include "compilerLCC.h"
+#include <wx/intl.h>
+#include <wx/regex.h>
+#include <wx/config.h>
+#include <wx/fileconf.h>
+#include <wx/msgdlg.h>
+#include <wx/log.h>
+
+#include <wx/msw/registry.h>
+
+CompilerLCC::CompilerLCC()
+ : Compiler(_("LCC Compiler"), _T("lcc"))
+{
+ Reset();
+}
+
+CompilerLCC::~CompilerLCC()
+{
+ //dtor
+}
+
+Compiler * CompilerLCC::CreateCopy()
+{
+ return new CompilerLCC(*this);
+}
+
+void CompilerLCC::Reset()
+{
+ m_Programs.C = _T("lcc.exe");
+ m_Programs.CPP = _T("lcc.exe");
+ m_Programs.LD = _T("lcclnk.exe");
+ m_Programs.DBG = _T("cdb.exe");
+ m_Programs.LIB = _T("lcclib.exe");
+ m_Programs.WINDRES = _T("lrc.exe");
+ m_Programs.MAKE = _T("make.exe");
+
+ m_Switches.includeDirs = _T("-I");
+ m_Switches.libDirs = _T("-L");
+ m_Switches.linkLibs = _T("");
+ m_Switches.defines = _T("-D");
+ m_Switches.genericSwitch = _T("-");
+ m_Switches.objectExtension = _T("obj");
+
+ m_Switches.needDependencies = true;
+ m_Switches.forceCompilerUseQuotes = false;
+ m_Switches.forceLinkerUseQuotes = false;
+ m_Switches.logging = clogSimple; // clogFull;
+ m_Switches.libPrefix = _T("");
+ m_Switches.libExtension = _T("lib");
+ m_Switches.linkerNeedsLibPrefix = false;
+ m_Switches.linkerNeedsLibExtension = true;
+ m_Switches.buildMethod = cbmDirect;
+
+ m_Options.ClearOptions();
+
+ // General
+ wxString category = _("General");
+ m_Options.AddOption(_("Generate the debugging information."), _T("-g2"), category, _T(""),
+ true,
+ _T("-O"),
+ _("You have optimizations enabled. This is Not A Good Thing(tm) when producing debugging symbols..."));
+ m_Options.AddOption(_("Arrange for function stack tracing. If a trap occurs, the function stack will be displayed."), _T("-g3"), category, _T(""),
+ true,
+ _T("-O"),
+ _("You have optimizations enabled. This is Not A Good Thing(tm) when producing debugging symbols..."));
+ m_Options.AddOption(_("Arrange for function stack and line number tracing."), _T("-g4"), category, _T(""),
+ true,
+ _T("-O"),
+ _("You have optimizations enabled. This is Not A Good Thing(tm) when producing debugging symbols..."));
+ m_Options.AddOption(_("Arrange for function stack, line number, and return call stack corruption tracing."), _T("-g5"), category, _T(""),
+ true,
+ _T("-O"),
+ _("You have optimizations enabled. This is Not A Good Thing(tm) when producing debugging symbols..."));
+
+ m_Options.AddOption(_("Inject code into the generated program to measure execution time. Incompatible with debug level higher than 2!"), _T("-profile"), category);
+ m_Options.AddOption(_("All warnings will be active"), _T("-A"), category);
+ m_Options.AddOption(_("Check the given source for errors. No object file is generated."), _T("-check"), category);
+ m_Options.AddOption(_("No warnings will be emitted. Errors will be still printed."), _T("-nw"), category);
+ m_Options.AddOption(_("Warn when a local variable shadows a global one."), _T("-shadows"), category);
+ m_Options.AddOption(_("Warns about unused assignments and suppresses the dead code."), _T("-unused"), category);
+ m_Options.AddOption(_("Generate code to test for overflow for all additions, subtractions and multiplications."),
download for full patch...
History
Alright, I have completed the work on LCC so far. It works for me but with some restrictions where I see no workaround. Allthough I know that I repeat myself on several aspects I'd like to point out all issues and possible solutions for the sake of completeness.
1.) Issue: Different versions of LCC:
There are at least two versions of LCC that make sense to support under Win32:
This is lcc-win32 and lcc-win32, patches by The MathWorks (Matlab) company. The implementation of how I've done it considers only the compiler/linker switches that are compatible to both versions. I leave additional switches up to the user, he should know about them anyway (at least in the case of Matlab).
2.) Issue: Setup of libpath via registry
The "default" LCC compiler requires specific entries in the registry. These are the path to the include files and the path to the LCC library files. It is not enough to provide them via the "-I" or the "-L" switch. The installer will setup these entries the right way. If they are not set at least the linker will ask the user to inpout the libpath manually via stdin. This is not possible with C::B so the compilation simply stops at that point until the user hits "break". The Matlab variant has a "-libpath" switch to provide the LCC with the path.
Possible solution: I have had an idea on how to make this issue more bullet prove. I'd like to propose that on the main compiler configuration page there should be a label that can be individually set by the compiler plugin(s) to inform the user about specific / compatibility issues. The label should have a red font but may contain no text (in fact initially it should be empty). The compiler plugins could set the label via something like:
m_Switches.issueInfo = _T("Warning: The LCC compiler requires...");
3.) Issue: The resource compiler cannot handle path names
A command issued like:
lrc MyRes.rc /oC:\MyFolder\.obj\MyRes.res
or:
lrc MyRes.rc /o.obj\MyRes.res
will NOT work. The file MyRes.res will be put into the directory where MyRes.rc is. This is quite nasty because that means as soon as I have a resource file to be compiled I have to place the object files in the same directory where the source code is, otherwise the linker is provided the wrong path for the resource objects. This applies to all Matlab stuff because every DLL created for Matlab depends on at least one resource file.
Possible solution: Add the possibility to setup the path for resource files seperately from object files. It won't work to add a include path switch to the linker because the object files are provided via the relative path.
4.) Issue: The generic switch is different for the LCC tools
The resource compiler expects the "/" switch, all other tools are proposed to use via the "-" switch but (fortunately) can also handle the "/" switch. Anyway: This should really be thought of for the compiler re-design. Also, that is is theoretically possible that the switches are case sensitive, thus e.g. the compiler requires "-i" and the resource compiler "/I".
Alltogether I have to say that I don't understand why the creators of LCC implement such incompatibilities and different interfaces. Anyway: We have to cope with that and hope it's going to be changed in the future. I've sent them feature requests accordingly.
Compatibility update for Matlab LCC support.
This update will refine the settings of the LCC compiler to support the Matlab LCC version, too. The Matlab LCC compiler is a patched variant of LCC-Win32.
Unfortunately, the problems you listed do not allow us to add this to our sources, at least for now (we 'll see with the new compiler framework).
Thanks anyway.
Yes, I understand - and I would have wondered if it would have been applied. Anyway: I'm glad you read the notes which may give you the one or other hint how different compiler can be... Maybe some information can be considered in the new compiler framework...
Updated the patch to be compatible with current SVN head. In addition it will now compile under Linux without errors, too (allthough LCC is not supported there yet). Some minor improvements to be more Matlab/LCC-Win32 friendly.