Thanks, it does. I'm working under the Win7/64 environment doing the builds using the C++ Builder from Bloodshed, but I do speak Linux, so I can follow along with what you're saying here.
I've found "fuel" and playing around with that to see if I can go back into history instead of downloading the packages. This repo is a little bit different from what I'm used to (But so is git and svn, and I'm just beginning to wrap my head around those two) so I'm seeing if I can get fuel to put those two files back in history so I can recompile. If I come up with a procedure, I can turn off the script. :] On Tue, Sep 29, 2015 at 3:51 AM, Kees Nuyt <k.nuyt at zonnet.nl> wrote: > On Tue, 29 Sep 2015 02:01:03 -0400, Stephen Chrzanowski > <pontiac76 at gmail.com> wrote: > > > For the past year, I've had a script that runs daily that reads all the > > links off of http://sqlite.org/download.html and downloads anything > that is > > missing. It has been a long while since I've looked at this particular > > section of my NAS, but thought I'd bring my repositories up to snuff, and > > build my own DLLs against each revision posted again. (So, yes, Richard, > > as a prank, you could slap a 1tb garbage file up and my script would > > dutifully download it.... My ISP would LOVE more of my money) > > > > First, I noticed that there hasn't been anything posted new for the > > amalgamation a long while (July 30 for 3.08.11.01 according to my file > > systems time stamp), so thinking that my script broke for whatever > reason, > > curiosity bit me. I checked the download site and no, things seem to be > > working. So a testament to stability, both for the code, and > surprisingly > > for my script!! > > > > Second, I noticed that on the download page itself TODAY has no reference > > to files named "sqlite-amalgamation-YYYYMMDDHHmm.zip" yet I have a bunch > of > > them in my archives. Are these the files put up for the purpose of the > > pre-releases of a finalized build and my script is working better than > > expected??? (I might get the script to filter those files out, but being > a > > digital file packrat....) > > > > Third, I don't know if it is something that can be done now, but I've > > noticed that on a very few of these downloads, I'm getting file sizes in > > the 5kb range. Looking at the raw bytes of the zip file in a text editor > > is a bit strange, but it looks like the .zip file was downloaded as an > HTML > > file. (As in, rename the zip file to .TXT and open up in notepad, kinda > > raw content). I'm thinking that the web server didn't find the file > when I > > requested so just spit out the page. > > > > Fourth, a little bit of hand-holding might be needed, but do the zipped > > archives of the released amalgamations (Not the dated files) exist on the > > web server somewhere, or can I get the zip from the SQlite repo? If only > > from the repo, where can I get either the .c/.h or .zip file for older > > versions? (Just in case I miss a revision in the future because of that > > 5kb thing) -- Maybe because of that 5kb thing I should write into my > script > > that any zip file that is less than 100kb should be just flat out > deleted. > > I'm a somewhat interested in getting older versions for the sake of just > > having them, and going back to them in case I want/need them. > > By far the easiest way to follow revisions and build older > versions is to follow the repository, which is managed by > fossil. > http://fossil-scm.org/index.html/doc/trunk/www/quickstart.wiki > > Clone the repository using fossil: > fossil clone http://www.sqlite.org/cgi/src \ > ~/var/fossil/repo/sqlite3.fossil > > Open a checkout in a dedicated directory: > mkdir -p ~/src/sqlite3 # once > cd ~/src/sqlite3 > fossil open ~/var/fossil/repo/sqlite3.fossil trunk > > Update it periodically: > cd ~/src/sqlite3 > fossil pull > > and update the checkout: > cd ~/src/sqlite3 > fossil update trunk # or any other point on the timeline > > Building the amalgamation is a matter of: > mkdir -p ~/bld/sqlite3 # once > cd ~/bld/sqlite3 > ./configure [ options ] > > Then you can i.e. build the command line tool > and sqlite3_analyzer: > cd ~/bld/sqlite3 > make clean > make sqlite3.c > make tclsqlite3.c > gcc ${CFLAGS} -o sqlite3 sqlite3.c \ > ../../src/sqlite3/src/shell.c > make sqlite3_analyzer > > Your build can grab the version in the > generated sqlite3.h in the build directory: > #define SQLITE_VERSION "3.8.12" > #define SQLITE_VERSION_NUMBER 3008012 > #define SQLITE_SOURCE_ID "2015-09-26 17:44:59 > 33404b2029120d4aabe1e25d484871810777e934" > > Hope this helps. > > -- > Regards, > Kees Nuyt > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >
