<div dir="ltr">Kenneth,<br><br>I find module_info's {time,CompileTimeAndDate} very useful. At a glance, I can see whether a set of modules that were recently compiled made it to the target platform properly after distribution and installation. Unlike Erlang/OTP itself, the applications I am working with have frequent releases, and sometimes things can go wrong with the distribution mechanism (yes, I know, fix the mechanism, but I still like to have to ability to check). When that happens, I like to be able to look at a beam on the target system and see its compile date and time, and compare it with the known good date and time. A checksum would work just as well for pure comparison purposes but contains less information - a date/time is very human-friendly. The date of the actual beam is, I feel, somewhat more useful (to me, anyway) than the date of the source file, because when I release something I usually rebuild everything from scratch and want to see the <i>build</i> date and time in the beam files, not necessarily the <i>source</i> date and time.<br>
<br>My vote, for what it's worth, is to keep {time,CompileTimeAndDate} and add the compile option to suppress it if it really annoys people.<br><br>By the way, if module_info is documented somewhere, could some kind person please point me to it because I looked for it in the Erlang docs last night and could not find it. Not saying it's not there, just I couldn't find it. It wasn't in the permuted indexes, either.<br>
<br>Regards,<br>Edwin Fine<br><br><div class="gmail_quote">On Tue, Oct 7, 2008 at 1:30 PM, Kenneth Lundin <span dir="ltr"><<a href="mailto:kenneth.lundin@gmail.com">kenneth.lundin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
module_info ought to be documented somewhere, I actually thought it was.<br>
Our general principle is that what is documented is what we support<br>
and keep backwards compatible (as much as possible).<br>
When it comes to the information you can get out from module_info<br>
there are parts that really can be questioned and we<br>
have been thinking of changes although they can be made compatible.<br>
<br>
If we look at M:module_info it returns a list of key value tuples like this:<br>
[<br>
 {exports,ListOfExportedFunctions},<br>
 {imports,ListOfImportedFunctions},<br>
 {attributes,ListOfAttributeValues},<br>
 {compile,ListOfCompileInfo}<br>
]<br>
<br>
where ListOfCompileInfo = [ {options,OptionList},<br>
{version,CompilerVersion},{time,CompileDateAndTime},{source,SourceFilePath}]<br>
<br>
It is the ListOfCompileInfo that in my experience contains<br>
questionable information and that we have plans to change.<br>
For example {time,CompileTimeAndDate} which contains the time when the<br>
compilation was done, this value makes modules (.beam file)<br>
different even if they are compiled from exactly the same sources,<br>
with the same version of the compiler and with the same compiler<br>
options. This is not always a good thing for example if you want to<br>
compare beam files and find out which has changed from one<br>
version of an application to another.<br>
We have thought of 2 alternative solutions. 1) change the time info<br>
from compile time to last modification time of the source file<br>
2) introduce a compiler option which can be used to omit the time info<br>
completely.<br>
<br>
The options info has also been questioned since it has a tendency to<br>
create large volumes of data. For example if a big project passes a<br>
very long and the same list of include directories to every<br>
compilation (even if it is not necessary for that particular file).<br>
Sometimes the volume of the data here will then be significant<br>
compared to the actual code size and the will be kept in RAM by the<br>
Erlang VM.<br>
We have thought of 2 alternative solutions here too: 1) remove all<br>
include paths not used for this file (i.e only keep the ones where<br>
we actually included a file). 2) introduce an option with which the<br>
info can be suppressed.<br>
<br>
<br>
So in summary. The CompileDateAndTime is a little unsafe to rely on<br>
because it might be changed.<br>
<br>
I actually don't understand why you are interested in ?DATE and ?TIME<br>
macros or similar info and I don't see the problem with<br>
passing -DDATE or whatever on the command line to erlc. I am sure it<br>
is possible on WIndows as well (You can as one example<br>
do it with an escript).<br>
<br>
<br>
Even the {source, SourceFilePath } is sometimes totally worthless info<br>
and can also make beam files different even though<br>
they ought to be identical.<br>
<br>
/Kenneth Erlang/OTP team, Ericsson<br>
<div><div></div><div class="Wj3C7c"><br>
<br>
<br>
On Tue, Oct 7, 2008 at 4:32 PM, harry <<a href="mailto:mpharrison@gmail.com">mpharrison@gmail.com</a>> wrote:<br>
> Cheers,<br>
><br>
> I had a dig around in the source in compile, and found some other<br>
> possible tags.<br>
><br>
> But, I wonder, if this is not documented, might it change in the<br>
> future?<br>
><br>
> On Oct 7, 2:31 pm, Mats Cronqvist <<a href="mailto:mats.cronqv...@gmail.com">mats.cronqv...@gmail.com</a>> wrote:<br>
>> harry wrote:<br>
>> > Excellent, thanks!<br>
>><br>
>> > I'm struggling to find docs on module_info.<br>
>> > I'm guessing erlc inserts it into each module<br>
>><br>
>> yes.<br>
>><br>
>> > and it uses beam_lib?<br>
>><br>
>>  afaik, no. it's just a regular exported function that would look<br>
>> something like this in Erlang.<br>
>><br>
>> module_info() -> <list of tagged tuples>.<br>
>> module_info(Tag) -><br>
>>  try proplists:get_value(Tag,module_info())<br>
>>  catch _:_ -> exit(badarg)<br>
>>  end.<br>
>><br>
>>  where <list of tagged tuples> is a constant term.<br>
>>  this is just speculation on my part though.<br>
>><br>
>>   mats<br>
>> _______________________________________________<br>
>> erlang-questions mailing list<br>
>> erlang-questi...@erlang.orghttp://<a href="http://www.erlang.org/mailman/listinfo/erlang-questions" target="_blank">www.erlang.org/mailman/listinfo/erlang-questions</a><br>
> _______________________________________________<br>
> erlang-questions mailing list<br>
> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
> <a href="http://www.erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://www.erlang.org/mailman/listinfo/erlang-questions</a><br>
><br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://www.erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://www.erlang.org/mailman/listinfo/erlang-questions</a><br>
<br>
</div></div></blockquote></div><br></div>