Capture build log in package

[rconde01]

I originally brought this up in #814 but now looking at the proposed solution #884 it is not what I expected. The idea was to automatically include the log in the package so that if you go to look at your package and something seems wrong (or you just want to confirm something), you can look at the log to get some insight. In other words, it gives you some traceability into how the package was created. Maybe the package build uses a tool (e.g. Cmake) and the log let's you know what version of cmake was used to build the package. Or a specific version of a compiler (where maybe the profile isn't as specific as you want to know).

[jgsogo]

Hi @rconde01! One of the main issues about including a log file into the package is that it will be considered part of the package and it will be taken into account to compute its hash. So, any change to this logfile will create a different package... I find it quite difficult to include this functionality into Conan.

Nevertheless, some versions ago, we implemented hooks, they allow the user to plug-in some behavior at certain points. Using hooks, you can add a file (the trace file) to your package in the pre_package function, but take into account that this file (its contents), will affect the package itself.

[rconde01]

Hi! I'm trying to think this through a bit:

• It's unclear to me when the hash is computed. If the hash is computed during the log, then perhaps I see an issue because there's an infinite recursion there (although maybe you only capture the log up until the time it calculates the hash...that would be an acceptable limitation IMO)
• Otherwise, I don't think the inclusion of the log changing the hash of the package is an issue in particular. Presumably, for a package including binaries anyhow, the package would not be unique regardless. Am I missing something (probably :P)?

[jgsogo]

As Conan is implemented right now (taking into account compatibility with previous versions) that file should be inside the tar.gz file, it should appear in the manifest and it will affect the hash of the package. We cannot change this behavior without breaking old clients.

The problem with different hashes depends on who/where/how that log file is generated. If it is the CONAN_TRACE_FILE it will be modified by other processes or Conan commands and each time there will be a different hash, even though the package hasn't been modified...

Other approaches:

• Generate that file with relevant information inside the recipe or with a hook, and control what it is in that file (not a log but a set of key-value pairs).
• Use Conan to package your tools too, use the build_requires to retrieve the cmake_installer or compiler you want to use to build the recipe or any other tool that could affect your build.

[rconde01]

different hash, even though the package hasn't been modified...

Won't that be true in general for any packages containing built binaries? I.e. the binaries contain meta data like the build time etc. which would cause a change?

[jgsogo]

Yes, you are right, it is not an argument against it.

Implementing something like this will require piping all the outputs related to one package (Conan output and subprocesses ones) to a common place and then write it down into a file that will be stored within the package. For sure the CONAN_TRACE_FILE cannot be the source of information because it contains unrelated information and maybe mixed one (if some Conan commands run in parallel for different recipes). It looks like a middle-complex feature, but if we agree on it, it is doable (I'm marking this one to discuss it with the team).

Nevertheless, if you want to track your tools versions, the best you can do is packaging those tools too. I know it is orthogonal answer related to the log file one, but it could give you fully reproducible packages.

[rconde01]

Ok - thanks for the thoughts! Yes, I agree if you very specifically want to get the tools versions then there are other reasonable/better ways to accomplish that. But I still think there's a general value to capturing that build log as well.

[memsharded]

This has been implemented already in Conan 2.0.7 in the "metadata" (still not documented) and will be finalized and released in 2.0.8 (#14152)