[erlang-questions] ?DATE and ?TIME MACROs

Kenneth Lundin kenneth.lundin@REDACTED
Tue Oct 7 19:30:50 CEST 2008


module_info ought to be documented somewhere, I actually thought it was.
Our general principle is that what is documented is what we support
and keep backwards compatible (as much as possible).
When it comes to the information you can get out from module_info
there are parts that really can be questioned and we
have been thinking of changes although they can be made compatible.

If we look at M:module_info it returns a list of key value tuples like this:
[
 {exports,ListOfExportedFunctions},
 {imports,ListOfImportedFunctions},
 {attributes,ListOfAttributeValues},
 {compile,ListOfCompileInfo}
]

where ListOfCompileInfo = [ {options,OptionList},
{version,CompilerVersion},{time,CompileDateAndTime},{source,SourceFilePath}]

It is the ListOfCompileInfo that in my experience contains
questionable information and that we have plans to change.
For example {time,CompileTimeAndDate} which contains the time when the
compilation was done, this value makes modules (.beam file)
different even if they are compiled from exactly the same sources,
with the same version of the compiler and with the same compiler
options. This is not always a good thing for example if you want to
compare beam files and find out which has changed from one
version of an application to another.
We have thought of 2 alternative solutions. 1) change the time info
from compile time to last modification time of the source file
2) introduce a compiler option which can be used to omit the time info
completely.

The options info has also been questioned since it has a tendency to
create large volumes of data. For example if a big project passes a
very long and the same list of include directories to every
compilation (even if it is not necessary for that particular file).
Sometimes the volume of the data here will then be significant
compared to the actual code size and the will be kept in RAM by the
Erlang VM.
We have thought of 2 alternative solutions here too: 1) remove all
include paths not used for this file (i.e only keep the ones where
we actually included a file). 2) introduce an option with which the
info can be suppressed.


So in summary. The CompileDateAndTime is a little unsafe to rely on
because it might be changed.

I actually don't understand why you are interested in ?DATE and ?TIME
macros or similar info and I don't see the problem with
passing -DDATE or whatever on the command line to erlc. I am sure it
is possible on WIndows as well (You can as one example
do it with an escript).


Even the {source, SourceFilePath } is sometimes totally worthless info
and can also make beam files different even though
they ought to be identical.

/Kenneth Erlang/OTP team, Ericsson



On Tue, Oct 7, 2008 at 4:32 PM, harry <mpharrison@REDACTED> wrote:
> Cheers,
>
> I had a dig around in the source in compile, and found some other
> possible tags.
>
> But, I wonder, if this is not documented, might it change in the
> future?
>
> On Oct 7, 2:31 pm, Mats Cronqvist <mats.cronqv...@REDACTED> wrote:
>> harry wrote:
>> > Excellent, thanks!
>>
>> > I'm struggling to find docs on module_info.
>> > I'm guessing erlc inserts it into each module
>>
>> yes.
>>
>> > and it uses beam_lib?
>>
>>  afaik, no. it's just a regular exported function that would look
>> something like this in Erlang.
>>
>> module_info() -> <list of tagged tuples>.
>> module_info(Tag) ->
>>  try proplists:get_value(Tag,module_info())
>>  catch _:_ -> exit(badarg)
>>  end.
>>
>>  where <list of tagged tuples> is a constant term.
>>  this is just speculation on my part though.
>>
>>   mats
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questi...@REDACTED://www.erlang.org/mailman/listinfo/erlang-questions
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>



More information about the erlang-questions mailing list