Re: Concurrent loading of images ?
On May 8, 2020, at 6:00 PM, Gabriel Zachmann via Cocoa-dev wrote: > >> Sure. Just be aware that if you're using NSImage, simply loading an NSImage >> does not rasterize it; the class tries to be 'lazy' about doing work. So >> your background task should explicitly render it, e.g. into an >> NSBitmapImageRep. > > I am using CGImageSourceCreateImageAtIndex and related functions. > But I am still unclear which function actually takes the time. > Maybe it is only when I create the CALayer like this? > > CALayer * imgLayer= [CALayer layer]; > imgLayer.contents = nsimage; Reading a 50MB image will definitely take some time, so preloading the image will definitely help. I’ve usually used an NSOperationQueue but my apps working with images can sometimes be loading hundreds of images and NSOperationQueue has an option to limit the number of operations run concurrently. Since you’ll only be loading the next image then a single GCD dispatch would work just as well. Also, if you’re already getting a CGImageRef using CGImageSourceCreateImageAtIndex, why not just set imgLayer.contents to the CGImageRef? Jim Crate ___ 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: Concurrent loading of images ?
Using a queue is part of GCD. You should probably not use the main queue since
that is analogous to the main thread and the main thread is meant for updating
the UI.
The good thing here is that you can sort of preload the next image in a queue
after your last one has displayed.
With a dispatchQueue, the idea here is that you have lots of tasks that you
want to get done and you want the previous task to complete, then start the
next one and so on and so on. You probably don’t need to do that for this
application.
If I were doing this in Objective-C, I’d fire off a “preload” on an async
dispatch to a block. Something like this.
// create a queue to load the image
dispatch_group_t d_group = dispatch_group_create();
dispatch_queue_t bg_queue =
dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
dispatch_group_async(d_group, bg_queue, ^{
NSLog(@“preloading");
Do that image loading here
});
If you did want to do something on the main queue, you can do it like this.
dispatch_async(dispatch_get_main_queue(), ^{
Do your main thread updates here
}
If you want to use a serial queue that doesn’t block the main thread you can do
it like this.
// Dispatch the rest of session setup to the sessionQueue so that the main
queue isn't blocked.
dispatch_queue_t sessionQueue = dispatch_queue_create("session queue",
DISPATCH_QUEUE_SERIAL);
[self setSessionQueue:sessionQueue];
dispatch_async(sessionQueue, ^{
Do stuff here, but you want to read up on dipatch queues to see the
best approach.
}
There’s lots of fun that you can have using these queues and GCD. The trick is
finding the approaches that suit your needs.
Hope these help.
> On May 8, 2020, at 4:53 PM, Gabriel Zachmann via Cocoa-dev
> wrote:
>
>> I second the use of GCD. Its also considerably simpler than NSThread,
>> NSOperationQueue/NSOperation et al. This is the kind of operation that GCD
>> was invented for.
>
> Thanks a lot for your response(s).
>
> To me a queue suggests that you have lots and lots of tasks arriving from the
> producer , which you need to buffer in queue, so that the consumer can work
> on it one task at a time.
>
> But in my case, I really have just one task, so the queue would - at most -
> contain one task at a time.
> So, why not start the task right away using NSThread or NSOperation?
>
>
> ___
>
> 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: Concurrent loading of images ?
> On May 8, 2020, at 15:13, Rob Petrovec via Cocoa-dev > wrote: > > > >>> On May 8, 2020, at 12:19 PM, Jens Alfke via Cocoa-dev >>> wrote: >>> >>> >>> On May 8, 2020, at 9:53 AM, Gabriel Zachmann via Cocoa-dev wrote: >>> >>> So, I was thinking, maybe it helps to load the next image concurrently, >>> while the current one is still being displayed. >> >> Sure. Just be aware that if you're using NSImage, simply loading an NSImage >> does not rasterize it; the class tries to be 'lazy' about doing work. So >> your background task should explicitly render it, e.g. into an >> NSBitmapImageRep. >> >>> I also read about the GCD's dispatch queues, but it seems to me that this >>> would not be the suitable approach since I always only have one task >>> running concurrently to the main thread. >> >> Why not? Dispatch queues are always available. (The main thread is simply a >> special queue.) You can run the background task by creating a single >> dispatch queue and then using dispatch_async to call a block that does the >> work. The end of the block would call dispatch_async back to the main queue >> and pass the image as a parameter. >I second the use of GCD. Its also considerably simpler than NSThread, > NSOperationQueue/NSOperation et al. This is the kind of operation that GCD > was invented for. I would add, that for a long running process, open ended work, or task, I would favor a thread. But for short and finite items I would favor GCD/NSOperationQueue. Are you going to only load one image, the next image, in this concurrent loading scenario? Or, will you be loading many images and caching them? I would imaging looking one or two ahead would be the choice. I’m just trying to understand the need/use case. If there’s lots of overhead that can be reduced to a one time effort than maybe a thread is better. If not maybe a one-off throw-it-in-a-queue and be done with it approach is better? Sandor > > —Rob > > > ___ > > 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: Concurrent loading of images ?
> Sure. Just be aware that if you're using NSImage, simply loading an NSImage > does not rasterize it; the class tries to be 'lazy' about doing work. So your > background task should explicitly render it, e.g. into an NSBitmapImageRep. I am using CGImageSourceCreateImageAtIndex and related functions. But I am still unclear which function actually takes the time. Maybe it is only when I create the CALayer like this? CALayer * imgLayer= [CALayer layer]; imgLayer.contents = nsimage; > > Why not? Dispatch queues are always available. (The main thread is simply a > special queue.) You can run the background task by creating a single dispatch > queue and then using dispatch_async to call a block that does the work. The > end of the block would call dispatch_async back to the main queue and pass > the image as a parameter. Could you give a few more specific hints? Best regards, Gabriel ___ 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: Concurrent loading of images ?
> I second the use of GCD. Its also considerably simpler than NSThread, > NSOperationQueue/NSOperation et al. This is the kind of operation that GCD > was invented for. Thanks a lot for your response(s). To me a queue suggests that you have lots and lots of tasks arriving from the producer , which you need to buffer in queue, so that the consumer can work on it one task at a time. But in my case, I really have just one task, so the queue would - at most - contain one task at a time. So, why not start the task right away using NSThread or NSOperation? ___ 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: Concurrent loading of images?
> I also read about the GCD's dispatch queues, but it seems to me that this would not be the suitable approach since I always only have one task running concurrently to the main thread. > > Why not? Dispatch queues are always available. (The main thread is simply > a special queue.) You can run the background task by creating a single > dispatch queue and then using dispatch_async to call a block that does the > work. The end of the block would call dispatch_async back to the main queue > and pass the image as a parameter. I could not agree more with Jens. Great Central Dispatch has been a big boon. Before GCD, I would not touch multithreaded code with a ten-foot pole. Now I use it everyday and I can increase responsiveness as never before. I would definitely take a look at it. You can load images with a background thread and then when the loading is done you can dispatch it to the main queue for display. It has never been so easy to do that. João > > ___ 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: Concurrent loading of images ?
> On May 8, 2020, at 12:19 PM, Jens Alfke via Cocoa-dev > wrote: > > > >> On May 8, 2020, at 9:53 AM, Gabriel Zachmann via Cocoa-dev >> wrote: >> >> So, I was thinking, maybe it helps to load the next image concurrently, >> while the current one is still being displayed. > > Sure. Just be aware that if you're using NSImage, simply loading an NSImage > does not rasterize it; the class tries to be 'lazy' about doing work. So your > background task should explicitly render it, e.g. into an NSBitmapImageRep. > >> I also read about the GCD's dispatch queues, but it seems to me that this >> would not be the suitable approach since I always only have one task running >> concurrently to the main thread. > > Why not? Dispatch queues are always available. (The main thread is simply a > special queue.) You can run the background task by creating a single dispatch > queue and then using dispatch_async to call a block that does the work. The > end of the block would call dispatch_async back to the main queue and pass > the image as a parameter. I second the use of GCD. Its also considerably simpler than NSThread, NSOperationQueue/NSOperation et al. This is the kind of operation that GCD was invented for. —Rob ___ 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: Minimizing my app kills timer ?
On May 8, 2020, at 12:50:23, Alex Zavatone wrote: > > Oh Steve, which version of MacOS are you seeing this on? What? I'm not the OP of this thread. -- 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: Concurrent loading of images ?
> On May 8, 2020, at 9:53 AM, Gabriel Zachmann via Cocoa-dev > wrote: > > So, I was thinking, maybe it helps to load the next image concurrently, while > the current one is still being displayed. Sure. Just be aware that if you're using NSImage, simply loading an NSImage does not rasterize it; the class tries to be 'lazy' about doing work. So your background task should explicitly render it, e.g. into an NSBitmapImageRep. > I also read about the GCD's dispatch queues, but it seems to me that this > would not be the suitable approach since I always only have one task running > concurrently to the main thread. Why not? Dispatch queues are always available. (The main thread is simply a special queue.) You can run the background task by creating a single dispatch queue and then using dispatch_async to call a block that does the work. The end of the block would call dispatch_async back to the main queue and pass the image as a parameter. (Or you could use NSOperationQueue and NSOperation, although I've always found those classes unnecessarily complicated for simple tasks.) —Jens ___ 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: Concurrent loading of images ?
Does this seem related? https://9to5mac.com/2020/04/28/new-bug-found-in-macos-can-quickly-fill-up-storage-when-importing-photos-with-image-capture/ "The problem discovered by the NeoFinder team is that the Mac adds 1.5MB of empty data to each converted photo, making the imported files larger for no reason. By looking inside these photos through a Hex-Editor, you can find a section full of zeroes, which results in unnecessarily larger files.” I know you’re not capturing images, just loading them, but It’s pretty suspiciously similar. > On May 8, 2020, at 11:53 AM, Gabriel Zachmann via Cocoa-dev > wrote: > > Sometimes, when it switches from one image to the next, there is a noticeable > lag when the file size of the next image is very big, say, 50 MB or more. ___ 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: Minimizing my app kills timer ?
Oh Steve, which version of MacOS are you seeing this on? > On May 4, 2020, at 8:33 AM, Steve Mills via Cocoa-dev > wrote: > > On May 4, 2020, at 03:28:23, Gabriel Zachmann wrote: >> >> You mean, it could happen that Apple decides to make ScreenSaverView a >> subclass of some class other than NSView ? >> (currently, it is a subclass of NSView) > > No, I mean just what I said. It's not guaranteed or even suggested that > ScreenSaverView be used with anything other than a screensaver. > >> I agree that with Apple you never know what massive changes are waiting >> around the corner. But, are there other reasons why you recommend against >> using ScreenSaverView? > > The screensaver animation in macOS is reliant on the engine that drives it. > Recently that changed from an older engine to what we can only guess is a > newer one, but some of them still run in what is known as a newly named > legacyScreenSaver, yet ScreenSaverEngine still fits in there somehow. We > don't know how it works and we don't *need* to know. Screensaver engines run > in a very controlled and limited environment. They need to be efficient. They > need to treat user input differently. They treat activation totally > differently. When you start trying to force such an engine to run in a normal > app that can deactivate, hide, minimize, etc, you're throwing it all kinds of > things it isn't designed to handle. > > If you really want to run your screensaver animation in a non-screensaver > app, you'll need to control the animation, and rework your classes so you > have one class that is used by both the screensaver and your app, and do the > actual drawing in that class. It will be called by animateOneFrame in the > screensaver and by what animation engine you come up with in your app. > > -- > 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/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: Minimizing my app kills timer ?
What if you spawned another process (NSTask?) from the screensaver and tested if a timer works in that? It’s hokey as hell, but I use this approach to monitor a running process and do things when its state changes to suspended. See if you can fire off a process and have a timer in it that logs the time and some string every 10 seconds. Then minimize your screensaver and see what happens. Various appendages crossed for you. Sending thoughts and prayers. Good luck. Alex Zavatone > On May 4, 2020, at 8:33 AM, Steve Mills via Cocoa-dev > wrote: > > On May 4, 2020, at 03:28:23, Gabriel Zachmann wrote: >> >> You mean, it could happen that Apple decides to make ScreenSaverView a >> subclass of some class other than NSView ? >> (currently, it is a subclass of NSView) > > No, I mean just what I said. It's not guaranteed or even suggested that > ScreenSaverView be used with anything other than a screensaver. > >> I agree that with Apple you never know what massive changes are waiting >> around the corner. But, are there other reasons why you recommend against >> using ScreenSaverView? > > The screensaver animation in macOS is reliant on the engine that drives it. > Recently that changed from an older engine to what we can only guess is a > newer one, but some of them still run in what is known as a newly named > legacyScreenSaver, yet ScreenSaverEngine still fits in there somehow. We > don't know how it works and we don't *need* to know. Screensaver engines run > in a very controlled and limited environment. They need to be efficient. They > need to treat user input differently. They treat activation totally > differently. When you start trying to force such an engine to run in a normal > app that can deactivate, hide, minimize, etc, you're throwing it all kinds of > things it isn't designed to handle. > > If you really want to run your screensaver animation in a non-screensaver > app, you'll need to control the animation, and rework your classes so you > have one class that is used by both the screensaver and your app, and do the > actual drawing in that class. It will be called by animateOneFrame in the > screensaver and by what animation engine you come up with in your app. > > -- > 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/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: Concurrent loading of images ?
Thanks for the question: MacOS. > > iOS or MacOS? ___ 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: Concurrent loading of images ?
iOS or MacOS? > On May 8, 2020, at 11:53 AM, Gabriel Zachmann via Cocoa-dev > wrote: > > I have kind of a slide-show app. > > Sometimes, when it switches from one image to the next, there is a noticeable > lag when the file size of the next image is very big, say, 50 MB or more. > Sometimes, it seems that loading the image takes 1-2 seconds. > > So, I was thinking, maybe it helps to load the next image concurrently, while > the current one is still being displayed. > > My question is: should I spawn a thread (using NSThreads' > detachNewThreadSelector), load the image in that thread, then exit the > thread? (no run loop) > > Or should I use NSObject's performSelectorInBackground ? > > I also read about the GCD's dispatch queues, but it seems to me that this > would not be the suitable approach since I always only have one task running > concurrently to the main thread. > > What do you think? > > Best regards, Gabriel > > ___ > > 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
Concurrent loading of images ?
I have kind of a slide-show app. Sometimes, when it switches from one image to the next, there is a noticeable lag when the file size of the next image is very big, say, 50 MB or more. Sometimes, it seems that loading the image takes 1-2 seconds. So, I was thinking, maybe it helps to load the next image concurrently, while the current one is still being displayed. My question is: should I spawn a thread (using NSThreads' detachNewThreadSelector), load the image in that thread, then exit the thread? (no run loop) Or should I use NSObject's performSelectorInBackground ? I also read about the GCD's dispatch queues, but it seems to me that this would not be the suitable approach since I always only have one task running concurrently to the main thread. What do you think? Best regards, Gabriel ___ 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
