zeek icon indicating copy to clipboard operation
zeek copied to clipboard

Store information about the build during 'make install'

Open timwoj opened this issue 5 years ago • 3 comments

We ran into some issues with the 4.0-RC testing where we were seeing a bug in an install but couldn't actually know what commits the build was based on. Can we add something to the build output, either a text file or an extended --version argument that outputs more information about the source the build was based on? Something like the commit hash of the zeek tree and the submodules?

timwoj avatar Feb 18 '21 19:02 timwoj

Yes, this would be great! We should also cover any built-in plugins (configure --include-plugins=...) in this output, since Zeek packages could then use it to identify resolved dependencies (#2243).

ckreibich avatar Jul 08 '22 00:07 ckreibich

Outputting this in json or something similar would probably be most useful. It being in an easily-parseable format would help zkg determine if something is already installed for dependencies. Something like the below:

{
  "submodules": {"moduleA": {"commit": "abcdef.....", "dirty": False }, ......},
  "included_plugins": ["pluginA", "pluginB"]
}
  • submodules would be a dictionary listing each top-level submodule by name, the current commit hash, and whether or not the directory has local changes
  • included_plugins would be a simple list of the names of the plugins included in the build.

Can anyone think of anything else useful? Maybe some information about the compiler used, the line passed to configure, etc?

timwoj avatar Jul 19 '22 18:07 timwoj

Another possible piece of data would be the VERSION file from any of the submodules, if one exists. The only problem I see with the submodule data I suggested previously is that we eat all of the git data when we build the release tarballs, so all of that commit/dirty information is lost.

timwoj avatar Jul 20 '22 23:07 timwoj

Another possible piece of data would be the VERSION file from any of the submodules, if one exists. The only problem I see with the submodule data I suggested previously is that we eat all of the git data when we build the release tarballs, so all of that commit/dirty information is lost.

Uhm, good point. I guess non-git workflows exist.

If it has been built from a tarball, maybe that info is sufficient as we should know what was package.

awelzel avatar Feb 09 '23 15:02 awelzel