2 File naming conventions

Mercury source files must be named *.m. Each Mercury source file should contain a single Mercury module whose module name should be (although it does not have to be) the same as the filename without the ‘.m’ extension.

The Mercury implementation uses a variety of intermediate files, which are described below. But all you really need to know is how to name source files. For historical reasons, the default behaviour is for intermediate files to be created in the current directory, but if you use the ‘--use-subdirs’ option to ‘mmc’ or ‘mmake’, all these intermediate files will be created in a Mercury subdirectory, where you can happily ignore them. Thus you may wish to skip the rest of this chapter.

In cases where the source file name and module name don’t match, the names for intermediate files are based on the name of the module from which they are derived, not on the source file name.

Files whose names end in .int, .int2, .int0 and .int3 are interface files; these are generated automatically by the compiler, using the ‘--make-interface’ (or ‘--make-int’), ‘--make-private-interface’ (or ‘--make-priv-int’), ‘--make-short-interface’ (or ‘--make-short-int’) options. (Invoking the compiler with ‘--make-interface’ generates both .int and .int2 files.) Files whose names end in .opt are used for inter-module optimization, and are created using the ‘--make-optimization-interface’ (or ‘--make-opt-int’) option. Similarly, files whose name ends in .trans_opt are used for transitive inter-module optimization, and are created using the ‘--make-transitive-optimization-interface’ (or ‘--make-trans-opt’) option.

Since the interface of a module changes less often than its implementation, the .int, .int0, .int2, .int3, .opt, and .trans_opt files will often remain unchanged when they are rebuilt. To avoid unnecessary recompilations of the clients of the module, the timestamps on these files are updated only if their contents change. Files with the suffixes .date, .date0, .date3, .optdate, and .trans_opt_date serve as timestamp files, to be used when deciding whether the interface files need to be regenerated: they each record the last time when the file or files it represents has last been checked for being up to date.

Files ending in .d are automatically generated Makefile fragments which contain the dependencies for a module. Files ending in .dep are automatically generated Makefile fragments which contain the rules for an entire program. Files ending in .dv are automatically generated Makefile fragments which contain variable definitions for an entire program.

As usual, .c files are C source code, and .o files are object code. In addition, .pic_o files are object code files that contain position-independent code (PIC). .lpic_o files are object code files that can be linked with shared libraries, but don’t necessarily contain position-independent code themselves. .mh and .mih files are C header files generated by the Mercury compiler. Their non-standard extensions are necessary to avoid conflicts with system header files.

.java files are Java source code, .class files are Java bytecode, and .jar files are Java archives.

.cs files are C# source code, .dll files are library assemblies and, when compiling to C#, .exe files are process assemblies.

When smart recompilation (see Auxiliary output options) is enabled, .c_date, .cs_date, .java_date and .erl_date files perform the same function for .c, .cs, .java and .erl files respectively as e.g. .date3 files do for .int3 files: when smart recompilation works out that a module does not need to be recompiled, it updates the timestamp of the timestamp file for the target file, but leaves the timestamp of the target file itself unchanged.

.used files contain dependency information for smart recompilation (see Auxiliary output options).