Technische handleiding Simake. SIMONA rapport nummer

Transcriptie

1 Technische handleiding Simake SIMONA rapport nummer

2 Technische handleiding Simake Versie: 1.7, Juli 2013 Beheer en onderhoud: zie Copyright: Rijkswaterstaat

3 Log-sheet Log-sheet versie datum auteur Wijzigingen sinds de laatste versie LV c72292: Eerste versie LV c72292: aanvullingen opties EV c84610: toevoeging aanmaken dynamic link libraries MB C85478: Compileren matlab-applicaties MB C86922: ifort Linux compiler warnings kunnen worden gelogd in een apart bestand MB C85478: Beschrijving voor config.txt toegevoegd voor het compileren van matlab applicaties ES M3708: correctie in spelling optie stop_on_error; -create_dsw en create_dsp zijn obsolete WK 3802: Add -exclude-gino option

4

5 Inhoud Inhoud 1 Inleiding Achtergrond Terminologie Indeling van deze handleiding Gebruik van het make-systeem Inleiding Overzicht van opties Compileren van alle subsystemen Compileren en installeren van één subsysteem met afhankelijke subsystemen Compileren en installeren van één subsysteem zonder afhankelijke subsystemen Aanmaken van Fortran projectbestanden Compileren of installeren van verschillende typen subsubsystemen Aanmaken van het SIMETF-bestand Aanmaken van referentiearrays Installeren van documentatie Technische beschrijving van het make-systeem Opzet van het make-systeem simake.pl Tijdens runtime laden van modules Subsubsystemen Routines.pm Modules.pm Archives Etc Include Sds, Mm, Systemlib, Pre, Intpol Waqpre, Waqpro Matlab Reftab Simetf Doc Compileren van broncode Inleiding Makefile.gen Config.txt Settings.inc Instellingen Inleiding Debug - release - of range -modus Belangrijke compilervlaggen...21

6 Inhoud 6 Referenties...24

7 Inleiding 1 Inleiding 1.1 Achtergrond Het stromingssimulatiepakket SIMONA is oorspronkelijk ontwikkeld voor Unix-platformen. Voor het genereren van executables uit broncode werden tools gebruikt zoals make en sed die op MS Windows computers niet (goed) beschikbaar zijn. In de Kalminaprogrammatuur is het gebruik van Makefile s verder uitgewerkt en is een compleet make-systeem gemaakt voor het compileren van executables, converteren van hulpbestanden, en op de goede plek neerzetten van hulpbestanden en documentatie, zie [1]. Doordat dit systeem gebruik maakte van externe Unix/Linux-specifieke programma s kon dit alleen op Unix/Linux-platformen worden gebruikt. Op het Windows-platform werd voor het compileren gebruik gemaakt van de MS Visual Studio omgeving en bijbehorende project-files. Hiermee kunnen executables gemaakt worden, maar voor de installatie van overige bestanden is meer nodig dan waarin Visual Studio kan voorzien. In change c72292 van het SIMONA B&O-contract is een nieuw make-systeem gemaakt dat ook bruikbaar is op het Windowsplatform. In eerste instantie is daarbij onderzocht of het mogelijk was een op Makefiles gebaseerd systeem te gebruiken. De bedoeling hiervan was om Makefiles te maken waarmee SIMONAprogramma s op zowel Linux als op Windows gecompileerd konden worden. Een tweede doel was om ook alle hulpbestanden en documentatie op de juiste plaatst te installeren. De aanpak via universeel bruikbare Makefiles bleek dermate omslachtig, dat besloten is een andere strategie te volgen: de mogelijkheden van make zijn herschreven in Perl, dat zoveel mogelijk platform-onafhankelijk werkt. Daar waar het niet mogelijk is om functionaliteit op een platform-onafhankelijke manier uit te voeren, worden Perl-modules gebruikt. Voor elk ondersteund platform is een module geschreven. Alle modules bieden dezelfde functionaliteit, maar voeren de taken op een platform-afhankelijke manier uit. Dit rapport beschrijft hoe het nieuw ontwikkelde make-systeem simake gebruikt kan worden. Daarna beschrijft dit rapport hoe simake is opgezet en hoe het systeem uitgebreid kan worden voor andere platforms, andere compilers of met andere soorten functionaliteit. 1.2 Terminologie In dit rapport wordt gesproken over subsystemen, waarmee bibliotheken of programma s aangeduid worden, zie [1]. In vorige versies van het make-systeem werd de naam modules gebruikt. In FORTRAN-90 hebben modules echter een bijzondere betekenis

8 Inleiding gekregen. Om verwarring te voorkomen is daarom gekozen voor deze naamgeving. Een subsysteem bestaat weer uit verschillende onderdelen: programmacode, include-bestanden, documentatie, enzovoorts. Deze onderdelen worden in dit rapport subsubsystemen genoemd. In het make-systeem en in dit rapport wordt de term ui_name gebruikt om het platform en de architectuur van het systeem aan te duiden. De volgende namen zijn gebruikelijk: win32, voor Microsoft Windows 2000, NT en XP win64, voor Microsoft Windows7 winwmpi voor Microsoft Windows 2000, NT en XP, met gebruik van de commerciële MPI-implementatie WMPI II. linux, voor linux-systemen linux64, voor linux64-systemen hp9000s700, voor HP-UX-systemen met een PA-RISC architectuur; dit systeem wordt overigens niet meer ondersteund. Het bovenste niveau van de SIMONA-installatie wordt in dit rapport en in de broncode aangeduid als SIMONADIR. Dit is de directory waar ook de src en makeutil -directories aanwezig zijn. Zie [1] voor een overzicht van de in SIMONA gebruikte directory-structuur. 1.3 Indeling van deze handleiding In het tweede hoofdstuk wordt een beknopt overzicht gegeven van hoe het make-systeem in de praktijk gebruikt kan worden. Het derde hoofdstuk beschrijft hoe het make-systeem ontworpen is.

9 2 Gebruik van het make-systeem 2.1 Inleiding De opzet van simake is om te doen wat de gebruiker verwacht. De gebruiker zal één van de volgende handelingen uit willen voeren: compileren van alle subsystemen, bijvoorbeeld voor het maken van een release compileren van één subsysteem met alle afhankelijke subsystemen, als het niet nodig is alles te compileren; compileren van één subsysteem, bijvoorbeeld wanneer slechts één routine gewijzigd is; het compileren van een subsubsysteem, wat in het bijzonder nuttig is voor aanmaken van hulpbestanden; of het aanmaken van projectbestanden en een workspace om één of meerdere SIMONA-programma s in een debugger te kunnen starten op het Windows-platform. Afhankelijk van de plaats waar simake gestart wordt en afhankelijk van de gebruikersopties voert simake één van deze taken uit. 2.2 Overzicht van opties Simake.pl heeft een aantal opties. De volgende opties worden ondersteund: -only: in combinatie met één of meerdere subsystemen: controleert geen subsystemen waar de opgegeven subsystemen van afhankelijk zijn, bedoeld om in geval van kleine wijzigingen het compileren te versnellen. -create_dsp: creëert voor alle of de opgegeven subsystemen projectbestanden die gelezen kunnen worden door Compaq Visual Studio. Is obsolete: gebruik make_projects.pl -create_dsw: in combinatie met create_dsp ; creëert een workspace met daarin verwijzigingen naar de tegelijkertijd aangemaakte projectbestanden; met Compaq Visual Studio kunnen hiermee de programma s gecompileerd worden. Is obsolete: gebruik make_solution.pl -make_waqcta: compileer het waqcta subsysteem. Staat standaard aan onder Linux en uit voor Windows. -make_coecta: compileer het coecta subsysteem. Staat standaard aan onder Linux en uit voor Windows.

10 Gebruik van het make-systeem -exclude_gino: niet compileren van gino bibliotheek en subsysteem afhankelijk van gino. -stop_on_error: alleen bij het compileren van meerdere subsystemen; als meerdere subsystemen gecompileerd worden, dan zal het make-systeem niet stoppen bij fouten. Als deze optie opgegeven wordt, dan zal het systeem wel stoppen zodra een fout gevonden wordt. -logfile <bestandsnaam>: de naam van het bestand waarnaar alle schermuitvoer geschreven wordt. Zonder deze optie wordt schermuitvoer naar het scherm geschreven. -verbose <niveau>: stuurt de hoeveelheid debug-uitvoer. Het niveau ligt tussen 1 en 5; met 1 worden alleen kritische fouten gemeld, met 5 wordt allerlei informatie weergegeven die nuttig zou kunnen zijn voor de ontwikkelaar. -copy_matlab: de matlab-bestanden worden gekopieerd naar SIMONADIR/matlab. Wordt de vlag niet gebruikt, dan zal simake proberen de matlab-applicaties te compileren. -warnings all: genereert een warning bestand in de root directory van simona. Dit bestand bevat de warnings die door de Linux ifort compiler worden gegeven. Wordt deze optie i.s.m. de vlag logfile gebruikt, dan wordt er per simonaapplicatie een apart warning-bestand gegenereerd. De hier genoemde opties kunnen handig zijn in sommige situaties. Deze situaties worden in de volgende secties beschreven. 2.3 Compileren van alle subsystemen Een complete installatie van alle simona progamma s, hulpbestanden en documentatie kan uitgevoerd worden door in de SIMONADIR directory het commando simake.pl uit te voeren. simake heeft dus ook de functionaliteit van makeall uit het vorige make-systeem. Omdat het doorgaans de bedoeling is dat zoveel mogelijk subsystemen gecompileerd en geïnstalleerd worden, slaat het make-systeem in dit geval stukgelopen compilaties over. Voor dat subsysteem wordt dan geen executable aangemaakt. Het stoppen bij een fout kan echter geforceerd worden door de vlag op te geven. -stop_on_error

11 Gebruik van het make-systeem 2.4 Compileren en installeren van één subsysteem met afhankelijke subsystemen Het compileren van alle subsystemen kan tijdrovend zijn. De gebruiker kan geïnteresseerd zijn in het compileren van slechts één programma, om bijvoorbeeld een storing aan dit programma te verhelpen. In dit geval kan dit programma en alle subsystemen waarvan dit programma afhankelijk is, gecompileerd en geïnstalleerd worden door vanuit de bovenste directory het commando simake.pl <subsysteem> te geven. Door expliciet één of meer subsysteem op te geven worden alleen de benodigde deelsystemen gecompileerd en geïnstalleerd, zodat tijd bespaard wordt. Om bijvoorbeeld de programma s getser en obs2sds te compileren, wordt het commando gegeven. simake.pl getser obs2sds Ook wanneer een complete installatie reeds verricht is, heeft dit commando nut: alleen de benodigde subsystemen worden dan gecontroleerd op wijzigingen, wat het compileren bekort. 2.5 Compileren en installeren van één subsysteem zonder afhankelijke subsystemen Bij het opsporen en verhelpen van een storing is het mogelijk dat al een complete installatie verricht is, en er een wijziging aan één subsysteem heeft plaatsgevonden. Het kan in dat geval wenselijk zijn om niet ook nog alle afhankelijke deelsystemen te controleren op wijzigingen, maar alleen routines in dat subsysteem. In dit geval wordt het doorzoeken van alle deelsystemen voorkomen door niet in de SIMONADIR-directory te staan, maar door naar de directory van het subsysteem te gaan. Door nu in deze subdirectory het commando simake.pl te geven, wordt alleen dit subsysteem gecontroleerd op wijzigingen, en alleen gewijzigde bestanden worden opnieuw gecompileerd. 2.6 Aanmaken van Fortran projectbestanden Op het windows-platform is het gebruikelijk om fouten in een programma op te sporen in een Integrated Developer s Environment. De projectbestanden en het sln-bestand worden gemaakt met behulp van make_projects.pl en make_solution.pl.

12 Gebruik van het make-systeem 2.7 Compileren of installeren van verschillende typen subsubsystemen Alhoewel de term compileren doet vermoeden dat het makesysteem fortran- of c-bestanden kan compileren, kan het makesysteem meer dan dat. SIMONA bestaat, zoals eerder vermeld, uit programma s en bibliotheken, maar ook uit hulpbestanden en uit documentatie. Ook deze hulpbestanden en documentatie kunnen door het make-systeem bewerkt en geïnstalleerd worden op de correcte plaats. De verschillende soorten bestanden die door het make-systeem geïnstalleerd kunnen worden zijn: het bestand SIMETF met foutmeldingen in binaire vorm; referentie-arrays met daarin een beschrijving van invoerbestanden in binaire vorm; gebruikersdocumentatie, systeemdocumentatie en technische documentatie. Deze bestanden zijn altijd subsubsystemen van andere subsystemen. Hieronder wordt beschreven hoe zij aangemaakt en geïnstalleerd kunnen worden Aanmaken van het SIMETF-bestand Het bestand SIMETF wordt aangemaakt door het subsysteem simetf te compileren. In dit subsysteem is geen broncode aanwezig. In het subsysteem simetf is echter een subsubsysteem simetf; aanwezig. De module die voor het compileren van dit subsubsysteem verantwoordelijk is, roept sierwr aan om met het bestand messages.inp het bestand SIMETF aan te maken. Vervolgens wordt dit bestand verplaatst naar de etc/<ui_name> -directory Aanmaken van referentiearrays Referentietabellen zijn ascii-bestanden die de invoer van een programma beschrijven. Door het programma sireft worden deze bestanden gecompileerd tot binaire bestanden, waardoor de beschrijving van de invoer sneller gelezen kan worden door het programma. Deze binaire bestanden worden referentie-arrays genoemd. Als een programma een eigen invoerbeschrijving heeft, is de referentietabel opgeslagen in het subsubsysteem reftab van dat programma. Als het make-systeem de executable van het programma maakt, wordt ook de bijbehorende referentiearray op de juiste plaats geïnstalleerd. De referentiearray kan ook aangemaakt worden in de reftab - directory van het desbetreffende subsysteem het commando

13 Gebruik van het make-systeem simake.pl te geven. De verantwoordelijke subsubsysteem-module roept dan sireft aan om de referentietabel te compileren tot een referentiearray, die vervolgens op de juiste plaats neergezet wordt Installeren van documentatie Documentatie wordt in de broncode meegeleverd als subsubsysteem van een programma of bibliotheek. Bij het installeren wordt de documentatie ook automatisch geïnstalleerd in de doc -directory van SIMONADIR. Alhoewel documentatie niet gecompileerd of anderszins bewerkt hoeft te worden, beschouwt het make-systeem het aanmaken van een documentatie-directorystructuur en het kopiëren van de documentatie naar de juiste directory ook als compileren. Door in de doc - subdirectory van een programma of een bibliotheek het commando simake.pl te geven, wordt de documentatie geïnstalleerd op de juiste locatie.

14 Technische beschrijving van het make-systeem 3 Technische beschrijving van het make-systeem 3.1 Opzet van het make-systeem Het make-systeem is opgezet om zo generiek mogelijk te kunnen werken. Hiervoor is het make-systeem opgedeeld als volgt: Er is een verzameling kern-programma s die generieke taken uitvoeren. Er is een groep modules die bepaalde taken specifiek voor het type subsubsysteem uitvoeren; deze modules zijn afgeleide klassen van de klasse Subsubsystem. Elke klasse heeft een lidfunctie make die voor dat type subsubsysteem de juiste taak uitvoert. Er is een groep modules die platform-specifieke, compilerspecifieke of architectuur-specifieke taken uitvoeren. Deze modules zijn afgeleide klassen van de klasse Simaker. Platformafhankelijke taken worden door de Subsubsystemmodules uitbesteed aan de Simaker-modules, die deze taken op een platformafhankelijke manier uitvoeren. Alle modules worden door de kern-programma s op verzoek geladen. Het proces is verduidelijkt in het schema in figuur 1. simaker.pl laadt laadt laadt Win32 (voert opdrachten uit ) Subsubsystem Simaker laadt laadt Routines Reftab... laadt Posix (voert opdrachten uit ) geven opdrachten aan Figuur 1: Uitvoering van taken binnen 'simake' door verschillende modules Alle platform-afhankelijke modules kunnen dezelfde set taken uitvoeren, maar elke module doet dit op een andere manier. Om een ander platform of een andere compiler te ondersteunen hoeven dan alleen nieuwe modules van het type Simaker gemaakt te worden en hoeft niets aan de kern-programma s gewijzigd te worden. De nieuwe klasse moet dan alle lidfuncties implementeren. Het is ook mogelijk om een subklasse te maken van een platform-afhankelijke module en

15 Technische beschrijving van het make-systeem alleen de afwijkende functies te implementeren. De afgeleide klasse erft dan alle functies van de basisklasse. Voor nieuwe functionaliteit in een nieuw Subsubsysteem moet een nieuwe subklasse van Subsubsystem of van een andere Subsubsystem-klasse gemaakt worden. De klasse moet de make - functie implementeren. 3.2 simake.pl Om het make-systeem te starten is het commando simake.pl. Dit commando voert de volgende taken uit: het onderzoekt op welk platform gecompileerd moet worden, en met welke compilers; het onderzoekt welke subsystemen gecompileerd moeten worden; het laadt de module met platform-afhankelijke en compilerafhankelijke routines; het onderzoekt welke subsystemen gecompileerd moeten worden; dit zijn alle gevraagde subsystemen en de subsystemen waarvan de gevraagde subsystemen afhankelijk zijn; het compileert alle benodigde subsystemen en linkt programma s; het genereert en installeert hulpbestanden en documentatie. 3.3 Tijdens runtime laden van modules Zowel de Simake -module als de Subsystem module laden op verzoek andere modules die verantwoordelijk zijn voor het uitvoeren van bepaalde taken. Er wordt zoveel mogelijk gestreefd naar het generiek maken van deze twee modules zodat alle specifieke taken in deelmodules uitgevoerd worden. Op deze manier blijft de kern van het systeem generiek en worden uitbreidingen elk in aparte, van elkaar onafhankelijke modules geïmplementeerd. Het laden van een module gebeurt in de volgende stappen: probeer de module te laden met behulp van een use <modulenaam> ; probeer een object te creëren met behulp van de constructor van die module; geef het object terug dat de benodigde taken kan uitvoeren.

16 Technische beschrijving van het make-systeem 3.4 Subsubsystemen De module Subsubsystem laadt op verzoek modules die de taken uitvoeren voor het gelijknamige subsubsysteem. De volgende typen subsubsystemen worden nu ondersteund: Routines, waarin broncode van bibliotheken en applicaties opgeslagen is; Modules, waarin FORTRAN-90 modules opgeslagen zijn; Archives, waarin voorgecompileerde bibliotheken opgeslagen zijn; Etc, waarin lds -bestanden en andere hulpbestanden opgeslagen zijn; Include, waarin include-bestanden opgeslagen zijn; Intpol, MM, Pre, Sds, Systemlib, die broncode van tools bevatten; Waqpre en Waqpro, die broncode van waquapublic bevatten; Matlab, waarin matlab scripts staan van matlab-applicaties; Reftab, waarin referentietabellen opgenomen zijn; Simetf, waarin het bronbestand van alle SIMONA foutmeldingen staat; Doc, waarin alle documentatie van het subsysteem in verzameld is. De subsubsystemen worden hier beschreven Routines.pm In routines staan C- en Fortran-bronbestanden die gecompileerd moeten worden. De gecompileerde bronbestanden moeten worden opgeslagen in een bibliotheek. Als er een programma-bronbestand aanwezig is, dan moet dit niet in de bibliotheek opgeslagen worden. In plaats daarvan moet het bronbestand gecompileerd worden en gelinkt worden met alle bibliotheken waarvan het programma afhankelijk is. Dit levert een executable op. Als er een bronbestand aanwezig is met de speciale naam <subsubsysteem>_dll.f, dan moet dit evenmin in de bibliotheek worden opgeslagen. Dit bestand moet worden gecompileerd en gelinkt tot een dynamisch linkbare bibliotheek. Onder Windows is dit een dll, onder Linux een shared object library (so-file).

17 Technische beschrijving van het make-systeem Modules.pm In modules staan FORTRAN-90 bronbestanden waarin FORTRAN-modules opgeslagen zijn. Deze bestanden moeten normaal gecompileerd worden, maar bovendien worden mod - bestanden aangemaakt. Deze aangemaakte bestanden worden gebruikt wanneer andere bronbestanden gecompileerd worden. Omdat zij met behulp van een use -statement in een FORTRANbroncodebestand gebruikt worden, moeten zij door het make-systeem in de include -directory geplaatst worden. Omdat zij bovendien platform-afhankelijk zijn, worden zij in de platformafhankelijke subdirectory geplaatst. Het plaatsten van de mod -bestanden in de juiste subdirectory is in feite een nabewerkingsslag van het gewone compileren. De make - slag kan dus gezien worden als een uitbreiding van de make -slag van Routines. Hierom is Modules een afgeleide klasse van Routines. Eerst wordt van Routines de make -functie aangeroepen. Daarna worden de verkregen modules in de juiste include-directory geplaatst Archives In Archives worden voorgecompileerde bibliotheken opgeslagen waarvan het niet wenselijk of mogelijk is om deze te compileren. Aan de namen van de bibliotheken is het platform toegevoegd waarvoor zij geschikt zijn. Tijdens het compileren van dit subsubsysteem worden de bibliotheken hernoemd naar de oorspronkelijke naam en worden zijn gekopieerd naar de lib/<ui_name> -directory Etc In Etc zijn hulpbestanden zoals lds -bestanden opgeslagen die zo veel mogelijk onbewerkt naar de etc -directory van SIMONA gekopieerd moeten worden Include In een 'include'-directory zijn include-bestanden opgeslagen die gebruikt worden tijdens het compileren van het subsysteem en tijdens het compileren van afhankelijke subsystemen. De include-files worden gekopieerd van.../<subsysteem>/include naar

18 Technische beschrijving van het make-systeem $SIMONADIR/include/<subsysteem> Bij het kopiëren van include-bestanden wordt onderzocht of zij aangepast zijn sinds het kopiëren naar de doeldirectory. Ongewijzigde bestanden worden niet opnieuw gekopieerd Sds, Mm, Systemlib, Pre, Intpol Deze subsubsystemen zijn onderdeel van de tools-bibliotheek. Zij dienen gecompileerd te worden zoals de programmabestanden in 'routines'. De modules zijn hierom slechts afgeleide klassen van 'Routines.pm', zonder verdere inhoud. Hierdoor zijn zij een soort alias voor Routines Waqpre, Waqpro Deze twee subsubsystemen zijn onderdeel van waquapublic. Zij dienen net zo gecompileerd te worden als Routines, dus de modules zijn ook afgeleide klassen van Routines Matlab Matlab-applicaties zijn opgeslagen in subsystemen met een matlab - subsubsysteem. Wordt de vlag copy_matlab gebruikt, dan wordt deze matlab -directory gekopieerd naar de matlab -directory van SIMONA. De bestanden worden niet bewerkt. Wordt de vlag niet gebruikt, dan zullen de matlab-applicaties worden gecompileerd mbv de matlab-compiler. Voorwaarde is wel, dat de compiler is geïnstalleerd en een geldige licentie aanwezig is Reftab Zoals reeds in hoofdstuk 2 is vermeld, kan het make-systeem ook referentietabellen compileren. Deze vorm van compileren is natuurlijk anders dan het compileren van fortran-bronbestanden, maar de essentie blijft dezelfde: bronbestanden worden verwerkt tot nieuwe bestanden, die vervolgens in een installatiedirectory geplaatst worden Simetf In hoofdstuk 2 is reeds vermeld dat het make-systeem ook het bestand met binair gecodeerde foutmeldingen SIMETF kan aanmaken. Het subsubsysteem simetf is alleen aanwezig in het (gelijknamige) subsysteem simetf.

19 Technische beschrijving van het make-systeem Doc Documentatie wordt door het make-systeem niet aangepast. In plaats daarvan kopieert de make -functie van de module Doc de documentatie naar de juiste plaats. Documentatie die in een subsysteem aanwezig is, wordt gekopieerd naar de documentatie-directory van SIMONA. Alleen 'pdf'-, 'doc'- en 'html'-bestanden worden gekopieerd. Documentatie die in een directory.../<subsysteem>/doc/<type> aanwezig is, wordt gekopieerd naar $SIMONADIR/doc/<type>/<subsysteem> waarbij de volgende typen documentatie ondersteund worden: usedoc; voor gebruikersdocumentatie; sysdoc; voor systeemdocumentatie; en techdoc; voor technische documentatie.

20 Compileren van broncode 4 Compileren van broncode 4.1 Inleiding Een belangrijke functie van het make-systeem is het compileren van bronbestanden en het uiteindelijk linken van executables. Voor het compileren van alle programma s is een set van compilervlaggen van toepassing. Deze compilervlaggen zijn gedefiniëerd in het bestand Makefile.gen. De verschillende bibliotheken en programma s hebben een samenhang die in elk subsysteem via een bestand config.txt gedefiniëerd wordt. Ook worden in dit bestand compiler-vlaggen gedefiniëerd die niet voor de alle SIMONA-programma s van toepassing zijn, maar wel nodig voor bepaalde bronbestanden. Sommige programma s van SIMONA gebruiken externe programma s die op het systeem geïnstalleerd moeten zijn voordat deze programma s gecompileerd kunnen worden. Op dit moment is de enige externe bibliotheek MPI. In ieder geval moet van MPI de installatie locatie opgegeven worden in het bestand Settings.inc. In dit hoofdstuk worden de drie typen bestanden beschreven. 4.2 Makefile.gen In Makefile.gen staan compilervlaggen die gebruikt worden tijdens het compileren van alle subsystemen. Vlaggen worden op de volgende manier gedefiniëerd: <variabelenaam> = <expressie> De variabelenaam mag bestaan uit letters, cijfers en underscores. In de expressie mogen ook variabelen voorkomen in de vorm van $(<variabele>) Deze variabelen worden ook in de omgeving ( environment ) gezocht en geëvalueerd. Variabele definities kunnen meerdere regels beslaan als het laatste teken een backslash ( \ ) is. Een aantal variabelen is platform-afhankelijk. De gangbare techniek hiervoor is om eerst de variabelenaam te definiëren in een naam waarin het platform verwerkt is. Daarna wordt de variabele gezet via een expressie waarin de variabele UI_NAME verwerkt is. Deze variabele is automatisch gezet op de naam van het platform Als voorbeeld wordt de variabele CFLAGS gezet met verschillende inhoud op Linux en op Windows: CFLAGS_win32 = /O CFLAGS_linux = -O CFLAGS = $(CFLAGS_$(UI_NAME))

21 Compileren van broncode Een aantal belangrijke instellingen is in het volgende hoofdstuk opgenomen. 4.3 Config.txt In elk subsysteem zijn allereerst de naam en de precisie aangegeven van het subsysteem met de volgende regel: <precisie>-subsystem <naam> Hierbij is <precisie> één van de volgende aanduidingen: geen aanduiding: het subsysteem is enkele precisie single-precision : het subsysteem is alleen in enkele-precisie modus te compileren; variable-precision : het subsysteem is in zowel enkeleprecisie als in dubbele-precisie modus te compileren. Op de volgende regels is aangegeven van welke subsystemen dit subsysteem afhankelijk is met regels als volgt: Uses <precisie> Subsystem <naam> Voor <precisie> worden dezelfde conventies gehanteerd als voor de definitie van het eigen subsysteem. Door op te geven van welke andere subsystemen het subsysteemn afhankelijk is, wordt bepaald: wat de volgorde is waarin subsystemen gecompileerd worden; welke include-directories gebruikt worden tijdens het compileren; welke bibliotheken gebruikt worden bij het linken van executables. Het derde gedeelte van het config.txt -bestand bevat compilervlaggen die alleen voor dit subsysteem van belang zijn. Het kan dan gaan om bijvoorbeeld het onderdrukken van bepaalde optimalisaties waarvan bekend is dat zij problemen geven, of het toevoegen van extra include-directories en externe bibliotheken. Het vierde en vijfde gedeelte zijn bedoeld voor de matlab-compiler. In het vierde gedeelte kan achter Matlabmainroutines: worden aangegeven, wat de hoofdroutines zijn. Het makesysteem weet dan dat er voor elke hoofdroutine een executable moet worden aangemaakt. Hoofdroutines moeten worden gescheiden d.m.v. een spatie.

22 In het vijfde gedeelte kan worden aangegeven, in welke directories de matlabscripts zich bevinden. Achter matlabdirectories: zal per hoofdroutine tenminste 1 directorie moeten worden opgegeven. Directorienamen per hoofdroutine zullen moeten worden gescheiden d.m.v. een spatie. Zijn de scripts voor een hoofdroutine verdeeld over meerdere subdirectories, dan zullen de subdirectories per hoofdroutine moeten worden gescheiden d.m.v. een Bijvoorbeeld: # 4. Matlab main routines Matlabmainroutines: kgwizard.m kalgui.m # 5. Matlab Directories matlabdirectories: sources wizard sources Voor het zetten van de variabelen in config.txt worden dezelfde conventies als in Makefile.gen gevolgd. 4.4 Settings.inc In het bestand Settings.inc staan instellingen die zowel van belang zijn bij het compileren van SIMONA-applicaties als tijdens de werking van programma s. De instellingen in Settings.inc hebben standaardwaarden die voor de meeste ontwikkelaars en gebruikers van toepassing zijn. Alleen als bijvoorbeeld MPI op een andere dan gebruikelijke plaats geïnstalleerd is moet deze locatie in Settings.inc gewijzigd worden. Bij alle instellingen staat uitleg over hoe deze gezet moet worden en wat het effect is.

23 Instellingen 5 Instellingen 5.1 Inleiding Met behulp van de instellingen in Makefile.gen kunnen compilervlaggen gezet worden. Sommige van deze vlaggen zijn essentieel, omdat zij bijvoorbeeld de lengte van een record in binaire bestanden beïnvloeden. Andere vlaggen sturen de hoeveelheid debug-informatie die het debuggen kunnen vergemakkelijken, terwijl andere vlaggen de optimalisatie beïnvloeden. In dit hoofdstuk wordt een kort overzicht gegeven van de belangrijkste instellingen die via Makefile.gen gezet kunnen worden. 5.2 Debug - release - of range -modus In Makefile.gen zijn per platform twee groepen van opties opgenomen, de debug en de release -instellingen. Met de debuginstellingen wordt code gegenereerd met onder andere: stacktraces ; bij een fout geeft het systeem weer in welk bestand en in welke regel de fout is opgetreden; range checking ; bij overschrijding van array-indexen stopt het programma; debug symbols ; nodig voor het debuggen van een programma in een debugger. Deze instellingen worden gebruikt tijdens de ontwikkeling van een programma. De eindgebruiker heeft doorgaans niet veel nut van de debug-instellingen. Code die met debug-instellingen gegenereerd is, is doorgaans niet geoptimaliseerd. Voor eindgebruikers wordt code dan ook gegenereerd in release -modus. De gegenereerde code in release -modus is sneller en zal minder vaak stoppen (doordat arrayindex overschrijdingen niet gedetecteerd worden). Op het Linux-platform is nog een derde modus range beschikbaar. Deze modus is gelijk aan de release -modus, met het verschil dat range-checking aan staat. Kiezen tussen de debug- en release-modus kan door de vlaggen FFLAGS_linux voor het Linux-platform, en FFLAGS_win32 voor het windows-platform te zetten zoals beschreven in Makefile.gen. 5.3 Belangrijke compilervlaggen In de onderstaande tabellen is een aantal nuttige compilervlaggen opgenomen. In deze tabel is tevens weergegeven in welke modus de vlag opgenomen is.

24 Instellingen Tabel 1: Compiler-vlaggen voor het Windows-platform Vlag debug Release betekenis /dbglibs + link met debugruntime bibliotheken /debug:full + zoveel mogelijk debug-informatie /traceback + geeft aan in welk bestand en in welke regel een fout optreedt /warn:argument_checking + geeft informatie over verkeerde subroutineaanroepen, waarbij het totaal aantal bytes van de argumenten wel klopt /nologo + + onderdrukt het Compaq Visual Fortran logo Tabel 2: compiler-vlaggen voor het Linux-platform Vlag debug release range betekenis -O optimalisatie -g genereren van debuginformatie in code -cm onderdrukt afdrukken van niet-essentiële informatie -vec-report onderdrukt afdrukken van informatie over code vectorisatie. -nbs / -assume nobscc zorgt ervoor dat een backslash geen escapekarakter is -assume byterecl forceert een recordlengte van 1 byte ipv 2 bytes -CB + + zorgt voor controle arrayen string-indices -warn all + geeft allerlei waarschuwingen tijdens compileren -fpstkchk + extra controle van de stack na elke functie- en subroutineaanroep -ftrapuv + controle op nietgeïnitialiseerde variabelen Bij de compilervlaggen geldt het volgende: De vlag -assume byterecl op het Linux-platform is niet strikt noodzakelijk voor de goede werking. Deze vlag is wel

25 Instellingen wel essentieel voor uitwisseling van SDS-bestanden met het windows-platform, waar bestanden een standaard recordlengte hebben van een byte; De -nbs -vlag heeft altijd voorrang boven de vlag -assume bscc. Deze laatste vlag is nodig voor het compileren van het bestand sistmd.f, wat weer nodig is voor het verwerken van tabs in invoerbestanden.

26 Referenties 6 Referenties [1] Vollebregt, E.A.H., Beschrijving van werkwijzen rondom het SIMONA beheer en onderhoud, SIMONA rapport , 2008.