Next: , Previous: , Up: Top   [Contents][Index]


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 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 ending in .int, .int0, .int2 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. Files ending in .opt are interface files used in inter-module optimization, and are created using the ‘--make-optimization-interface’ (or ‘--make-opt-int’) option. Similarly, files ending in .trans_opt are interface files used in transitive inter-module optimization, and are created using the ‘--make-transitive-optimization-interface’ (or ‘--make-trans-opt-int’) option.

Since the interface of a module changes less often than its implementation, the .int, .int0, .int2, .int3, .opt, and .trans_opt files will remain unchanged on many compilations. To avoid unnecessary recompilations of the clients of the module, the timestamps on the these files are updated only if their contents change. .date, .date0, .date3, .optdate, and .trans_opt_date files associated with the module are used as timestamp files; they are used when deciding whether the interface files need to be regenerated.

.c_date, .cs_date, .java_date and .erl_date files perform a similar function for .c, .cs, .java and .erl, files respectively. When smart recompilation (see Auxiliary output options) works out that a module does not need to be recompiled, the timestamp file for the target file is updated, and the timestamp of the target file is left unchanged.

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

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. The non-standard extensions are necessary to avoid conflicts with system header files. .java, .class and .jar files are Java source code, Java bytecode and Java archives respectively. .cs files are C# source code. .erl and .beam files are Erlang source code and bytecode (object) files respectively. .beams directories are collections of .beam files which act like a library archive.


Next: , Previous: , Up: Top   [Contents][Index]