Cannot archive app with TouchDB-iOS

[Pulkit Singhal]

It may something to do with the new Xcode version, I was wondering if anyone else is facing a similar error when attempting to archive an app for submission toto the app store:
error: /Users/myusername/dev/myprojname/./DerivedData/myprojname/Build/Products/Debug-ios-universal/TouchDB.framework: No such file or directory

Is there a workaround?

Thanks!
- Pulkit

[Jens Alfke]

On May 15, 2013, at 9:48 PM, Pulkit Singhal <pulkit...@gmail.com> wrote:

> It may something to do with the new Xcode version, I was wondering if anyone else is facing a similar error when attempting to archive an app for submission toto the app store:

I haven’t seen that error before.

> error: /Users/myusername/dev/myprojname/./DerivedData/myprojname/Build/Products/Debug-ios-universal/TouchDB.framework: No such file or directory

From the path it looks like your project is building TouchDB, not just linking in a .framework?

Have you tried cleaning all targets, deleting the build directories, etc?

—Jens

[Pulkit Singhal]

I did try that but I seem to have gotten into a strange funk which was only cleared by resetting my pbxproj file against previous commits from git.

Works now. Thanks!

--
You received this message because you are subscribed to the Google Groups "Mobile Couchbase" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mobile-couchba...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Pulkit Singhal]

It seems like there are two issues:

a) one it has something to do with the new xcode version ... earlier it used to create "relative" builds in "deriveddata" directory for submodules like TouchDB here:
./DerivedData/myprojname/Build/Products/Debug-ios-universal/TouchDB.framework
but now it creates builds within a "derivedata" directory inside the submodule itself:
./TouchDB-iOS/DerivedData/TouchDB/Build/Products/Debug-ios-universal/TouchDB.framework

b) second problem has to do with the fact that there is a symlink inside the framework, which may or may not have always been there ... but now Apple validation check complains about it:
$ cd ./TouchDB-iOS/DerivedData/TouchDB/Build/Products/Debug-ios-universal/TouchDB.framework
$ ls -alrt
total 16376
drwxr-xr-x   4 pulkitsinghal  staff      136 Jan 24 05:58 ..
-rw-r--r--   1 pulkitsinghal  staff      680 Apr 16 13:45 Info.plist
drwxr-xr-x  31 pulkitsinghal  staff     1054 Apr 16 13:45 Headers
-rwxr-xr-x   1 pulkitsinghal  staff  8364092 Apr 16 14:21 TouchDB
lrwxr-xr-x   1 pulkitsinghal  staff       17 May 20 15:19 TouchDB.framework -> TouchDB.framework
drwxr-xr-x   7 pulkitsinghal  staff      238 May 20 15:19 .

I just used the "show package contents" option to go inside and locate it in the archive packaging being submitted to the app store ... and manually removed it ... not sure what the elegant way to fix this would be for those of us who build off the source code for touchdb everytime ... instead of simply the binary file downloads.

- Pulkit

On Wednesday, May 15, 2013 11:48:24 PM UTC-5, Pulkit Singhal wrote:

It may something to do with the new Xcode version, I was wondering if anyone else is facing a similar error when attempting to archive an app for submission to the app store:

[Jens Alfke]

On May 20, 2013, at 2:09 PM, Pulkit Singhal <pulkit...@gmail.com> wrote:

a) one it has something to do with the new xcode version ... earlier it used to create "relative" builds in "deriveddata" directory for submodules like TouchDB here:
./DerivedData/myprojname/Build/Products/Debug-ios-universal/TouchDB.framework
but now it creates builds within a "derivedata" directory inside the submodule itself:
./TouchDB-iOS/DerivedData/TouchDB/Build/Products/Debug-ios-universal/TouchDB.framework

I can well believe that this could change from one version of Xcode to another. The layout of stuff in the build directories is internal to Xcode, not something that’s supposed to be stable.

The only safe way to locate directories in there is to use the environment variables (like $TARGET_BUILD_DIR) in build scripts.

b) second problem has to do with the fact that there is a symlink inside the framework, which may or may not have always been there ... but now Apple validation check complains about it:

The symlink is definitely wrong. I looked inside my build directory and I don’t have one. After you deleted it, did it reappear on the next build?

(BTW, you should probably be using the Release builds, not Debug.)

—Jens