On 11.04.24 10:51, Dominique Devienne via Boost wrote:
On Thu, Apr 11, 2024 at 10:49 AM Dominique Devienne
wrote: On Wed, Apr 10, 2024 at 10:11 PM Rainer Deyke via Boost < boost@lists.boost.org> wrote:
- Build configurations appear to be stored in a sqlite database, not in a readable and editable text file.
Some would argue that's a positive. There are tons of GUI SQLite "viewers". A structured normalized data-model for build configuration sounds good to me (haven't looked at this particular one though) If you want text, you can also "dump" the SQL or CSV of the tables using a sqlite3 1-liner, or used sqlite3 to SELECT the subset you want. But I get the resistance to non-text too. Perhaps Boris has an alternate text-form? --DD
From https://www.loc.gov/preservation/digital/formats/fdd/fdd000461.shtml
The Library of Congress Recommended Formats Statement (RFS) includes SQLite as a preferred format for datasets https://www.loc.gov/preservation/resources/rfs/data.html
Also, it's a bit ironic you complain about SQLite use, when your SCM of choice, Fossil, *is* SQLite-based, from the SQLite author no less! :) --DD
The difference is that I don't want to hand-edit my version history, but I do want to hand-edit my build configurations. Going through the command line for the latter seems like an unnecessary redirection when it comes to copying build configurations from project to project. (Imagine a dozen projects with a dozen build configurations each that all need an additional command line parameter because a common dependency has changed its requirements.) I have nothing against sqlite per se. It's a great tool. I just don't think it's the right tool in this specific case. -- Rainer Deyke (rainerd@eldwood.com)