Lazarus-IDE Komponente -> Project Parameter abfragen

[Mathias]

Ich würde vorschlagen, neue Prozeduren anzulegen, der Name ist auch ziemlich irreführend. Außerdem solltest du die "CompileReasons", das sind die drei Häckchen, übergeben.

Das mit den separaten Funktionen würde ich auch besser finden.
Dann müsste auch Project/InstantFPC angepasst werden, das ist eine Package, welche SetAlternativeCompile verwendet. Und ich wollte kompatibel bleiben.

Was ich mir vorstellen kann, das SetAlternativeCompile auch nur provisorisch eingebaut wurde, so das InstantFPC läuft.

Der Kommentar "// disable normal compile and call this instead" spricht auch für was anderes.

Ich habe dies mal mit Google übersetzt. Deaktivieren Sie das normale Kompilieren und rufen Sie stattdessen dieses aufBaer was dies aussagen sollte, kann ich nicht entziffern.
Einzig was ich weis, SetAlternativeCompile ist noch nicht sehr alt, bei einem älteren Lazarus 1.9. ist es noch nicht dabei.

Allerdings, richtige Setter wären das dann auch nicht, da ja zwei Variablen übergeben werden. K.A. wie man es richtig macht...

Dies stimmt, aber zuerst muss man mal wissen, wie man ausliest.
Evtl. kann man einfach Result := ExecuteBefore.Command im Getter machen.

Für die AVR-Package würde es erst mal reichen, wen ich schreiben kann, und dies gelingt mit meinem ersten Vorschlag.

@kupferstecher
Ich habe gerade gesehen, das du im englischen Forum aktiv bist.

[Mathias]

Erstell doch einen Patch und reiche ihn via bugtracler oder dem englischen Forum ein, da sind die Chancen wahrscheinlich am besten, da der Patch direkt in den Trunk geladen werden kann

Eine Patch konnte ich mit "diff" erstellen, siehe Anhang.
Da sieht man wieder die Genialität von Linux Tools für sowas sind schon dabei.

Vorschlag:
procedure SetExecuteBeforeCommand(const ACommand: string; ACompileReasons: TCompileReasons);
procedure SetExecuteAfterCommand(const ACommand: string; ACompileReasons: TCompileReasons);

Oder wäre es besser SetAlternativeCompile stehen lassen, wie es ist, und den obigen Vorschlag einzubauen. Was vielleicht noch besser ist, wen man Command und CompileReasons trennen würde ?
Oder noch besser mit einer property ?

[Mathias]

Ich bin ein wenig weiter gekommen.
In meiner Package, kann ich folgendes aufrufen.

Code: Alles auswählen

AProject.LazCompilerOptions.SetExecuteBeforeCommand('Vorher....');
AProject.LazCompilerOptions.SetExecuteAfterCommand('Nachher....');

Dazu habe ich folgende abstracte Funktionen hinzugefügt.

Code: Alles auswählen

type
  TLazCompilerOptions = class(TAbstractIDEOptions)
  .....
    procedure SetExecuteBeforeCommand(const ACommand: string); virtual; abstract;
    procedure SetExecuteAfterCommand(const ACommand: string); virtual; abstract;
    procedure SetExecuteBeforeCompileReasons(ACompileReasons: TCompileReasons); virtual; abstract;
    procedure SetExecuteAfterCompileReasons(ACompileReasons: TCompileReasons); virtual; abstract;
 

Und folgendes:

Code: Alles auswählen

procedure TBaseCompilerOptions.SetExecuteBeforeCommand(const ACommand: string);
begin
  ExecuteBefore.Command := ACommand;
end;
 
procedure TBaseCompilerOptions.SetExecuteAfterCommand(const ACommand: string);
begin
  ExecuteAfter.Command := ACommand;
end;

Dies würde funktionieren.

Aber mit Reasons scheitert es noch, da ich nicht weis wo ich es reinschreiben soll. Ich kann nichts mit Reasons finden.

Code: Alles auswählen

procedure TBaseCompilerOptions.SetExecuteBeforeCompileReasons(
  ACompileReasons: TCompileReasons);
begin
  ExecuteBefore.Parsers.Text := SubToolFPC; /// ????????????
  /// ????????????
end;
 
procedure TBaseCompilerOptions.SetExecuteAfterCompileReasons(
  ACompileReasons: TCompileReasons);
begin
  ExecuteAfter.Parsers.Text :=SubToolFPC; /// ????????????
end; 

Dafür kann ich in den Parser schreiben.

[kupferstecher]

Oder wäre es besser SetAlternativeCompile stehen lassen, wie es ist, und den obigen Vorschlag einzubauen. Was vielleicht noch besser ist, wen man Command und CompileReasons trennen würde ?
Oder noch besser mit einer property ?

So habe ich es gemeint (SetAlternativeCompile stehen lassen). Mit Properties ist es denke ich am besten.

Ich bin ein wenig weiter gekommen.

Super

Aber mit Reasons scheitert es noch, da ich nicht weis wo ich es reinschreiben soll. Ich kann nichts mit Reasons finden.

In project.pp habe ich folgendes gefunden:

Code: Alles auswählen

with TProjectCompilationToolOptions(ExecuteBefore) do begin
    DefaultCompileReasons:=crAll;
    CompileReasons:=DefaultCompileReasons;
  end;

Vielleicht funktioniert das folgende? Richtig verstehen tue ich die Abhängigkeiten hier aber nicht...

Code: Alles auswählen

procedure TProjectCompilerOptions.SetExecuteBeforeCompileReasons(ACompileReasons: TCompileReasons);
begin
  inherited SetExecuteBeforeCompileReasons(ACompileReasons);
  CompileReasons:= ACompileReasons;
end;
 

[Mathias]

Für Command gibt es in der Unit CompilerOptions. 2 Variante eine für Before und die andere für After, so wie erwartet.

CompileReasons befindet sich in der Unit Project. Aber von CompileReasons, gibt es leider nur eine Variante, anstelle das es ein Before und After geben würde.
Somit stehe ich schon wieder an.

Wen niemand eine Rat weis, werde ich mich erst mal mit CompilerOptions begnügen. aber es wäre mir schon lieber, wen auch CompileReasons funktionieren würde.

[Mathias]

Für ExecuteCommand hat es unterdessen einen property gegeben, welcher sich lesen und schreiben lässt.

[Mathias]

Erstell doch einen Patch und reiche ihn via bugtracler oder dem englischen Forum ein, da sind die Chancen wahrscheinlich am besten,

Im englischem Forum habe ich den Patch schon gepostet, aber es hat niemand reagiert.
Ist es besser, wen ich direkt in den BugTracker schreibe ?

[af0815]

Ja, aber schau zuerst im Trunk-SVN nach ob das nicht vielleicht doch ohne viel Rückmeldung übernommen wurde. Manche (logischen und sinnvollen) Sachen werden ohne viel Rückmeldung eingepflegt. Mir ist es schon passiert, das das geändert wurde, bevor ich den Bugreport schreiben konnte, bzw. die Rückmeldung kam, 'already fixed'

[Mathias]

Du meinst da wird von den Entwicklern heimlich im Forum gelesen und dann kommentarlos ergänzt ?
Ich werde am Abend die aktuelle Trunk angucken. Und wen nötig einen Report schreiben.

[Mathias]

Ich habe grade einen Bug-Report hochgeladen: https://bugs.freepascal.org/view.php?id=34283

[kupferstecher]

ComileReasons gehen:

Verwendung:

Code: Alles auswählen

uses LazIDEIntf, CompOptsIntf, ProjectIntf;
 
AProject.LazCompilerOptions.SetExecuteBeforeCompileReasons([crCompile]+[crBuild]);
AProject.LazCompilerOptions.SetExecuteAfterCompileReasons([crBuild]);

Anpassungen in der IDE:
1. /ide/project.pp [TProjectCompilerOptions]

Code: Alles auswählen

procedure TProjectCompilerOptions.SetExecuteBeforeCompileReasons(ACompileReasons: TCompileReasons); override;
begin
  if ExecuteBefore is TProjectCompilationToolOptions then begin
    with TProjectCompilationToolOptions(ExecuteBefore) do begin
        DefaultCompileReasons:= ACompileReasons;
        CompileReasons:=DefaultCompileReasons;
    end;
  end;
 
end;
 
procedure TProjectCompilerOptions.SetExecuteAfterCompileReasons(ACompileReasons: TCompileReasons); override;
begin
  if ExecuteAfter is TProjectCompilationToolOptions then begin
    with TProjectCompilationToolOptions(ExecuteAfter) do begin
        DefaultCompileReasons:= ACompileReasons;
        CompileReasons:=DefaultCompileReasons;
    end;
  end;
 
end;

2./components/ideintf/CompOptsIntf.pas [TLazCompilerOptions]

Code: Alles auswählen

procedure SetExecuteBeforeCompileReasons(ACompileReasons: TCompileReasons); virtual; abstract;
procedure SetExecuteAfterCompileReasons(ACompileReasons: TCompileReasons); virtual; abstract;

[Mathias]

Ich habe grade einen Bug-Report hochgeladen: https://bugs.freepascal.org/view.php?id=34283

Die vom Lazarus-Team waren echt fleissig, ich konnte nicht mal mein Znacht fertig essen, wurde es schon ins Release 59006 eingebaut.
Die Änderung wird sogar in der dem nächst erscheinenden RC1 einhalten sein.

ComileReasons gehen:

[Mathias]

Ich habe noch Fragen zu CompileReasons.

Wieso änderst du "DefaultCompileReasons" ?
Für was ist "if ExecuteBefore" ?

Bei mir funktioniert die vereinfachte Version.

Code: Alles auswählen

// unit ide/Project.pp
function TProjectCompilerOptions.GetExecuteBeforeCompileReasons: TCompileReasons;
begin
  Result := TProjectCompilationToolOptions(ExecuteBefore).CompileReasons;
end;
 
function TProjectCompilerOptions.GetExecuteAfterCompileReasons: TCompileReasons;
begin
  Result := TProjectCompilationToolOptions(ExecuteAfter).CompileReasons;
end;
 
procedure TProjectCompilerOptions.SetExecuteBeforeCompileReasons(ACompileReasons: TCompileReasons);
begin
  TProjectCompilationToolOptions(ExecuteBefore).CompileReasons := ACompileReasons;
end;
 
procedure TProjectCompilerOptions.SetExecuteAfterCompileReasons(ACompileReasons: TCompileReasons);
begin
  TProjectCompilationToolOptions(ExecuteAfter).CompileReasons := ACompileReasons;
end;

Auch das Abfrage funktioniert.

Code: Alles auswählen

  s := 'Before: ';
  if crCompile in LazProject.LazCompilerOptions.ExecuteBeforeCompileReasons then begin
    s += 'compile ';
  end;
  if crBuild in LazProject.LazCompilerOptions.ExecuteBeforeCompileReasons then begin
    s += 'build ';
  end;
  if crRun in LazProject.LazCompilerOptions.ExecuteBeforeCompileReasons then begin
    s += 'run ';
  end; 

Es ist noch interessant, die CompilerCommands muss man in der Unit CompilerOptions einfügen und die Reasons in Project.

[kupferstecher]

Für was ist "if ExecuteBefore [is TProjectCompilationToolOptions then]" ?

Es ist ja ein Typecast notwendig um an die Variable CompileReasons zu gelangen, d.h. es gibt keine Garantie (vom Compiler), dass ExecuteBefore tatsächlich vom abgeleiteten Typ TProjectCompilationToolOptions und nicht vom Basistyp TBaseCompilerOptions ist. Ist es von letzterem, dann gibt/gäbe es eine Zugriffsverletzung/Absturz. Vielleicht ist das vom Programm her auch immer TProjectCompilationToolOptions, aber sicher ist sicher.

Wieso änderst du "DefaultCompileReasons" ?

Hab das an anderer Stelle im Code gesehen und einfach kopiert, nachdems funktioniert hat, hab ich mich nicht mehr darum gekümmert. Für was das gut ist, keine Ahnung...
Ich würde es raus nehmen.

[Mathias]

Ich habe gerade den Patsch im Bug-Report veröffentlicht.
https://bugs.freepascal.org/view.php?id=34289

Es ist ja ein Typecast notwendig um an die Variable CompileReasons zu gelangen, d.h. es gibt keine Garantie (vom Compiler), dass ExecuteBefore tatsächlich vom abgeleiteten Typ TProjectCompilationToolOptions und nicht vom Basistyp TBaseCompilerOptions ist. Ist es von letzterem, dann gibt/gäbe es eine Zugriffsverletzung/Absturz. Vielleicht ist das vom Programm her auch immer TProjectCompilationToolOptions, aber si

Ich habe die If-Abfrage in den Patch eingebaut.