[erlang-questions] ?DATE and ?TIME MACROs

[Edwin Fine]

Kenneth,

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 *build* date and time in
the beam files, not necessarily the *source* date and time.

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.

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.

Regards,
Edwin Fine

On Tue, Oct 7, 2008 at 1:30 PM, Kenneth Lundin <kenneth.lundin@REDACTED>wrote:

> 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
> >
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20081007/2c344779/attachment.htm>