Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development

Compiler plugin redesign for post v1.0?

(1/2) > >>

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:

--- Quote from: Game_Ender on August 04, 2005, 03:15:13 pm ---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?

--- End quote ---

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.

Navigation

[0] Message Index

[#] Next page