GiellaLT provides an infrastructure for rule-based language technology aimed at minority and indigenous languages, and streamlines building anything from keyboards to speech technology.

View GiellaLT on GitHub

Page Content

Naming and organisation of the makefiles

The directory structure is described in this document. Almost every directory has one make file, named The .am suffix is there to indicate that the files are going to be processed by automake, to produce files, which are processed by configure to produce the final Makefile’s that make can process.

Most of the files have an include statement at the end, by which they include shared build instructions, These shared build instructions are common to all languages (thus shared), and they are always located in $top_srcdir/am-shared ($top_srcdir refers to the language dir, like sme, sma, etc.).

The “am-shared” dir

There are three types of files in the am-shared dir, each with their own file naming scheme:

  1. named after the dir of the including file (these files should always be included by the files, then these included files can further include other include files, see below). These files must always end in
    • => included by the following file:
  2. named after the type of source file to be processed by the makefile. These are utility include files, so to speak, in the sense that they will process files of one type irrespective of source file location, using the utility (or utilities) as indicated by the the file name of the include file. The name of these files do not include an underscore, and not the string -dir. This allows processing abstration over file types independent of location, and will make it easier to maintain the core build code for all file types.
    • => compile vislcg3 files
    •   => compile twolc files
    •   => compile regex files
  3. named after configure option/application-specific targets, and after the including file. These files are always included by another include file, and the purpose is to avoid filling up the main include file by all sorts of optional build code. The first part of the filename follows the directory part of the including file, then followed by underscore ( _ ) followed by the tag for the configure option, and finally ending with as usual.
    • => included by

Summary: it is possible to programmatically identify all three types:

Other (regular) dirs

The Automake files are everywhere else named These do always include the Automake include files in am-shared/, and always and only the include file named after the directory which the is located in. That is, the file tools/spellcheckers/fstbased/ includes the file am-shared/

There are a couple of conventions to observe:

  1. the target clean-local: should always be defined in the local - not in the include files; if there is a need to define clean operations in the include files, it should be through the use of the variable CLEANFILES, e.g. something like:
  2. the include file am-shared/ should only be included by the * files to avoid double inclusion and subsequent double definitions of the same variables

There might be some violations of these conventions, they should be cleaned up as they are found.