[ Skip to the content ]

Institute of Formal and Applied Linguistics Wiki


[ Back to the navigation ]

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
Next revision Both sides next revision
user:zeman:mdmake [2010/11/05 14:52]
zeman
user:zeman:mdmake [2010/11/05 15:28]
zeman
Line 4: Line 4:
  
 The most prominent phenomenon that is difficult to capture is what I call //multidimensionality// of the data. Every data file undergoes a sequence of processing steps, i.e. it appears in many different states (and intermediate data formats). Some processing tools may have alternative implementations, so you may have the same piece of data in the same stage of processing (e.g. syntactically parsed) but with different processing results (e.g. parsed either by Malt parser, or MST parser). Besides that, you may be applying the same processing to data in ten different languages, several domains per language, separately to development and evaluation test data etc. All these //dimensions// will probably be somehow reflected in the path to your data files. You probably would want to use pattern (template) rules in your Makefile to describe the same action applied to many files. However, gnu make allows you only one ''%'' (variable) per pattern rule, which makes it rather difficult to define templates in the multidimensional space. This is where **mdmake,** or “multidimensional make” may be useful. The most prominent phenomenon that is difficult to capture is what I call //multidimensionality// of the data. Every data file undergoes a sequence of processing steps, i.e. it appears in many different states (and intermediate data formats). Some processing tools may have alternative implementations, so you may have the same piece of data in the same stage of processing (e.g. syntactically parsed) but with different processing results (e.g. parsed either by Malt parser, or MST parser). Besides that, you may be applying the same processing to data in ten different languages, several domains per language, separately to development and evaluation test data etc. All these //dimensions// will probably be somehow reflected in the path to your data files. You probably would want to use pattern (template) rules in your Makefile to describe the same action applied to many files. However, gnu make allows you only one ''%'' (variable) per pattern rule, which makes it rather difficult to define templates in the multidimensional space. This is where **mdmake,** or “multidimensional make” may be useful.
 +
 +An older, more detailed discussion of the related problems is described [[rizeni-pokusu-pomoci-makefilu|here]] but it's in Czech.
 +
 +===== Makefile =====
 +
 +  * A MD-makefile (''makefile.mdm'') may contain all syntactic constructions that a normal makefile can contain. The constructions will be copied to a generated makefile and normal gnu make will be responsible for their interpretation. It has to be borne in mind however that they will be processed //after// the makefile will be generated. So for example if we include nested makefiles, these must be normal makefiles, not MD-makefiles.
 +  * Enumerate variables that contain values of respective dimensions. At the same time tell how to combine them into file names (paths). (The spaces will be deleted, their purpose here is to show what delimiter should be omitted if a dimension is omitted. Permitted delimiters are slash, hyphen and period.)
 +<code>.MDIMS: LANGUAGES/ DE TRAINTEST -PREPROCESSINGS .STATES</code>
 +  * The delimiters are not mandatory but MD-make checks whether missing delimiters do not cause ambiguities (e.g. if LANGUAGES = hi him, DOMAINS = mix ix, then .MDIMS: LANGUAGES DOMAINS would cause problems).
 +  * The last dimension in the list of dimensions is special. It need not be named STATES and it need not be delimited by a period (although it is recommended - in some operating systems it is desirable that the file name extension defines the type of the contents), nevertheless the value of this dimension is considered the type of the file. Among others, the file type defines, in what dimensions the files of this type exist. MD-make gets that information from the rule that generates files of this type as its goal. For every type there must be at least one such rule. Theoretically there can be more if e.g. we want to perform different actions for different languages. In that case all such rules must lead to the same list of dimensions of the goal. However, they are not required to cover together all values of all these dimensions.
 +  * The respective variables with values of the respective dimensions must be normal variables containing only a list of words separated by spaces. MD-make will not search them for references to other variables or macros. If it encounters a dollar sign in these variables, it will throw an exception and terminate. These variables will be visible in the generated makefile as well.
 +  * No value in no dimension can be identical with any other value of any dimension. In other words, a value uniquely identifies its dimension. (This helps prevent ambiguities in file names that do not contain all dimensions.)
 +  * There are special keywords to mark a multidimensional pattern rule. The following parameters can be supplied, too:
 +    * In what dimensions the target file exists. (The other dimensions will not appear in the file name.)
 +    * What are the constraints for the values in the respective dimensions. (Standard way is the ''.md.if'' directive but we would like to be able to constrain the ''.STATES'' dimension (or the last dimension in the list) directly in the rule.
 +    * MD-make will generate many normal rules from the multidimensional rule. In these generated rules, all combinations of all values in all affected dimensions will appear. As these rules are not templatic any more, we don't have to fear that gnu make will encounter cyclic dependencies or other problems.
 +
 +    * Uvnitř příkazů lze použít nové proměnné ''$(*1)'', resp. místo jedničky jiné číslo, pro n-tou závislost. MD-make si najde pravidlo, kterým tato závislost vzniká, zjistí si z&nbsp;něj, v&nbsp;jakých rozměrech se pohybuje, a podle toho zkonstruuje jméno příslušného souboru, které na dané místo vloží. Beze změny ponechá ''$<'' a ''$^'', které budou fungovat samy od sebe, avšak pozor na ''$*'', které v&nbsp;MD pravidlech (na rozdíl od obyčejných šablonovitých pravidel) nemá smysl.
 +    * MD pravidlo končí povinně prázdným řádkem (dokonce i na konci souboru).
 +    * Není-li uveden parametr ''.md.for'', pravidlo se rozgeneruje pro všechny známé rozměry kromě posledního (u nás ''STATES'', ale může se jmenovat i jinak).
 +    * Parametr ''.md.fix'' obsahuje hodnoty, které jsou v&nbsp;tomto pravidle pevné, tj. pravidlo se nerozgenerovává pro ostatní hodnoty téhož rozměru. Není zatím dovoleno uvést více hodnot ve stejném rozměru (i když by to teoreticky mohlo sloužit k&nbsp;vymezení částečného rozgenerování).
 +      * Jestliže ''.md.fix'' obsahuje rozměr, který je současně uveden v&nbsp;''.md.for'', znamená to, že cílový typ souboru se pohybuje v&nbsp;tomto rozměru, má jeho hodnotu uvedenou v&nbsp;cestě, akorát toto konkrétní pravidlo generuje tento soubor pouze pro jednu hodnotu v&nbsp;dotyčném rozměru.
 +      * Jestliže ''.md.fix'' obsahuje rozměr, který není současně uveden v&nbsp;''.md.for'', znamená to, že cílový typ souboru tento rozměr nezná a nemá ho uveden v&nbsp;cestě, avšak některý ze zdrojových souborů tento rozměr má a potřebuje vědět, kterou hodnotu máme na mysli. Které ze zdrojových souborů hodnotu ''.md.fix'' využijí, poznáme z&nbsp;pravidel, která tyto soubory generují jako cílové a vymezují jejich rozměry.
 +      * Jestliže některý zdrojový soubor vyžaduje rozměr, který cílový soubor neobsahuje, a tento rozměr není zafixován, pravidlo se rozgeneruje i pro všechny hodnoty tohoto rozměru. Bude pak existovat několik konkurenčních pravidel, která vytvářejí tentýž cílový soubor.
 +    * ''.md.del'' odstraní rozměry z&nbsp;''.md.for'' (nejvíce se hodí, když ''.md.for'' není uvedeno a defaultně tedy obsahuje všechny rozměry)
 +    * ''.md.fxd'' je jako ''.md.fix'' a ''.md.del'' dohromady. Uvádějí se hodnoty, nikoli názvy rozměrů (tedy jako u ''.md.fix'' a na rozdíl od ''.md.del'')
 +    * Odkaz na hodnotu rozměru z&nbsp;příkazu (např. ''$(*LANGUAGES)'') se převede na aktuální hodnotu daného rozměru. Pokud mohou mít různé zdrojové soubory různé hodnoty téhož rozměru v&nbsp;rámci jednoho vygenerovaného pravidla, odkaz se převede na hodnotu, které v&nbsp;tomto rozměru nabývá cílový soubor, resp. která je proměnná. Odkazy tohoto druhu byly stejně zavedeny kvůli proměnným rozměrům. Odlišné hodnoty u konkrétních zdrojových souborů jsou fixní výjimky, tyto hodnoty známe předem a v&nbsp;případě potřeby je můžeme do příkazu zapsat přímo.
 +
 +<code>.MDRULE
 +.md.rul mst.conll < blind.conll mst
 +.md.dep $(TOOLDIR)/runmst.pl
 +.md.for: LANGUAGES DE PREPROCESSINGS
 +.md.fix: test
 +        @echo Running MST for language $(*LANGUAGES):
 +        $(TOOLDIR)/runmst.pl -m $(*2) < $< > $@</code>
 +
 +  * Je možné definovat vstupní soubory. Ty typicky leží úplně v&nbsp;jiné cestě, nebo se alespoň jmenují tak, aby se nepletly se soubory pojmenovanými pomocí hodnot rozměrů, a nehrozilo tudíž jejich smazání makem. Můžeme popsat jejich vlastnosti v&nbsp;jednotlivých rozměrech prostě tak, že vytvoříme obyčejné pravidlo, kde dotyčný vstupní soubor bude jako závislost, zatímco cíl bude soubor pojmenovaný příslušnými hodnotami rozměrů. Před pravidlo připíšeme ''.md.in:''. MD-make pak doplní příkaz pro zkopírování závislosti do cíle (''cp $< $@'') a navíc zkontroluje, že cílový soubor má hodnoty všech rozměrů, které soubor v&nbsp;daném stavu (hodnota posledního rozměru) má mít.
 +  * Vygenerovaný makefile by navíc mohl obsahovat pro každou hodnotu každého rozměru seznam souborů, v&nbsp;nichž je tato hodnota zafixovaná. Např. všechny cílové soubory v&nbsp;jazyce "hi". Kromě proměnné obsahující jména těchto souborů (HIFILES) by vygenerovaný makefile obsahoval cíl, který všechny tyto soubory vyrobí (hi), a cíl, který je smaže (clean_hi).
 +  * V&nbsp;průběhu generování vícerozměrných pravidel si pamatovat seznam všech vygenerovaných cílových souborů. Ke každému cílovému souboru vytvořit hash, jehož klíčem je hodnota libovolného rozměru a hodnota u daného klíče je nenulová, jestliže příslušná hodnota rozměru je v&nbsp;názvu souboru obsažena. Na konci makefilu lze použít pravidlo ''.MDALL'', které vytvoří ''.PHONY'' cíl závisející na všech souborech obsahujících určité hodnoty. Např.
 +
 +<code>.MDALL: d hi conll</code>
 +
 +se přepíše jako
 +
 +<code>.PHONY: all_d_hi_conll
 +all_d_hi_conll: <seznam všech souborů obsahujících hodnoty "d", "hi" a "conll"></code>

[ Back to the navigation ] [ Back to the content ]