!standard 3.12.1 09-01-21 SI99-0043-1/01 !class confirmation 09-01-21 !status work item 09-01-21 !status received 08-12-08 !priority Low !difficulty Easy !subject Multiple A_Configuration_Compilation_Units are supported !summary ASIS allows multiple units to exist in a Context that have Unit_Kinds = A_Configuration_Compilation_Unit. !question Consider the A_Pragma Elements that belong to A_Configuration_Compilation unit. They can be obtained as the results of Asis.Elements.Configuration_Pragmas and Asis.Elements.Compilation_Pragmas queries. That is, elements representing configuration pragmas. The problem is that their enclosing A_Configuration_Compilation unit is not a first-class unit citizen, the current ASIS Standard says that it can be (at most) one unit of this kind in a Context. If configuration pragmas can be placed into configuration files (as is the case for many implementation), and a compilation may use more then one configuration file, we may have overlapped spans for configuration pragma elements that does not seem to be reasonable and useful. What is the intent here? !response (See summary.) !discussion The comment on the definition of A_Configuration_Compilation_Unit says in part: "A Context is not limited to the number of units of A_Configuration_Compilation kind." So the questioner's assertion that there is at most one such unit is incorrect. !appendix From: Sergey I. Rybin Sent: Monday, December 8, 2008 6:06 AM This message comes form a practical problem reported for the GNAT ASIS implementation. Consider the A_Pragma Elements that belong to A_Configuration_Compilation unit. They can be obtained as the results of Asis.Elements.Configuration_Pragmas and Asis.Elements.Compilation_Pragmas queries. That is, elements representing configuration pragmas. The first question - are these A_Pragma elements Is_Part_Of_Implicit? If they are not, they should test True with Asis.Text.Is_Text_Available, so Asis.Text.Element_Span should return some non-nil result for them. But what does the span mean in this case? (The problem is that their enclosing A_Configuration_Compilation unit is not a first-class unit citizen, the current ASIS Standard says that it can be (at most) one unit of this kind in a Context. And in case of GNAT where configuration pragmas are placed into configuration files, and a compilation may use more then one configuration file, we may have overlapped spans for configuration pragma elements that does not seem to be reasonable and useful. For me it looks like a gap in the ASIS Standard. Another problem corresponds to Asis.Compilation_Units.Text_Name query. ASIS does not forbid A_Configuration_Compilation unit to be an argument for this query, but in case when configuration pragmas can be located in configuration files, this query does not make very much sense for A_Configuration_Compilation unit, because we may have at most one such unit in each ASIS Context, so it is not clear which file name should be returned. The only reasonable, but useless possibility is to return a null result. Next thing. When defining A_Configuration_Compilation value of the Unit_Kind type, ASIS says: -- Corresponds to the whole content of a compilation with no -- compilation_unit, but possibly containing comments, configuration -- pragmas, or both. Any Context can have at most one unit of -- A_Configuration_Compilation kind. A unit of -- A_Configuration_Compilation does not have a name. This unit -- represents configuration pragmas that are "in effect". But there is no way to get the list of pragmas from A_Configuration_Compilation unit. Should we add a structural query that would allow to do this? And finally, the general suggestion. We may add more flexibility to the way how the ASIS Standard deals with A_Configuration_Compilation unit. The current situation may be kept as a minimal requirement, and the ASIS Standard may allow to have more then one *different* (that is, not Is_Equal) A_Configuration_Compilation units in the same Context. All these A_Configuration_Compilation unit should not have a name (in the sense of the Asis.Compilation_Units.Unit_Full_Name query), but they may be allowed to generate non-null results when submitted to Asis.Compilation_Units.Text_Name query. This would make reasonable the span returned for configuration pragmas, and at the application side it would allow to get a reasonable and useful answer for the question: "Where does this configuration pragma come from?" Thoughts? **************************************************************** From: Tucker Taft Sent: Tuesday, December 9, 2008 12:51 AM I don't understand the original ASIS limitation to a single configuration compilation unit. Certainly our AdaMagic front end allows any number of compilations consisting only of pragmas. If GNAT does as well, that means Green Hills, Aonix, and GNAT all allow this. It seems silly to impose a limitation that is not required by a number of Ada implementations. Your suggestion seems reasonable, but perhaps we should go further? **************************************************************** From: Pascal Leroy Sent: Wednesday, December 10, 2008 1:03 AM > Certainly our AdaMagic front end allows any number of compilations > consisting only of pragmas. If GNAT does as well, > that means Green Hills, Aonix, and GNAT all allow this. As I recall the IBM implementation also allowed any number of compilations consisting only of pragmas. **************************************************************** From: Sergey I. Rybin Sent: Wednesday, December 10, 2008 3:17 AM > I don't understand the original ASIS limitation to a single > configuration compilation unit. I think it may originate from old Ada days when it might be reasonable for old heavy-weight implementations of compilation libraries. Anyway, now it definitely looks odd. > Your suggestion seems reasonable, but perhaps we should go further? What do you mean? **************************************************************** From: Sergey I. Rybin Sent: Wednesday, December 10, 2008 4:33 AM I've just realised that this issue is not as clear as I thought... The typical ASIS implementation technique is to use some precompiled stuff as a basis for representing the ASIS Context. And here we have the consistency problem. This problem is very similar to what is said in RM 05 10.1.4(5). But nothing is said about consistency of configuration prarmas! Consider the following situation: we have procedure Proc1 is ... end Proc1; procedure Proc2 is ... end Proc2; with Proc1, Proc2; procedure Main is ... end Main; We put a configuration pragma (let it be, for example 'pragma Ada_95;') into the configuration file 'gnat.adc' and compile Proc1. Then we edit the configuration file (replace 'pragma Ada_95;' with 'pragma Ada_05;') and compile Proc2. Then we remove the configuration file and compile Main. The situation is quite legal from the point of view of the Ada Standard. So it should be possible in ASIS to define and to process an ASIS Context based on these compilations. And what do we have in this Context? The result of Asis.Elements.Compilation_Pragmas will be: - 'pragma Ada_95;' if the argument is Proc1; - 'pragma Ada_05;' if the argument is Proc2; - empty list if the argument is Main; So, if we would like to remove the existing limitations for A_Configuration_Compilation unit, the question is - how many A_Configuration_Compilation units will we have in this context, and what are their properties (text names, the content etc...)? **************************************************************** From: Tucker Taft Sent: Wednesday, December 10, 2008 1:19 PM I think you should assume a source-based view of the world, so there is exactly one set of configuration pragmas in force at any given moment. They may have originated from multiple files, but not from multiple versions of the same file. I don't think we need to handle libraries that are not self-consistent, including configuration pragmas. **************************************************************** From: Tucker Taft Sent: Wednesday, December 10, 2008 1:25 PM By "going further" I meant that I didn't understand why these multiple pragma-only compilations shouldn't have a name. I may not understand the implications of the distinction you are making in this sentence: ...All these A_Configuration_Compilation unit should not have a name (in the sense of the Asis.Compilation_Units.Unit_Full_Name query), but they may be allowed to generate non-null results when submitted to Asis.Compilation_Units.Text_Name query. Is this saying that these pragma-only compilations don't have Ada compilation-unit names, but they do have source-code file names? If so, I guess that makes sense... **************************************************************** From: Sergey I. Rybin Sent: Wednesday, December 10, 2008 1:51 PM > I think you should assume a source-based view of the world, so there > is exactly one set of configuration pragmas in force at any given > moment. But an ASIS Context is not a snapshot of a *moment*, it is a view of an Ada compilation environment, that may originate from more then one compilation. > They may have > originated from multiple files, but not from multiple versions of the > same file. According to the Ada Standard, this is true only for Ada compilation units. The notion of a configuration *file* is completely outside the semantic of the Ada language as it is defined by the Standard. And different compilations may be using different sets of configuration pragmas. Placing these pragmas into this or that configuration file is just an implementation detail. > I don't think we need > to handle libraries that are not self-consistent, That's true. > including configuration pragmas. This is also true, but it does not prevent us from different versions of the same configuration file to be used to make up the same ASIS Context. (May be I'm inventing problems here, but I think we have to consider all possibilities that we may have) **************************************************************** From: Randy Brukardt Sent: Wednesday, December 10, 2008 1:57 PM > I think you should assume a source-based view of the world, so there > is exactly one set of configuration pragmas in force at any given > moment. They may have originated from multiple files, but not from > multiple versions of the same file. I don't think we need to handle > libraries that are not self-consistent, including configuration > pragmas. This doesn't make much sense to me. I've always viewed configuration pragmas as essentially Ada syntax for compiler options. Indeed, that's all they are in Janus/Ada: a funky way to set default compiler options in the project file. (It's usually easier to do that via other tools, but of course not as portable.) Obviously, compiler options can vary for each compilation that makes up a partition. If you can read such pragmas at all, the only sane way to do it in Janus/Ada would be to synthesize appropriate pragmas based on the options used for each unit. There are no global pragmas. Indeed, for many (most?) projects, global settings don't make sense. If a project is large enough that parts are developed by separate teams (the ultimate being a third-party subsystem such as Claw), it doesn't make sense to make global settings. For instance, Claw is Ada 95 code and (since it has a few return-by-reference functions) can't be compiled in Ada 2005 mode. A global setting of Ada 2005 is going to prevent the use of Claw. Similarly, a global Suppress_All setting would make Claw malfunction. Surely there are projects created solely in-house with strong management (most avionics comes to mind) that probably could use global settings. But real-world project management is more flexible than that. ASIS ought to be able to deal with the real world capabilities of project management (at least to the extent that it is visible in Ada, such as configuration pragmas). **************************************************************** From: Randy Brukardt Sent: Wednesday, December 10, 2008 2:00 PM ... > This is also true, but it does not prevent us from different versions > of the same configuration file to be used to make up the same ASIS > Context. Right. Our project management facilities allow each individual compilation to have its own set of configuration pragmas (represented as compiler options). It is easy to think of that as different versions of the configuration file applying to each compilation. > (May be I'm inventing problems here, but I think we have to consider > all possibilities that we may have) No, I think you are on the right track. **************************************************************** From: Sergey I. Rybin Sent: Wednesday, December 10, 2008 1:57 PM > Is this saying that these pragma-only compilations don't have Ada > compilation-unit names, but they do have source-code file names? If > so, I guess that makes sense... But this is exactly that I have proposed... In Asis.Compilation_Units we have two queries for obtaining names: Unit_Full_Name: -- Returns the string image of the fully expanded Ada name of the given -- compilation unit. This may be a simple name ("A") of a root library -- unit, or an expanded name ("A.B") of a subunit or non-root child unit. -- An expanded name shall contain the full parent_unit_name as its prefix. -- Returns a null string only if A_Configuration_Compilation or a -- Nil_Compilation_Unit is given. Text_Name: -- Returns the name of the text, or other structure, that was the source -- of the compilation that resulted in this Compilation_Unit. Returns a -- null string if the unit has a Nil or nonexistent kind, or if the text -- name is not available for any reason. In case of a A_Configuration_Compilation, Unit_Full_Name should definitely return null result, because this query is supposed to return a sting image of the Ada name, and we do not have an Ada name for A_Configuration_Compilation unit, but Text_Name (in case of our source-based compilation systems that relay on the underlying file system) is a perfect means to get the name of the configuration *file*. **************************************************************** From: Tucker Taft Sent: Wednesday, December 10, 2008 2:20 PM Thanks, that clarifies the situation. It sounds like Text_Name is the correct way to give the file name. **************************************************************** From: Tucker Taft Sent: Wednesday, December 10, 2008 2:36 PM > This doesn't make much sense to me. I've always viewed configuration > pragmas as essentially Ada syntax for compiler options. Indeed, that's > all they are in Janus/Ada: a funky way to set default compiler options > in the project file. (It's usually easier to do that via other tools, > but of course not as portable.) There are two ways of using configuration pragmas, in a file all by themselves, in which case they apply to everything in the library, or at the head of the source file, in which case they apply only to that source file. I can believe that some compilers have limitations on the first way, in particular the RM allows them to only support the pragma-only units when the library is empty. But I don't think ASIS needs to worry about the situation where the pragma-only units are changed back and forth between different compilations. That really isn't the model of pragma-only units. Certainly every source file can have its own set of configuration pragmas, but those are the ones that appear at the head of the file. The other ones are the "library" configuration pragmas, and those apply to every compilation in the library. I realize the RM says the configuration pragmas in a pragma-only compilation apply to "all future" compilation units, but I had always presumed that any time you did a "build," you were effectively recompiling everything in the library needed for the executable, and thereby whatever was the state of the pragma-only compilations at that moment determined the pragmas that applied to the executable. I can't quite get my head around how any other interpretation would work for these pragma-only files, since you can't name them in a with clause, and if you "zipped" up an archive of your sources, you would get exactly one set of pragma-only files and that is what represents the way your program should be built. Our compiler also has the notion of "sublibraries" and these can each have separate sets of pragma-only compilations, so that gives you some flexibility, and perhaps other compilers have a similar approach. The Ada 2005 vs. Ada 95 could be handled with this sublibrary approach, putting the Ada 95 code in a sublibrary without the Ada 2005 pragma. Alternatively, you could handle it by adding a configuration pragma to the head of each file that didn't want the "default" settings. But I certainly hope you wouldn't have an "order dependent" interpretation of pragma-only compilations, because that seems pretty much doomed to failure upon any kind of automated recompilation or transfer of sources to someone else. Am I way off here in my model? **************************************************************** From: Jean-Pierre Rosen Sent: Wednesday, December 10, 2008 4:01 PM > Obviously, compiler options can vary for each compilation that makes > up a partition. If you can read such pragmas at all, the only sane way > to do it in Janus/Ada would be to synthesize appropriate pragmas based > on the options used for each unit. There are no global pragmas. [...] > Surely there are projects created solely in-house with strong > management (most avionics comes to mind) that probably could use > global settings. But real-world project management is more flexible > than that. ASIS ought to be able to deal with the real world > capabilities of project management (at least to the extent that it is > visible in Ada, such as configuration pragmas). Wait a minute. We are discussing about removing the restriction of having only one conceptual unit for all pragmas! If, for your implementation, it makes more sense to group all options (ignoring how they are provided) into one conceptual unit, noone is asking you to change your way. But for those implementations that do have several physical files containing configuration pragmas, it makes little sense to force the ASIS implementation to conceptually merge them. For the issue of changing the configuration between compilations, there is certainly an issue here, but I don't think that removing the restriction would change the problem. **************************************************************** From: Randy Brukardt Sent: Wednesday, December 10, 2008 6:19 PM I think both Sergey and Tucker have moved beyond that specific issue into the more general question of whether the ASIS model can map the real world very well. After all, if you get really pedantic, neither GNAT nor Janus/Ada have any support for configuration pragmas in the sense envisioned in the Ada Standard. Such pragmas don't exist in a separate source file somewhere, but rather as part of a project file. That being the case, it would make sense for an ASIS implementation to ignore them completely (it doesn't really define what happens outside of Ada source files; it assumes that everything that exists in the program exists in source somewhere, which has been a never-ending source of problems). But is that really the useful and appropriate thing to do? > For the issue of changing the configuration between compilations, > there is certainly an issue here, but I don't think that removing the > restriction would change the problem. No, I was responding to Tucker's "should we go further" and Sergey's response to that and his concern about versioning. If we bother changing these rules at all, we ought to get them right; just getting rid of a restriction to one unit doesn't do much at all in that direction. **************************************************************** From: Tucker Taft Sent: Wednesday, December 10, 2008 8:25 PM > After all, if you get really pedantic, neither GNAT nor Janus/Ada have > any support for configuration pragmas in the sense envisioned in the > Ada Standard. Such pragmas don't exist in a separate source file > somewhere, but rather as part of a project file. My sense is that GNAT supports having configuration pragmas in a separate file. It used to always be called "gnat.adc." It seems like it can be named anything now, with the name specified in the project file with a command: for Global_Configuration_Pragmas use "config_prag.adc"; I'm not sure whether you can have multiple config-pragma files for a single project, but you can have multiple projects as part of a single build. > ... > No, I was responding to Tucker's "should we go further" and Sergey's > response to that and his concern about versioning. If we bother > changing these rules at all, we ought to get them right; just getting > rid of a restriction to one unit doesn't do much at all in that direction. I am not an expert on how ASIS deals with inconsistency and versioning in general, but I don't see the need to make configuration pragmas a big special case. I really can't quite imagine how one would deal with inconsistency in ASIS, and it seems not terribly interesting, except perhaps to report that "things are inconsistent." Certainly most of the time when you do static analysis, you will want to do it on an internally consistent library. **************************************************************** From: Randy Brukardt Sent: Wednesday, December 10, 2008 9:40 PM > My sense is that GNAT supports having configuration pragmas in a > separate file. It used to always be called "gnat.adc." My recollection (perhaps wrong) is that the Gnat.Adc file contained stuff other than just configuration pragmas. That makes it more like a global project file than a configuration pragma file. > > ... > > No, I was responding to Tucker's "should we go further" and Sergey's > > response to that and his concern about versioning. If we bother > > changing these rules at all, we ought to get them right; just > > getting rid of a restriction to one unit doesn't do much at all in > > that direction. > > I am not an expert on how ASIS deals with inconsistency and versioning > in general, but I don't see the need to make configuration pragmas a > big special case. I really can't quite imagine how one would deal > with inconsistency in ASIS, and it seems not terribly interesting, > except perhaps to report that "things are inconsistent." Certainly > most of the time when you do static analysis, you will want to do it > on an internally consistent library. Because this *is* not a case of inconsistency. This is stuff that the user can manually override, and in many cases it has nothing to do with the canonical semantics of the Ada code. For instance, pragma Suppress just gives a permission to omit checks. Similarly with Restrictions pragmas -- allowing a violation of the restriction in some unit doesn't make any difference to the semantics of the program. (It might cause trouble with a restricted runtime, but that's doesn't seem very interesting for semantic analysis.) We don't currently store *any* pragmas in the program library; they're translated into compiler option settings in the project file. And we don't consider the project file to be part of the library; Janus/Ada has a mode where it will work just fine without such a file. In that case, there is no global context at all; everything depends solely on the compiler options and environment. So I don't see any inconsistency here; the question is whether we could report the interesting information about the settings for each unit through ASIS, or whether we simply have to report "no configuration pragmas" everywhere. (That's surely simpler, but not very useful!) I agree that the scenario that Sergey posited sounds a little weird. Let me posit one that makes much more sense to me. Imagine a project that includes a configuration pragma for pragma Suppress(All_Checks); This will have the effect of including the /YR option in all units currently in the project and also in any units added to the project in the future. Further imagine that the user has manually removed the /YR option from unit B and then compiled the project. If an ASIS program then analyzes unit B from this project, does it see a pragma Suppress(All_Checks);??? If it does, it is actively misleading (because the unit B was compiled without such a pragma), but if it does not, then we effectively have Sergey's versioning problem. (He just described it in Ada language terms of changing the configuration pragmas rather than compiler options.) Now, it surely is the case that the case postulated here is implementation-defined; manually removing the option surely is not contemplated by the Ada standard. But this is a possibility in the real world, and it's a commonly used capability (to give a few units special compilation settings for one reason or another). Indeed, it is easy to imagine a project file that allowed applying one set of configuration pragmas to one unit and automatically applying a different set to other units - that's essentially what manually changing the options does.) The idea that there is a single set of global settings used by everything is archaic at best. Shouldn't ASIS be able to handle such cases? Obviously, it cannot say definitively what it means to have different configuration pragmas for different units, but it surely needs implementation-defined wording somewhere in order to deal with issues like this. Otherwise, ASIS only will work for programs that are *developed* purely according to the Ada Standard, and such programs are pretty rare in practice. (I've never written one outside of ACATS tests, and even there I've used varying sets of options.) **************************************************************** From: Tucker Taft Sent: Wednesday, December 10, 2008 10:50 PM I see no problem in your pretending that each file has its own set of configuration pragmas at the head. You might have to give a bogus source position, but ASIS seems somewhat used to that kind of funny business. But it seems clear to me that you don't really support the pragma-only compilations that the RM talks about. That's fine by me, since you provide other ways to provide defaults, override them, etc. But I don't think you should try to shoe-horn your model into the ASIS support for *global* pragma-only compilations, since you really don't have that. Instead, you support setting an overridable default, which is somewhat different from the effect of a global, pragma-only file. It seems best for your implementation to always report the configuration pragmas as though they appeared at the head of each source file, and not imply there are any library-wide configuration pragmas. **************************************************************** From: Vincent Celier Sent: Wednesday, December 10, 2008 10:42 PM > My recollection (perhaps wrong) is that the Gnat.Adc file contained > stuff other than just configuration pragmas. That makes it more like a > global project file than a configuration pragma file. > Your recollection is indeed wrong: gnat.adc and the other configuration pragmas files specify with switch -gnatec= can only contain configuration pragmas. **************************************************************** From: Pascal Leroy Sent: Thursday, December 11, 2008 12:16 AM > But I don't think ASIS needs to worry about the > situation where the pragma-only units are changed > back and forth between different compilations. > That really isn't the model of pragma-only units. > > The other ones are the "library" configuration > pragmas, and those apply to every compilation > in the library. > > I realize the RM says the configuration pragmas > in a pragma-only compilation apply to "all future" > compilation units, but I had always presumed that > any time you did a "build," you were effectively > recompiling everything in the library needed for > the executable, and thereby whatever was the state > of the pragma-only compilations at that moment > determined the pragmas that applied to the > executable. I don't think that this theory aligns with the IBM implementation, and I believe that Sergey's scenario is valid. In Apex, each view (aka library) can have its own pragmas-only file (named pragma.1.ada). When a (normal) unit is compiled, it uses the configuration pragmas present in all the accessible pragma.1.ada files. These files are subject to incremental compilation, so they can be freely edited and that may or may not cause recompilation. For instance, adding a restriction causes recompilation of the units where this restriction would have been violated, but some other configuration pragmas have no effect until prelink time. At prelink time, a check is made that all the configuration pragmas used to compile all the units in the closure are consistent (note: not identical, consistent). Implementation-wise, each Diana tree contains a summary of the configuration pragmas that were in effect when it was created. I assume that ASIS would use this information to synthetize a snapshot of the pragmas that were in effect when this unit was compiled. The effect would be exactly what Sergey described. **************************************************************** From: Tucker Taft Sent: Thursday, December 11, 2008 2:24 AM It seems that from what you say, however, you could always use the current state of pragma.1.ada and you would get an answer that is consistent with the state of the library. I don't see the need to delve into the history, since clearly upon recompilation from scratch they will all end up with the set represented by the pragma.1.ada. This seems no different than your general incremental compilation approach, where you can probably determine the state of other units at the time you did the original compile, but that is somewhat irrelevant at the time of the ASIS analysis. Presuming that everything is consistent, then what you care about is the current state of the units, not their state at the moment of compile of some dependent unit. **************************************************************** From: Sergey I. Rybin Sent: Thursday, December 11, 2008 3:45 AM Let me try to summarize where we are with this issue. 1. We have agreed that the current ASIS approach used for representing configuration pragmas is too restrictive at least for GNAT and AdaMagic compilers (and probably for IBM Ada compiler as well). 2. An ASIS application may want to now where the given configuration pragma comes from, and there are technical possibilities for these Ada compilers to compute the answer in terms of the (names) of (configuration) files. 3. The notion of a configuration file is completely outside the Ada Standard, it is just a common implementation detail of the Ada compilers under consideration. We may take benefits from the fact that this detail is in common for most of the Ada compilers we have now, but we have to be careful when adding the interface to this common detail at the ASIS Standard level. 4. It is a normal situation when one use different sets of configuration pragmas to compile different units belonging to the same Ada compilation environment (in case of GNAT, you may specify individual set of compilation options for any unit from you project, and these options may include pointers to configuration files to be used when compiling a unit). So, having more then one A_Configuration_Compilation unit in an ASIS Context is also a normal situation, and I do not see any problem with this (except for ASIS implementation problems :( ) 5. Everything looks reasonable and implementable for a typical reasonable set of units that are compiled in some reasonable ways. But there are some corner cases, that may look like some hacker ways of using the underlying compilation system, but that are perfectly legal in Ada sense. The question is - what do we want to do with these corner cases at the level of the ASIS Standard? The example of such a corner case was in my previous message: someone creates Ada sources Ada_Unit_1 and Ada_Unit_2 and a configuration file Ada_Config_File, compiles Ada_Unit_1 with Ada_Config_File, then edits Ada_Config_File and compiles Ada_Unit_2 with the modified version of Ada_Config_File. It is perfectly legal to put these units in the same Ada compilation environment, so ASIS should be able to process a Context based on the results of these compilations. So the question is - how many A_Configuration_Compilation units will we have in this Context, and what should be their properties. I would suggest the following - in this case we have two units of A_Configuration_Compilation kind, for both of them Text_Name returns the same "Ada_Config_File" string, they are different (Is_Equal is False for them), and we may use Asis.Compilation_Units.Times.Time_Of_Last_Update to make the difference between these two versions of configuration files. ****************************************************************