# HG changeset patch # User wenzelm # Date 1554409096 -7200 # Node ID 0403b5127da17a4315ce07b3940ecf169cd3cafb # Parent 25c0ad612d622bca88425f4ab052ff39dd275942 documentation for generated files; diff -r 25c0ad612d62 -r 0403b5127da1 NEWS --- a/NEWS Thu Apr 04 22:17:37 2019 +0200 +++ b/NEWS Thu Apr 04 22:18:16 2019 +0200 @@ -41,6 +41,13 @@ need to provide a closed expression -- without trailing semicolon. Minor INCOMPATIBILITY. +* Commands 'generate_file', 'export_generated_files', and +'compile_generated_files' support a stateless (PIDE-conformant) model +for generated sources and compiled binaries of other languages. The +compilation processed is managed in Isabelle/ML, and results exported to +the session database for further use (e.g. with "isabelle export" or +"isabelle build -e"). + *** Isabelle/jEdit Prover IDE *** diff -r 25c0ad612d62 -r 0403b5127da1 src/Doc/Isar_Ref/Spec.thy --- a/src/Doc/Isar_Ref/Spec.thy Thu Apr 04 22:17:37 2019 +0200 +++ b/src/Doc/Isar_Ref/Spec.thy Thu Apr 04 22:18:16 2019 +0200 @@ -1188,18 +1188,102 @@ \ -section \External file dependencies\ +section \Generated files and external files\ text \ - \begin{matharray}{rcl} + Write access to the physical file-system is incompatible with the stateless + model of processing Isabelle documents. To avoid bad effects, the theory + context maintains a logical ``file-system'' for generated files, as a + mapping of structured file-names to content. Names need to be unique for + each theory node. When exporting generated files for other purposes, the + (long) theory name is prefixed for extra qualification, but there are also + means to smash overlong paths. See also @{cite "isabelle-system"} for + \<^theory_text>\export_files\ within session \<^verbatim>\ROOT\ files, together with @{tool build} + option \<^verbatim>\-e\. + + \begin{matharray}{rcll} + @{command_def "generate_file"} & : & \local_theory \ local_theory\ \\ + @{command_def "export_generated_files"} & : & \context \\ \\ + @{command_def "compile_generated_files"} & : & \context \\ \\ @{command_def "external_file"} & : & \any \ any\ \\ \end{matharray} - \<^rail>\@@{command external_file} @{syntax name} ';'?\ + \<^rail>\ + @@{command generate_file} path '=' content + ; + path: @{syntax embedded} + ; + content: @{syntax embedded} + ; + @@{command export_generated_files} (files_in_theory + @'and') + ; + files_in_theory: (@'_' | (path+)) (('(' @'in' @{syntax name} ')')?) + ; + @@{command compile_generated_files} (files_in_theory + @'and') \ + (@'external_files' (external_files + @'and'))? \ + (@'export_files' (export_files + @'and'))? \ + (@'export_prefix' path)? + ; + external_files: (path+) (('(' @'in' path ')')?) + ; + export_files: (path+) (executable?) + ; + executable: '(' ('exe' | 'executable') ')' + ; + @@{command external_file} @{syntax name} ';'? + \ + + \<^descr> \<^theory_text>\generate_file path = content\ augments the table of generated files + within the current theory by a new entry: duplicates are not allowed. The + name extension determines a pre-existent file-type; the \content\ is a + string that is preprocessed according to rules of this file-type. + + For example, Isabelle/Pure supports \<^verbatim>\.hs\ as file-type for Haskell: + embedded cartouches are evaluated as Isabelle/ML expressions of type + \<^ML_type>\string\, the result is inlined in Haskell string syntax. + + \<^descr> \<^theory_text>\export_generated_files paths (in thy)\ retrieves named generated files + from the given theory (that needs be reachable via imports of the current + one). By default, the current theory node is used. Using ``\<^verbatim>\_\'' + (underscore) instead of explicit path names refers to \emph{all} files of a + theory node. + + The overall list of files is prefixed with the respective (long) theory name + and exported to the session database. In Isabelle/jEdit the result can be + browsed via the virtual file-system with prefix ``\<^verbatim>\isabelle-export:\'' + (using the regular file-browser). + + \<^descr> \<^theory_text>\compile_generated_files paths (in thy) where compile_body\ retrieves + named generated files as for \<^theory_text>\export_generated_files\ and writes them into + a temporary directory, such that the \compile_body\ may operate on them as + an ML function of type \<^ML_type>\Path.T -> unit\. This may create further + files, e.g.\ executables produced by a compiler that is invoked as external + process (e.g.\ via \<^ML>\Isabelle_System.bash\), or any other files. + + The option ``\<^theory_text>\external_files paths (in base_dir)\'' copies files from the + physical file-system into the temporary directory, \emph{before} invoking + \compile_body\. The \base_dir\ prefix is removed from each of the \paths\, + but the remaining sub-directory structure is reconstructed in the target + directory. + + The option ``\<^theory_text>\export_files paths\'' exports the specified files from the + temporary directory to the session database, \emph{after} invoking + \compile_body\. Entries may be decorated with ``\<^theory_text>\(exe)\'' to say that it is + a platform-specific executable program: the executable file-attribute will + be set, and on Windows the \<^verbatim>\.exe\ file-extension will be included; + ``\<^theory_text>\(executable)\'' only refers to the file-attribute, without special + treatment of the \<^verbatim>\.exe\ extension. + + The option ``\<^theory_text>\export_prefix path\'' specifies an extra path prefix for all + exports of \<^theory_text>\export_files\ above. \<^descr> \<^theory_text>\external_file name\ declares the formal dependency on the given file name, such that the Isabelle build process knows about it (see also @{cite - "isabelle-system"}). The file can be read e.g.\ in Isabelle/ML via \<^ML>\File.read\, without specific management by the Prover IDE. + "isabelle-system"}). This is required for any files mentioned in + \<^theory_text>\compile_generated_files / external_files\ above, in order to document + source dependencies properly. It is also possible to use \<^theory_text>\external_file\ + alone, e.g.\ when other Isabelle/ML tools use \<^ML>\File.read\, without + specific management of content by the Prover IDE. \