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

Compiler plugin redesign for post v1.0?

(1/2) > >>

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.

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

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 & 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
(just for the selected target/project, do not process the dependencies)
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.

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?


--- 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" (,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.

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">

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)

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.


[0] Message Index

[#] Next page

Go to full version