On 06/06/18 09:24, Bob Friesenhahn wrote: > A local tool which makes it easy to configure sqlite from local files > sounds useful ...
It already exists. It is what the SQLite team uses to produce the amalgamations etc, and is part of the SQLite code base. > but depending on a "web site" (baby-bird model) ... Note that behind the scenes the existing tools would be used with the relevant results zipped up and downloadable. No one is advocating getting rid of the command line tools, just a web front end. > There is already far too much dependence on what what > happens to get served up at the time and too much dependence on a live > connection to the "Internet" ... You and Warren comprehensively describe best practises and why. You are both right. It is what developers *should* do for repeatable reliable builds. But it is a lot of friction. And not every developer follows best practise. And developers start out investigating and playing around with potential solutions, and then adopt the appropriate ones. If you are trying out a "hello world" quick test, then the best practises are a lot of friction, and a few web page tickboxes are the least. The more friction there is, the fewer people will try non-default configurations. But that also locks SQLite into a pessimistic legacy configuration going forward. For example default enabling STAT4 or disabling deprecated API could not be done, ever. Roger
signature.asc
Description: OpenPGP digital signature
_______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
