Re: Xcode Build Location
There are two more of these groups created Jens that you may find helpful. xc...@apple-dev.groups.io co...@apple-dev.groups.io > On May 15, 2020, at 2:18 PM, Richard Charles via Cocoa-dev > wrote: > > Thanks to everyone for your comments and suggestions. > > I now have my app with embedded frameworks working as multiple individual > projects or combined into a single workspace. It all works in Xcode 9 or 11 > and archiving also works. The app was successfully notarized by Apple. > > There is actually an informative technical note on the subject. > > https://developer.apple.com/library/archive/technotes/tn2435/_index.html > > I appreciate the list responding to an Xcode question. The xcode-users list > has been shut down and I have yet to acquire a taste for the new apple-dev > groups. > > Thanks again. > > --Richard Charles > > > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com > > This email sent to z...@mac.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Xcode Build Location
Thanks to everyone for your comments and suggestions. I now have my app with embedded frameworks working as multiple individual projects or combined into a single workspace. It all works in Xcode 9 or 11 and archiving also works. The app was successfully notarized by Apple. There is actually an informative technical note on the subject. https://developer.apple.com/library/archive/technotes/tn2435/_index.html I appreciate the list responding to an Xcode question. The xcode-users list has been shut down and I have yet to acquire a taste for the new apple-dev groups. Thanks again. --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Xcode Build Location
Richard, > On May 8, 2020, at 10:16, Steve Mills via Cocoa-dev > wrote: > > On May 8, 2020, at 09:08:17, Richard Charles via Cocoa-dev > wrote: >> >> Some of the dynamically linked libraries are large. If they are put in a >> workspace with the main project then it is so large it becomes cumbersome to >> work with. >> >> One library has over 1,100 source files. Using a workspace for this >> collection of projects on a daily basis is not fun at all. It is actually >> counter productive. > > I have a feeling you're misunderstanding workspaces. You keep all the > projects in their own projects, but you simply add each project to the > workspace. The projects still manage the individual subproject files. We have a ton of source files, 6 or more frameworks, 15+ apps/targets, use one Workspace for all of these, and have Xcode set to use legacy build locations (which is the build directory within the project directory). This setup is quite responsive and intelligently builds only what is necessary based on ‘what is dirty’. This is on Xcode 9.4.1 (I know, 9.X, I’m working on it, haha) But either your codebase significantly larger or more complicated, or something else is going on. I hope you can get workspaces… well… working. They have been an improvement for us in many ways. Sandor > >> So maybe I have answered my own question. The string appears to remain >> constant as long as the project name and enclosing folder remain unchanged. >> So perhaps there is nothing to be afraid of here with regards to this string >> being part of a link path during build. > > Yes, don't worry about any folder names Xcode creates when you let it manage > the build location. It won't be part of any paths written to final frameworks > or anything like that. Xcode knows what it's doing. > > BTW, this discussion should really be in the xcode-users list, or better yet > in the newer xcode list at apple-dev.groups.io. > > -- > Steve Mills > Drummer, Mac geek > > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/admin.szatmari.net%40gmail.com > > This email sent to admin.szatmari@gmail.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Xcode Build Location
On May 8, 2020, at 09:08:17, Richard Charles via Cocoa-dev wrote: > > Some of the dynamically linked libraries are large. If they are put in a > workspace with the main project then it is so large it becomes cumbersome to > work with. > > One library has over 1,100 source files. Using a workspace for this > collection of projects on a daily basis is not fun at all. It is actually > counter productive. I have a feeling you're misunderstanding workspaces. You keep all the projects in their own projects, but you simply add each project to the workspace. The projects still manage the individual subproject files. > So maybe I have answered my own question. The string appears to remain > constant as long as the project name and enclosing folder remain unchanged. > So perhaps there is nothing to be afraid of here with regards to this string > being part of a link path during build. Yes, don't worry about any folder names Xcode creates when you let it manage the build location. It won't be part of any paths written to final frameworks or anything like that. Xcode knows what it's doing. BTW, this discussion should really be in the xcode-users list, or better yet in the newer xcode list at apple-dev.groups.io. -- Steve Mills Drummer, Mac geek ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Xcode Build Location
> On May 7, 2020, at 10:04 PM, Rob Petrovec wrote: > > Have you considered using a workspace to handle building all of your > individual projects? That should solve your file path & linking problem. > Some of the dynamically linked libraries are large. If they are put in a workspace with the main project then it is so large it becomes cumbersome to work with. One library has over 1,100 source files. Using a workspace for this collection of projects on a daily basis is not fun at all. It is actually counter productive. > > btw, the 28 character string is a UUID. I’m not sure about its lifetime. > I don’t think these are a UUID. If a project is moved to another computer it has the same string appended to the project name in the build folder. If the build location is changed in Xcode preferences the appended string remains the same. The string does change if the name of the project enclosing folder is changed. So maybe I have answered my own question. The string appears to remain constant as long as the project name and enclosing folder remain unchanged. So perhaps there is nothing to be afraid of here with regards to this string being part of a link path during build. --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Xcode Build Location
Have you considered using a workspace to handle building all of your individual projects? That should solve your file path & linking problem. btw, the 28 character string is a UUID. I’m not sure about its lifetime. —Rob > On May 7, 2020, at 9:57 PM, Richard Charles via Cocoa-dev > wrote: > > I have a project that has several large dynamically linked libraries which > are located in the application bundle. Each linked library is a separate > project. > > The setting in Xcode > Preferences > Locations > Advanced > Build Location is > set to use Shared Folder > Build. Historically has worked well but now with > Xcode 11 there are some drawbacks. For example Clean Build Folder cleans the > entire shared build folder not just the target. Also archiving has never > worked and still does not work with this configuration. > > So now I have changed the Xcode setting from Shared Folder to Unique which > apparently is the default. > > When using the Unique setting a 28 character string is appended to the > project name in DerivedData. The string appears to be random characters but > most likely is not. > > During build when linking to the dynamic libraries this 28 character string > is in the file path. So if it ever changes then linking will fail. > > So my question is will this 28 character unique string always remain constant > for a given project? > > Any insight would be appreciated. > > --Richard Charles > > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com > > This email sent to petr...@mac.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Xcode Build Location
I have a project that has several large dynamically linked libraries which are located in the application bundle. Each linked library is a separate project. The setting in Xcode > Preferences > Locations > Advanced > Build Location is set to use Shared Folder > Build. Historically has worked well but now with Xcode 11 there are some drawbacks. For example Clean Build Folder cleans the entire shared build folder not just the target. Also archiving has never worked and still does not work with this configuration. So now I have changed the Xcode setting from Shared Folder to Unique which apparently is the default. When using the Unique setting a 28 character string is appended to the project name in DerivedData. The string appears to be random characters but most likely is not. During build when linking to the dynamic libraries this 28 character string is in the file path. So if it ever changes then linking will fail. So my question is will this 28 character unique string always remain constant for a given project? Any insight would be appreciated. --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
