+ technical/build/LumieraDebianPackage.html +
+ + ++ enthält auch Beschreibung des Installation-Bundle +
+ + ++ die ist gut und auch nützlich dort; könnte aber auch übernommen werden in die Beschreibun des Buildsystems +
+ + ++ ....und jetzt wird's mal Zeit, das aufzuräumen, da ich nun sowiso schon so viel Aufwand in Clean-up gesteckt habe!!! +
+ + ++ wenn Files als Seiteneffekt erzeugt werden, kann es helfen, explizit ein Manifest-File als HIlfs-Target zu erzeugen +
+ + ++ ...und wir fügen das erzeugte Objekt per env.Append(BUILDERS=) hinzu. Genau wie in der Doku immer noch dargestellt +
+ + ++ Anmerkung: das war alles eine falsche Fährte +
+ + ++ Parsing icons/svg/track-unlocked.svg +
++ scons: rebuilding `target/gui/icons/24x24/track-unlocked.png' because: +
++ `data/icons/svg/track-unlocked.svg' changed +
++ `target/rsvg-convert' changed +
++ rendering Icon: data/icons/svg/track-unlocked.svg --> target/gui/icons/24x24/track-unlocked.png target/gui/icons/22x22/track-unlocked.png target/gui/icons/16x16/track-unlocked.png +
++ Parsing data/icons/svg/track-unlocked.svg +
+ + ++ in tool/SConscript (letzte Zeile) +
++ # Rendering the SVG Icons depends on rsvg-convert +
++ env.Depends(icons, rsvg) +
++ +
++ daß er nämlich wenig systematisch aufgebaut ist, und darauf angewiesen, daß alle Daten korrekt normalisiert sind, und die Aufrufe jeweils richtig erfolgen: +
++ ...um all die Komplexität von unserem SCons-Build auszuschalten; also praktisch das beispiel für einen Builder mit Emitter aus der Doku nachbauen +
+ + ++ from SCons.Environment import Environment +
++ from SCons.Builder import Builder +
++ from SCons.Script import Decider +
+
+
+
+
+
+
+
+ Decider('content-timestamp') +
+
+
+
+
+ env = Environment() +
++ bld = Builder(action='(echo -n "FOO `date -Isecond` :"; cat) < $SOURCE > $TARGET') +
++ env.Append(BUILDERS={'Foo': bld}) +
+
+
+
+
+
+
+
+ env.Foo('file.foo', 'file.input') +
++ env.Program('hello.c') +
+
+
+
+
+ +
++ sondern enthält genau einen Eintrag, nämlich die SOURCE +
+ + ++ Die Action ist hier ein Python-Objekt +
+ + ++ ...und hier wird self (=die Target-Node) als 4.Parameter mitgegeben, die Prüfung erfolgt auf dem child, also der Source-Node +
+ + ++ was korrekt wit, da auch explain() auf der Source-Node aufgerufen wird +
+ + ++ scons: rebuilding `target/gui/icons/24x24/track-unlocked.png' because the contents of the build action changed +
+ + +
+ Make the Action expose a stable, deterministic signature by providing an explicit string function (strfunction) and/or an explicit variable list (varlist) when creating the Action, and avoid putting non-deterministic values (timestamps, randoms, VM-specific paths) into that signature.
+
+ SCons decides whether to rebuild partly from the Action's signature (a string representing the action) and from node signatures. A Python Action built without an explicit strfunction can produce unstable or overly-broad signatures and cause unnecessary rebuilds.
+
strfunction that returns a deterministic string (or a short label).
+ varlist to include relevant environment variables in the signature.
+ + Example: +
+ ++ python +
+from SCons.Action import Action
+
+def my_build(target, source, env):
+ # do deterministic build steps
+ with open(str(target[0]), "wb") as out:
+ out.write(open(str(source[0]), "rb").read())
+ return None
+
+# deterministic signature string; keep it short and stable
+def my_strfunc(act, target, source, env):
+ return "my_build: %s -> %s" % (",".join([s.path for s in source]), ",".join([t.path for t in target]))
+
+# optionally include env variables that should affect rebuilds
+my_action = Action(my_build, my_strfunc, varlist=['MYFLAG', 'OTHER_VAR'])
+
+env.Command('out.bin', 'in.bin', my_action)strfunction (or cmdstr) so the action signature is explicit and stable.
+ varlist to include only environment variables that legitimately change build output.
+ --debug=explain to see which signature or node change triggered the rebuild.
+ + aber ist komplett falsch und irreführend +
+ + ++ Muß schon sagen, nach einiger Zeit Debugging bin ich schon wieder am Kotzen. Dieser Stil!!!! +
++ Man akzeptiert irgendwas und geht dann durch eine zigfach verschachtelte Kette von Adaptern, solange bis es irgendwann.... wenn ... dann ... eben doch irgendwie paßt +
+ + ++ die Builder-Funktion in Lumiera ruft ein externes Python-Modul auf +
+ + ++ copyMergeDirectory=<function copyMergeDirectory at 0x7f0eeb296ac0> +
+ + ++ copyMergeDirectory=<function copyMergeDirectory at 0x7f5e85912ac0> +
+ + ++ r-grep über das ganze SCons-Paket gemacht.... +
++ Die Klasse erbt von der 'ABC' - Basisklasse (Python-3-Konstrukt). Aber die Argumente von gc(...) sprechen eigentlich dafür, daß das zu SCons gehört +
+ + ++ Diese Mentalität der Leute macht mich wütend. +
++ Kann man mal sein Hirn einschalten, bevor man loshackt?? +
++ Wenn jemand eine eigene Implementierung liefert, dann hat er Gründe dafür und man kann erwarten, daß dann auch der Kontrakt erfüllt wird. Woher wollen die denn wissen, ob eine custom-Implementierung überhaupteine »Varlist« eingeschlossen haben möchte???!! Zumal die ABC (ActionBase) gar kein Attribut 'self.varilist' hat... das kommt erst im nächsten Layer dazu. +
+ + ++ es teht ja nur darum, re-Builds der Icons zu vermeiden +
+ + ++ ...die Standard-Implementierung dieser get_contents()-Methode vewendet ein Rendering der involvierten Code-Objekte, inklusive der Variablen. Hier würde der IconSvgRenderer auftauchen. Stattdessen setzen wir eine Prüfsumme auf den Python-Quellcode; das Executable rsvog-convert ist sowiso auch noch eine Dependency, und auch Änderungen daran würden erkannt. Und natürlich Änderungen am SVG-Quellcode. +
+ + ++ ...und das lassen wir SCons machen, das kann das ja sehr gut... +
+ + +