DelftShell Build Logica.
Hieronder staat de build logica beschreven van DelftShell. Wees vrij om wijzigen etc aan te brengen zodat dit document kan worden opgenomen in referentie materiaal. Hieronder staat een voorstel voor een nieuw build proces en ook hier zijn suggesties om het simpeler of sneller te maken natuurlijk nodig.
Martijn
Voor het builden van DelftShell inclusief plugins wordt nu gebruikt gemaakt van een aantal shared libraries en post-build events. Dit document probeert zo helder mogelijk het proces van builden en creëren van een 'loader' te beschrijven.
delft-tools\lib(1)
delft-tools\apps\DelftShell\modules\DelftShell.Loader\bin\Debug
delft-tools\apps\DelftShell\modules\DelftShell.Loader\bin\plugins(5)
delft-tools\apps\DelftShell\lib(2)
delft-tools\apps\DelftShellPlugins
delft-tools\apps\DelftShellPlugins\NetCdf
delft-tools\apps\DelftShellPlugins\NetCdf\lib(3)
delft-tools\apps\DelftShellPlugins\NetCdf\modules\
delft-tools\apps\DelftShellPlugins\NetCdf\modules\NetCDF\bin\Debug(4)
De lib directories (1,2,3) zijn er voor om 3rd party dlls te herbergen. NB: waarom lib (2)?
Allereerst worden onafhankelijke dlls (Bijvoorbeeld GeoApi.dll) gebuild met eventueel PostSharp post-build actie. Deze dll worden gereferenced door ander projecten.
De meer interessante projecten zijn de plugins en de loader.
1 Build plugins
1.1 Build plugin
1.2 Run postbuild events voor deze plugin
1.2.1 Run PostSharpPostBuild.cmd (\\bin\PostSharpPostBuild.cmd)
1.2.1.1 TODO: specify what this .cmd does
1.2.2 Run plugin PostBuild.cmd (\\bin\PluginPostBuild.cmd)
1.2.2.1 Creëer directory voor plugin in de loader\bin\plugins
1.2.2.2 Copieer alle dlls uit bin directory van plugin(4) naar bin\plugin directory binnen de loader(5).
1.2.2.3 Copieer alle dll.config files uit bin directory van plugin naar bin\plugin directory binnen de loader.
1.2.2.4 Verwijder bepaalde dlls als ze bestaan.(de lijst van welke is lang en staat in de .cmd file).
1.2.3 Doe plugin specifieke logica. Bijvoorbeeld: plugins.SharpMapGis kopieert alle bestanden uit de root lib (2) naar de plugin dir (5) binnen de loader en kopieert daarna nog van alles.
2 Build loader
2.1 Build de loader
2.2 Run postbuild events van de loader
2.2.1 Verwijder Nhibernate.dlls als deze er zijn.
2.2.2 Verwijder NetTopologySuite.dlls als deze er zijn.
2.2.3 Copieer een paar dllls uit de hoofd lib dir naar de build directory.
Problemen huidige structuur:
1 Verschillende build acties voor verschillende plugins. Kopieeer acties voor specifieke plugin slecht gedocumenteerd.
2 PostSharpPostBuild doet veel (onnodige?) kopieeracties.
3 3 lib directories! (1 voor plugins 1 voor shared kan ik begrijpen) waarvan men moet bijhouden wat waar wordt gebruikt.
Voorstel nieuwe structuur:
KISS.
Doel maak het simpeler en reduceer het aantal kopieer acties.
Veranderingen:
1 Plugin kopieert zichzelf naar bin van de loader (zonder subdir) en kijkt of afhankelijke dlls ook moeten worden gekopieerd (if !Exists copy op de hele bin van de plugin). Een grote bak met alle dlls dus.En geen specificatie van file-names in postbuild event.
2 PostSharp kan misschien sneller (zonder kopieer acties)
3 Geen extra acties binnen build loader.
4 Verwijder overbodige lib directory (2)
1 Build plugin
1.1 Build plugin
1.2 Run postbuild voor plugin
1.2.1 Run PostSharpPostBuild
1.2.2 Kopieer inhoud van bin directory van plugin naar bin van de loader. Doe dit alleen voor non-existing files.
2 Build loader
2.1 Run Postbuild events van de loader