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
