[erlang-questions] ?DATE and ?TIME MACROs

[harry]

the only reference I could find was in the page for xref, and it
doesn't say a whole lot,
apart from saying the compiler inserts the function.


On Oct 7, 9:46 pm, "Edwin Fine" <erlang-questions_ef...@REDACTED>
wrote:
> 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.lun...@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 <mpharri...@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-questi...@REDACTED
> > >http://www.erlang.org/mailman/listinfo/erlang-questions
>
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questi...@REDACTED
> >http://www.erlang.org/mailman/listinfo/erlang-questions
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questi...@REDACTED://www.erlang.org/mailman/listinfo/erlang-questions