What I have not managed yet are the Reasons parameters.
Looking at TProjectCompilerOptions.Create in ide/project.pp shows that the ExecuteBefore/after properties of TBaseCompilerOptions are created as type TProjectCompilationToolOptions, which contains a CompileReasons property.
I tried declaring a properties with get/set methods in TLazCompilerOptions:
protected
function GetExecuteBeforeReasons: TCompileReasons; virtual; abstract;
function GetExecuteAfterReasons: TCompileReasons; virtual; abstract;
procedure SetExecuteBeforeReasons(Areasons: TCompileReasons); virtual; abstract;
procedure SetExecuteAfterReasons(Areasons: TCompileReasons); virtual; abstract;
...
public
property ExecuteBeforeReasons: TCompileReasons read GetExecuteBeforeReasons write SetExecuteBeforeReasons;
property ExecuteAfterReasons: TCompileReasons read GetExecuteAfterReasons write SetExecuteAfterReasons;
With the following overrides in TProjectCompilerOptions:
function GetExecuteBeforeReasons: TCompileReasons; override;
function GetExecuteAfterReasons: TCompileReasons; override;
...
function TProjectCompilerOptions.GetExecuteBeforeReasons: TCompileReasons;
begin
Result := TProjectCompilationToolOptions(ExecuteBefore).CompileReasons;
end;
function TProjectCompilerOptions.GetExecuteAfterReasons: TCompileReasons;
begin
Result := TProjectCompilationToolOptions(ExecuteAfter).CompileReasons;
end;
This gives an abstract error when calling as follows:
AProject.LazCompilerOptions.ExecuteAfterReasons := [crRun];
I'm not sure why this doesn't work like the ExecuteAfterCommand changes. An alternative may be to move the definitions of TCompilationToolOptions and TProjectCompilationToolOptions to projintf.p, move fExecuteBefore and property ExecuteBefore etc up the hierarchy to TLasCompilerOptions and implement the get/set functionality in TLazCompilerOptions. Not sure if this is a good way of refactoring the classes.