A while back now, we added the cut-off scores to the SpectrumSourceFiles table to improve our ability to reproduce creating a .blib file. This should definitely help if the file was built with a Skyline release, since that release if fairly well controlled, and the user records which Skyline release it was.

Hmmm... It would really be nice to record more information about how a library was built, including at least the exact command-line arguments (potentially multiple rows, since a redundant .blib file can be written two multiple times). And also better version information about the version of BlibBuild and/or Skyline that built the library.

We should feel more confident that someone can start from a found .blib file and reproduce it exactly. The recent addition of the search files to SpectrumSourceFiles also helps with this, but we are still missing information.

This could be a little tricky because Skyline's use of BlibBuild has historically used standard input. I changed that to write the standard input to a file and then redirect from the file, but either way the filenames are not passed on the command-line. Should I fudge the standard input into the command-line just to store it in the blib (might run into command-line length limit)? Or make a new column with the contents of the standard input?

I think you could make it two columns:

1. CommandLine
2. FileList

I am not sure it needs to be StdIn if StdIn just contains a file list.

I am more and more feeling like we should be capturing information about any change to all of our files that would allow a user to reproduce those changes. We should also be recording the full version number with Git hash for BlibBuild.exe into the table.