All; When you compile the amalgamation with your source code, doesn't the compiler reject/not include/remove/doesn't consider the code that could have been generated from the actual final build? In other words, if you just have one function being used out of 10,000 functions, the final binary would only include the code for that single function and not the 10,000?
OP; The big question is how much time you want to invest to meet your standards. Seeing that this is a Windows application, not something for a handheld with limited resources, if the above is true, and you "pride" yourself on making your binaries as small as possible, personally, I'd think the 40-80-160 hours investment time to figure out how to get rid of the pure "bloat" the DLL gives a plausible exercise into investigating this, even if its on the side. On top of that, I'm the kind of developer who, if I have to require assistance from an external source, I'll leave it external from my main binary, that way if something does change, like FF in your case, then my application just needs to update a single file, not the entire application. As much as I can appreciate that your program is under 400k (Which I remind you is still smaller than the capacity of a 5 1/4 inch floppy disk, single sided), no user on the planet is going to be concerned that your application "blew up" to 900kb (Which now fits on a double sided 5 1/4 inch floppy). I don't like bloat as much as the next guy, but when you're talking applications the size of a meg, on what seems to be a windows platform, NO ONE is going to notice a performance hit between a 400kb application and a 900kb application. Not to mention bloatware, to me, is more about how fast the system responds. If it takes more than 15 seconds to show your initial UI, or you see elements of your UI just "showing up" randomly, that would be bloat, even if its a 1 meg file. If your application is in line with a "hello world" app, is gigabytes in size, but everything seems to respond nice and quickly, excellent application, not bloat, well worth the download/install time, as an end-user view. Bottom line, how important is [staying close to 400kb and removing external dependencies] vs [having two physical files, in which, one can be updated on the fly (Pending no application use)]? In your testing, if the new DLL breaks, simply fix, and push out a new version. Otherwise, just have your app download the DLL from you or the machine hosting SQLite. The other thing I just thought of, the fact that this library is available AT ALL for better-than-free makes me jump for joy and hit my head on the ceiling. Its a little black box that "works". That 500kb DLL is something I didn't have to write, something that I can review and update if I want. Its something I didn't have to invent, can easily plug into new applications I write, small footprint, etc, etc. Personally, could be 10meg in size, and I'd STILL use it. On Tue, Jun 26, 2012 at 5:39 PM, E. Timothy Uy <t...@loqu8.com> wrote: > " 40-80 hours digging deep into how System.Data.SQLite.dll is built " > > Lol, I actually did this. > > On Tue, Jun 26, 2012 at 11:00 AM, Andrew Rondeau > <andrew.rond...@gmail.com>wrote: > > > The answer of "just add sqlite.c to your project" is great when you're > > making something in C. The entire world does not use C, nor is C (or > > C++) always the best option for a particular project. > > > > Timothy Uy's offer actually makes a lot of sense if you're using > > something other then C or C++. > > > > For example, I just can't ship a .Net .exe that uses x-copy > > deployment, and runs on Linux/Mac (via Mono) unless I invest about > > 40-80 hours digging deep into how System.Data.SQLite.dll is built. > > > > On Tue, Jun 26, 2012 at 9:10 AM, Simon Slavin <slav...@bigfraud.org> > > wrote: > > > > > > On 26 Jun 2012, at 4:55pm, bi...@aol.com wrote: > > > > > >> Thank you everyone who took the time to comment on my Windows DLL > > question. > > >> I'm also glad I'm not the only one who sees the problem with not > having > > >> the version in the resource block. This really would have helped when > > Chrome > > >> and Firefox updated to a new version of SQLite and all my code stopped > > >> working. > > > > > > This is the reason you will see so many posts here telling you to build > > SQLite into your application instead of using a DLL. Then you are not > > subject to the choices of any other person with code on your users' > > computers. SQLite purposely issued a compact and simple amalgamation > > version of the source code especially to make this fast and simple. > > > > > > Simon. > > > _______________________________________________ > > > sqlite-users mailing list > > > sqlite-users@sqlite.org > > > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > _______________________________________________ > > sqlite-users mailing list > > sqlite-users@sqlite.org > > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
