Re: On Boost and modules

From: Rainer Deyke (rdeyke_at_[hidden])
Date: 2024-04-11 09:21:10

On 11.04.24 10:51, Dominique Devienne via Boost wrote:
> On Thu, Apr 11, 2024 at 10:49 AM Dominique Devienne <ddevienne_at_[hidden]>
> wrote:
> 
>> On Wed, Apr 10, 2024 at 10:11 PM Rainer Deyke via Boost <
>> boost_at_[hidden]> 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_at_[hidden])