On 22 December 2017 at 23:57, Michael Tiernan <michael.tier...@gmail.com> wrote:
> > > It just doesn’t install to a directory it can’t write to, because you > > told it to install system-level things. > > Not going to hash it out here but I didn't tell it to install system-level > things, I told it to compile and install everything locally. Just like I do > with lots of other source packages especially when I'm not very familiar > with the software and wish to make sure of what I'm doing before committing > it to the system. > How is the build system supposed to differentiate "local" vs "system-level"? It's obvious from your perspective, but --prefix does not clearly disambiguate between the two; it's also used for system-level builds. Eg. --prefix=/opt or --prefix=/usr (for package maintainers). AFAIK there's no standard way to tell configure to avoid touching any system-level dirs. If you want to know what an unfamiliar package is going to do before the fact your best bet is `make -n install`, or `make DESTDIR=/tmp/foo install` if the package supports staged installs (sqlite does, probably most autoconf projects do). The tests rely on tcl, but they run here without installing the tcl extension so not sure what's going wrong in your situation. They run on a DB in the current directory, so maybe related to you running under a dropbox vfs (which I don't know if implements properly locking?). Dunno about OSX either; do you have tcl installed there? -Rowan _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
