You could create a fake framework, because it takes a while every time to compile.
Just wondering: What's your rationale to use Unicode61 in an iOS project? Being able to sort based on the locale is a feature all our foreign customers demand (and here in German as well). Of course nobody will complain until they realize. ________________________________________ Von: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org] im Auftrag von Josh Wilson [neozenith....@gmail.com] Gesendet: Montag, 16. Juni 2014 04:38 An: sqlite-users@sqlite.org Betreff: Re: [sqlite] Unicode61 Tokenizer Righteo thanks for the sanity check that it must be me at fault and that this is indeed possible without ICU. I have a separate XCode project for rolling the latest SQLite amalgamation and copy that built library out of the Derived Data folder into our main App project. It would appear I kept copying an old file for v3.8.4.3 and not the actual v3.8.5 I was modifying so no wonder there was no change. So after a `Clean` and `Delete Derived Data` then build the resulting build worked. Rookie mistake, sorry guys. I simply followed the ottersoftware approach to adding the defines at the top of the sqlite3.c file after SQLITE_CORE and SQLITE_AMALGAMATION get defined. #define SQLITE_ENABLE_FTS4 #define SQLITE_ENABLE_FTS3_PARENTHESIS #define SQLITE_ENABLE_FTS4_UNICODE61 This worked for me building against the iOS7.1 SDK (including 64bit architecture build) for anyone else's future reference. -- View this message in context: http://sqlite.1065341.n5.nabble.com/Unicode61-Tokenizer-tp76113p76118.html Sent from the SQLite mailing list archive at Nabble.com. _______________________________________________ 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
