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
