savingStandalone message

[Ali Lloyd]

Thanks for the feedback Paul. How is your build number increment
implemented?

On Tue, Nov 15, 2016 at 1:18 PM Paul Dupuis <paul at researchware.com> 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
> > use-livecode at lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> >
>
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>