Ben, Your suggested model with the parameters would work just fine for me. I like it!
Ali Different projects of mine do different things, but generally, for some of my projects, I grab a stack custom property that represented a incremental counter (which is basically incremented by 1 on every saveStackRequest message) and clear it for the standalone(s) when built. As noted, I could code around it, or, as I consider this, I realize in this specific case where I am clearing a property, repeated calls of the savingStandalone message would not matter. In another I add a date and time stamp into a property of the standalone - ideally the same date & time for all the platforms I am building for (which in that case is just Windows and OSX) As I noted, any of the above can be coded to work with a savingStandalone message for each platform, so it is not like the proposed change would change anything that could not be fixed. On 11/15/2016 8:49 AM, Ali Lloyd wrote: > Thanks for the feedback Paul. How is your build number increment > implemented? > > On Tue, Nov 15, 2016 at 1:18 PM Paul Dupuis <[email protected]> wrote: > >> I make use of the savingStandalone message in a few projects. Generally, >> I would prefer a single message regardless of the number of platforms I >> am building for. For ecample, I set a incremental "build' number on >> savingStandalone and I would want that build number to be the same for >> all platforms built for. If the message was sent for each platform I >> suspect I could come up with some what to still do this, but the code >> complexity would increase for a relatively simple task. >> >> It would seem to me that if you are looking for platform specific >> actions to modify the stack(s) used in each platform build, then ideally >> you would want a set of platform specific messages. i.e >> >> savingStandaloneForWindows >> savingStandaloneForOSX >> savingStandaloneForiOS >> savingStandaloneForAndroid >> savingStandaloneForHTML5 >> ... >> >> Or something like that. That way if you only meed to make a specific >> scripted stack modification for Android, you only need to handle that >> specific message. >> >> >> On 11/15/2016 4:45 AM, Ali Lloyd wrote: >>> Hi all, >>> >>> Various tweaks to the standalone builder seem to have broken the way the >>> savingStandalone message is supposed to work >>> http://quality.livecode.com/show_bug.cgi?id=18778 >>> >>> I have submitted a pull request that fixes it - the only wrinkle might be >>> that it reintroduces the following bug: >>> http://quality.livecode.com/show_bug.cgi?id=18364, namely that the >>> savingStandalone message gets sent for each build platform. >>> >>> Now, my personal view is that that is how it should work, provided the >>> stack state is restored before building for the next platform. It allows >> a >>> more fine-grained build step where, if we added suitable parameters to >> the >>> message, you could for example ensure substacks with >> platform/architecture >>> specific resources were not included in the standalones where they are >>> irrelevant. >>> >>> My question to you is the same as I asked Lyn Teyla in the above report: >>> >>> Would the following behavior be a problem for your use case, and if so >> why? >>> store stack state (*) >>> repeat for each target architecture >>> dispatch saving standalone message >>> modify stack for per-arch settings >>> deploy stack >>> restore to state in (*) >>> dispatch standalone saved message >>> end repeat >>> _______________________________________________ >>> use-livecode mailing list >>> [email protected] >>> Please visit this url to subscribe, unsubscribe and manage your >> subscription preferences: >>> http://lists.runrev.com/mailman/listinfo/use-livecode >>> >> >> _______________________________________________ >> use-livecode mailing list >> [email protected] >> Please visit this url to subscribe, unsubscribe and manage your >> subscription preferences: >> http://lists.runrev.com/mailman/listinfo/use-livecode >> > _______________________________________________ > use-livecode mailing list > [email protected] > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > _______________________________________________ use-livecode mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
