Compiler plugin redesign for post v1.0?

[zieQ]

During my investigations to add dependencies handling into the compiler plugin, I found out that the code is big, confusing and thus error prone. I think it's now time to rework the compiler plugin, maybe for version >1.0. I may tackle with that as soon as I'll go back from vacations.

Here are my thought about it. Feel free to post your thoughts too

Name: compilerplug / depcompilerplug (for dependency-enabled compiler plugin)

To basic files for the plugin himself:
- compilerengine: implementation of the compile/build/clean/dist/distclean * stuff.
- compilerinterface: all the GUI/menu/events stuff to call the appropriate build stuff.

compilerengine
--------------
Responsible for dependency calculations, not much code for that. May be in the sdk to avoid circular dependency in the dependencies editor dialog.
one basic (protected) primitive: Batch(BuildTargets, BatchCommand);  that applies a build command to a list of targets
(the parent project of each target is now part of the ProjectBuildTarget API)
one basic enum BatchCommand: could be compile, clean, dist, distclean, run?. Rebuild is just a successive call of clean then compile

All Compile, CompileAll, BatchClean, BatchBuild, Dist (etc.) methods are writen from the basic Batch primitive, even if there's only one
target/project to process. That will greatly simplify the implementation and make the build engine clearer.

Internally, there would be a Target list to process and for the current processed target, a queue of compiler-specific commands to perform.
Remove all the AskForProject/CheckProject/ActivateProject stuff since parent project now appear in the buildtarget. Just batch command for a list of targets, even in the XXXAll functions.

Those commands are issued by the DirectCommand or (a new) MakefileCommand classes, with may derive from a general BuildCommand and provide the basic commands needed during Batch


compilerinterface
-----------------
responsible for creating menus, toolbars, and reacting to events on those, to call the appropriate build commands

Default compile, clean, recompile items performs the selected project/target build, with dependencies handling

Compile menu
------------
Compile
Clean
Recompile
Run
Compile & Run
(applies to the selected target/project, and deal with dependencies)
----------
Compile All
Clean All
Recompile All
(all targets/projects, with correct dependency order)
----------
No dependencies -> Compile
                   Clean
                   Recompile
(just for the selected target/project, do not process the dependencies)
----------
Abort
----------
Errors stuff
Target Selection
----------
Makefile stuff
----------
Compiler options stuff


In the toolbar, something to select the current project and current target (or All targets)
and the existing toolbar.

[Game_Ender]

Code blocks already handles dependencies doesn't it?  I know it makes a dependencies file.  Are you talking about moving the functionality to the compiler pluggin?

[zieQ]

Code blocks already handles dependencies doesn't it?  I know it makes a dependencies file.  Are you talking about moving the functionality to the compiler pluggin?

Well, not really! C::B actually handles external file dependencies: if a file is modified, the whole target should be recompiled. My post here is about target dependencies: when a file of a target A is modified, the target B which depend on A is recompiled after A is recompiled. See my previous post about "dependency handling" (http://forums.codeblocks.org/index.php/topic,543.0.html), I have already discussed about that  :wink: . It's not incompatible with the external file dependency feature of C::B which is already handled by the compiler plugin.

[rickg22]

zieQ, you're welcome to start the "project".  You might also want to use XML for the compiler options, this way a tree can contain:

a) The options for the project.
b) The targets for the project.
    b.a.) The options for the targets.

And these could be compiler-independent, like...

<option for="compilername" name="blahblah">
...
</option>

And having these in loose-type variables (nodes) would save us a LOT of headaches. I'm still trying to UNDERSTAND how the compiler options are set (see the latest bug that i reported on SF regarding the Cancel button)

[AkiraDev]

Why not take this one step further and allow multiple language support?
Someone already successfully adapted C::B to compile Fortran77, after all.
Multiple hard-coded compilers always seemed harder to manage, if you ask me.

[rickg22]

One reason: I don't know! :lol:

Anyway the problem is this:

The compiler module is *not*  only about the compiler plugin... it's part of the SDK, too! And there are A LOT of classes that are intermingled like some kind of structured spaguetti but the structure is hard to decypher / reverse engineer (even with the source code ).

Now if Yiannis did the favor of explaining how the thingy works, I'd be very grateful.

[zieQ]

I was talking mainly about the compiler plugin compilation engine, that is, the code that compile the different project source files.

But I've forgotten to talk about the compiler configuration and options. Inspired from what Rick said, I think it would be great to have a xml configuration file for each compiler instead of some specific lines of code in the compiler plugin for each compiler, so that it would be easier to support another compiler by writing a new xml file. Or maybe a sub-plugin for each new compiler. Don't know what is the best to do.

In this configuration file:
- some hints to detect the compiler installation path (name of the registry key, path variable...)
- name of the executables of the compiler/linker/debugger/resource compiler
- description of the switches options for the compiler/linker (with a set of equivalent options for all compilers ?). We must allow mutually exclusive options.
- maybe the file extensions recognized by the compilers?

Rick, the compilation engine is quite confusing for now, it have lost some days trying to understand how it works. I think I have understood but it's not easy to explain how it works. The easiest thing to do is to redesign it I think  :lol: Don't worry, I will work on that . I have not tried to understand the option management during compilation yet, so I can't help you Rick!