List, Apologies for moving off-topic. The discussion is now moved to be on PM.
Thank you. On Wed, Oct 24, 2012 at 3:39 AM, Simon Slavin <slav...@bigfraud.org> wrote: > > On 24 Oct 2012, at 5:29am, Igor Korot <ikoro...@gmail.com> wrote: > >> It looks like you are "Apple person" that I got suggeted to talk to. ;-) >> The situation is as follows: I am developing an application that will >> utilize not just SQLite but some other library. >> According to the "development standards" on *nix-like systems programs >> should use dynamic linking (use .so), and >> not static linking (not use .a). Since Apple Mac OS X follows *nix, >> this will be the approach. >> According to the same guidelines all those libraries should go to >> /usr/lib (or /usr/local/lib). > > Well, for SQLite the recommendation is that you just compile the .h and .c > SQLite files into your application. Doesn't need a library. And it ensures > that you know which version of SQLite your app is using. > >> Now how else I can place everything in the proper place without >> installer/distribution package? On Mac they have >> dmg extension IIRC. > > For other libraries you want to install, do what I previously described and > include a copy of the library in your application. When the application is > run, it looks for a copy of the library in the right place, and if it doesn't > find one it copies its own copy from its bundle into there. In other words, > your application does its own installation of any support files (including > libraries) that it needs, if they don't already exist. Then, if your > programming language makes it necessary, it restarts itself so it can use > them. > > My /usr/lib folder does have files in. They have '.dylib' extensions, not > .so, except for the PAM stuff which is '.so.2'. I don't know what that means. > >> Now AFAICS, those distribution packages (or dmg) files can be called >> installation packages. > > dmg is a disk image. They can be compressed which makes for smaller > downloads, which is why they're popular. You might distribute your > application, documentation, sample files, etc. all in one disk image. That's > standard. But application installers as separate apps or packages are > frowned on in the Mac community. They're used only when you have a large > suite of applications all of which share common components, e.g. Microsoft > Office, where building support installation logic into each individual > application would be wasteful. > >> This will be one copy for all users. >> The database will be populated originally by me and will be supplied >> alone with the application bundle and those additional library. > > You explained it clearly now. Your application can include a copy of that > file with starter information inside its own bundle. The writable version > belongs in the shared application support folder, which on an English-based > standalone locally-mounted Mac is > > /Library/Application Support/<app name> > > However, there is a system call which use should use to get that path, and > the system call takes into account what your user has named your application, > what language they are using, and whether they have a non-standard setup > which keeps their support files on a network drive or something. So rather > than hardwire this path into your app you should use the system call > > URLsForDirectory:inDomains: > > and feed it > > NSApplicationSupportDirectory > > as described in the 'Locating Items in the Standard Directories' section of > > <https://developer.apple.com/library/mac/documentation/FileManagement/Conceptual/FileSystemProgrammingGUide/AccessingFilesandDirectories/AccessingFilesandDirectories.html#//apple_ref/doc/uid/TP40010672-CH3-SW3> > > Listing 2-1 on that page is a pre-written function you can use to find > exactly that directory we've been discussing. > > Hope this helps. We have drifted far away from matters to do with SQLite, so > if you want to pursue the more Maccish side of this, you might email me > directly. > > 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
