mcStandaloneBuilder b1 posted

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

mcStandaloneBuilder b1 posted

Richard Gaskin
Wilhelm and the rest of the MC gang:

The first beta of the new mcStandaloneBuilder is available at the new MC
mirror:

<http://www.metacard.livecodejournal.com/files/mccomponents/mcStandaloneBuilder.rev.gz>

This requires engine v4.5 or later, and was tested with v4.6 on OS X,
Windows, and Linux.

This build should let you make standalones for all three platforms (OS
X, Win, Linux) from any of them with one exception:  currently it can
only build for OS X while running on OS X.  This is a known issue and
will be addressed, but I didn't want to hold this up further while I
work out the details.

This build does not support mobile in any way, and the RevWeb options in
the UI are entirely unimplemented.  In fact, I have no need for RevWeb
at all for the foreseeable future, so if any of you need that and are
willing to add support for it let me know and we can coordinate how to
add your mods to my copy of the master build.

Also, note that while most of the useful code is exposed in the unlocked
mainstack for your perusal and enhancement if you so desire, I was
requested by Kevin and Mark to temporarily lock the relatively small
portion of the code currently in a substack there that makes the actual
engine call that binds the engine to the stack file.   This lock will be
removed in later version, but RunRev needs to first verify that their
internal security mechanism is working as expected.  This will have no
practical effect on using or modifying the Standalone Builder, since all
the meaningful stuff is available for you in the mainstack, and only the
specifics of the engine call at the end of the process are protected in
this version.


There is currently no Help provided in this build, but I'll give you a
few tips on using it here:

- Like LiveCode's, there are multiple tabs for platform-specific
options, but unlike LiveCode's there's also a General tab -- if you set
stuff there it fills in all of the OS-specific tabs for you, making the
setup process even easier since you really only need to work with the
stuff on one tab to build for all platforms.  App name, version,
copyright, etc. get transferred automatically to the platform-specific
tabs whenever you edit the values on the General tab.  This means that
if you do make specific edits to the other tabs, those will be
overwritten if you later modify the General tab again.  Whether this is
a bug or a feature is for you to decide; for now it is what it is, and
it's very handy for me personally. :)

- Settings are stored in a custom property set of the stack being built
into a standalone, using the same property set name LC uses
(revStandaloneSettings).  The format of the data stored there is a
superset of the keys LC uses, so you should be able to use these
settings interchangeably with LC's standalone builder.  Please let me
know if you find any exceptions to that.

- When the mcStandaloneBuilder stack opens it scans all other open
stacks to find the topmost stack which already has a
revStandaloneSettings property set, and loads that data if it finds one.
  This means that if you already have a stack open that you want to
build from and have set it up previously, just opening the
mcStandaloneBuilder will load its UI with the settings from that stack
automatically so all you have to do is click "Build".


There are various minor bugs and annoyances, and the option to use a
custom plist for OS X is not yet implemented (though the generated one
works well).

A new build will be made available as soon as time permits.

In the meantime, feel free to post any bug reports you have either here
to or me personally at [hidden email]

I wouldn't want to overload this list with bug reports, but it may be
helpful to discuss them here where we can all keep apprised of what's
working, what's not, and future directions.  Your call.

--
  Richard Gaskin
  Fourth World Media Corporation
  ___________________________________________________________
  [hidden email]       http://www.FourthWorld.com

_______________________________________________
metacard mailing list
[hidden email]
http://lists.runrev.com/mailman/listinfo/metacard
Reply | Threaded
Open this post in threaded view
|

Re: mcStandaloneBuilder b1 posted

sanke
Many thanks to Richard and Ken for the release of the new Standalone
Builder and the 4.1 IDE, not to forget the new Metacard Setup 2.01 by
Jacqueline - and I assume that the preparations by Klaus were helpful
for the developments of these tools..

The releases coincided with a palpable improvement of my health after
four months of fighting with a nasty gastritis that caused a lot of
enforced inactivity and reduced my energy and productivity to a large
extent. But last week I have even resumed training with my tennis team,
hopefully to prepare for the second half of the summer series in August
(usually it is colder here than elsewhere).

Although the new releases are actually not the direct cause of my
relatively improved health (as you would also guess from my first report
below), I think that working with the shortly following versions of
Standalone Bulder and the IDE will help me to recover completely in the
near future with an enhanced motivation.

In his release mail Richard wrote:

"In the meantime, feel free to post any bug reports you have either here
to or me personally at [hidden email]

I wouldn't want to overload this list with bug reports, but it may be
helpful to discuss them here where we can all keep apprised of what's
working, what's not, and future directions. Your call."

With his "beta 1"-version Richard has given a differentiated answer to a
situation that has become at least slightly more complex than before
with the required new directory structure for a Metacard folder and the
new license-binding procedures for a standalone two years ago. Before
Rev version 4.0, all I needed to set up a Metacard folder was to drop a
new Revolution engine into the MC IDE and possibly rename the engine, at
least on Windows. To build a standalone, in the Metacard Standalone
Builder I had to find a single file "standalone" (without extension)
instead of the former "MC.exe" - and to prepare for such standalone
building I had copied this single "standalone" file into my Metacard
folder before. I just checked this again inside my Metacard folder 3.5
gm1 with the MC IDE 3.0..

Here are some results and added comments of my first unsystematic
exploration of the B1 version:

I succeeded to build two standalones from my stacks on Windows XP and in
my Metacard folder 4.6.1, but after the succesful build they refuse to
run and only throw an error message "Standalone origin mismatch". After
these two non-running builds I was somehow unable to build more
standalones. There is for example no indication in the Windows pane
which fields are required ones and which optional. One of the questions
here: Should not field "Original Filename" in the Windows tab be
automatically filled from the chosen "Source Stack" selection?

For "LiveCode Folder/Bundle" - in the upper region of the Standalone
Builder - I had first chosen the Livecode "runtime" folder" where the
"standalone" files reside - following in essence the procedure I had
used before in the 3.0 MC IDE, namely locating the necessary file
"standalone".  Instead we apparently need to choose the complete
Livecode folder, but I cannot replicate this now as the Standalone
Builder at the moment refuses to build any stacks, there is even no
error message when I press button "Build".

My proposal is to allow to point to the "runtime" folder only, which
could be copied into the Metacard folder. This would mean that you need
not have both the full Metacard and Livecode installations on the same
computer (for example on a laptop). If the presence of a complete
Livecode folder would be needed, why should we use an extra MC
Standalone Builder?, provided of course the Livecode SB would function
as expected without such peculiarities as it had often shown in the past
like endless build times etc..

I see that "cRevStandaloneSettings" are attached to the source stack
during the build procedure. Looking at them in one of the source stacks
that were built, but refuse to run,
I find (without the full path before):
          "Meta-Livecode 4.6.1" for "_GEN_DestinationFolder"
          "Livecode 4.6.1"         for "_GEN_EngineFolder"
but     "Livecode 4.6"           for "defaultBuildFolder"

i.e. "4.6" instead of "4.6.1". Should this be the cause for the above
quoted error message "Standalone origin mismatch"?

This is all I can report at the moment. I will continue to look more
closely into the matter, but it seems to me we need a first update.

Best regards,

Wilhelm Sanke

_______________________________________________
metacard mailing list
[hidden email]
http://lists.runrev.com/mailman/listinfo/metacard
Reply | Threaded
Open this post in threaded view
|

Re: mcStandaloneBuilder b1 posted

Ken Ray

> For "LiveCode Folder/Bundle" - in the upper region of the Standalone Builder - I had first chosen the Livecode "runtime" folder" where the "standalone" files reside - following in essence the procedure I had used before in the 3.0 MC IDE, namely locating the necessary file "standalone".  Instead we apparently need to choose the complete Livecode folder, but I cannot replicate this now as the Standalone Builder at the moment refuses to build any stacks, there is even no error message when I press button "Build".

Wilhelm, the "LiveCode Folder/Bundle" corresponds to the true LiveCode directory or (on Mac) application bundle. The standalone builder figures out where the runtimes are based on that. this matches the corresponding data in the new "LiveCode" tab of the Preferences window; in fact, if you set it up from Preferences, the new standalone builder will use it.

So all you need to do is pick the folder that was installed by the LiveCode installer into Program Files and the SB should do the rest (bugs notwithstanding).

Ken

_______________________________________________
metacard mailing list
[hidden email]
http://lists.runrev.com/mailman/listinfo/metacard
Reply | Threaded
Open this post in threaded view
|

Re: mcStandaloneBuilder b1 posted

Ken Ray
In reply to this post by sanke
Sorry Wilhelm, misread your post - ignore what I said in my previous post to
the list.

> My proposal is to allow to point to the "runtime" folder only, which
> could be copied into the Metacard folder. This would mean that you need
> not have both the full Metacard and Livecode installations on the same
> computer (for example on a laptop). If the presence of a complete
> Livecode folder would be needed, why should we use an extra MC
> Standalone Builder?, provided of course the Livecode SB would function
> as expected without such peculiarities as it had often shown in the past
> like endless build times etc..

That's the rub... even if the LC SB worked perfectly, it would still be a
pain to develop in the MC IDE and then have to switch out to LC in order to
build a standalone.

We're trying to accommodate those that use MC *and* LC as well as those
using MC only, so we should come up with a good way to do that; pointing to
only the Runtime folder might be a way to do it...

Ken Ray
Sons of Thunder Software, Inc.
Email: [hidden email]
Web Site: http://www.sonsothunder.com/



_______________________________________________
metacard mailing list
[hidden email]
http://lists.runrev.com/mailman/listinfo/metacard
Reply | Threaded
Open this post in threaded view
|

Re: mcStandaloneBuilder b1 posted

sanke
In reply to this post by Richard Gaskin
On Sun, 03 Jul 2011,  Ken Ray wrote:


> Sorry Wilhelm, misread your post - ignore what I said in my previous
> post to
> the list.


Not at all, Ken. Your hint to the Livecode tab in the new "preferences"
was new information for me, as it places the path to the preferred
Livecode version then automatically into the field "LiveCode
Folder/Bundle" of the SB.

> > My proposal is to allow to point to the "runtime" folder only, which
> > could be copied into the Metacard folder. This would mean that you need
> > not have both the full Metacard and Livecode installations on the same
> > computer (for example on a laptop).
>
> That's the rub... even if the LC SB worked perfectly, it would still be a
> pain to develop in the MC IDE and then have to switch out to LC in
> order to
> build a standalone.
>
> We're trying to accommodate those that use MC *and* LC as well as those
> using MC only, so we should come up with a good way to do that;
> pointing to
> only the Runtime folder might be a way to do it...

Thanks for agreeing here, and maybe we could have both options.

> Ken Ray


I want come back to my question about "required" and "optional" fields
in the SB (in my last post):

The SB of our old MC IDE 3.0.0b has a impressing simplicity:

To successfully build a standalone only *three* selections have to be
made. You have to select the source stack ("Stack name"), then the
"Metacard engine" (which two years ago was already the path to this
single file "standalone" (on Windows)), and finally a "Standalone file
name" for the new standalone to be built.

Then you press button "Build" and get the message "Standalone built
successfully"

Especially for quick builds in between during a development such a
simple procedure (only on the surface of course) is important and
useful, more detailed information about a standalone can then be entered
under "Set Windows Version Info.." and "OSX settings" (with "file
version", "OriginalFilename" etc. etc.)

Our new SB could maybe be considered to possess a similar simplicity,
but it is surely not obvious, unless of course you know which entries
are required.

After a lot of trial and error - yesterday and today - I think I found
out the minimal requirements to build a standalone (I am though not
sure, whether I am 100% exact here, but they seem to work; ten minutes
ago I have been finally able to build my first working standalone, but
we do not get a concluding message after an achieved build like with MC
SB 3.0.0b):

- select "Source Stack"
- "Save Stack" is *not* needed for the build, probably only useful for
storing the new custom properties in the source stack, but for that
purpose *after* the build process.
-select "destination Folder"
- select "LiveCode Folder/Bundle"
In the "General" Tab
- enter "App Name" (name of the new standalone)
- enter "Version"
- enter "Builder Number" (really reqired?)
In the "Windows" tab
- add "File Version"
- add "Product Version".

As a result of all my endeavours I have now got two extra folders in my
destination directory, namely "Version" and "Version 1". Folder
"Version" is empty, "Version 1" contains two subfolders "Build" and
"Build 1". "Build" also is empty, "Build 1" eventually contains folder
"Windows" with the three standalone files I managed to create in these
two days. All indeed bear their "App Names" I had chosen in the
"General" tab, but two of them refuse to run and throw an error
"Standalone origin mismatch". -

I am wondering what the meaning of this message could be. As I had
already reported yesterday, one of the non-running standalones has
deviating entries in its ""cRevStandaloneSettings" that are created
during the build process

          "Livecode 4.6.1"         for "_GEN_EngineFolder"
but     "Livecode 4.6"           for "defaultBuildFolder"

It seems to me that "Livecode 4.6" is a remnant of an earlier build
inside Livecode. But that does not explain, why and how the standalone
was created nevertheless and why it doesn't run?

I recommend to use something like "cMCStandaloneSettings" in the future
to avoid such conflicts.

The second non-running standalone, which throws the same error message,
does *not* have such conflicting "cRevStandaloneSettings", in fact,
there are none at all, having seemingly disappeared later somehow.

To sum it up: About four hours for the first two explorations of our new
Standalone Builder, some insights - including looks at the structure of
the scripts - and at least one really working standalone.

All in all a positive achievement.

Best regards,

Wilhelm Sanke



_______________________________________________
metacard mailing list
[hidden email]
http://lists.runrev.com/mailman/listinfo/metacard
Reply | Threaded
Open this post in threaded view
|

Re: mcStandaloneBuilder b1 posted

Ken Ray

> Our new SB could maybe be considered to possess a similar simplicity,
> but it is surely not obvious, unless of course you know which entries
> are required.
>
> After a lot of trial and error - yesterday and today - I think I found
> out the minimal requirements to build a standalone (I am though not
> sure, whether I am 100% exact here, but they seem to work; ten minutes
> ago I have been finally able to build my first working standalone, but
> we do not get a concluding message after an achieved build like with MC
> SB 3.0.0b):
>
> - select "Source Stack"
> - "Save Stack" is *not* needed for the build, probably only useful for
> storing the new custom properties in the source stack, but for that
> purpose *after* the build process.
> -select "destination Folder"
> - select "LiveCode Folder/Bundle"
> In the "General" Tab
> - enter "App Name" (name of the new standalone)
> - enter "Version"
> - enter "Builder Number" (really reqired?)
> In the "Windows" tab
> - add "File Version"
> - add "Product Version".

OK, let's take this one at a time as it relates to a "quick build" (i.e.
brand new stack):

"Source Stack" currently is automatically filled in for you *if* the stack
has any standalone settings stored with it. I think it should just use the
topStack (unless Richard wants to chime in here).

At least one "Build For" checkbox must be checked. Perhaps the SB should
automatically check off the current OS's checkbox for a brand new stack.

"Destination Folder" is needed, but once again, perhaps it can default to
the current location of the stack.

"LiveCode Folder/Bundle", if set in Preferences, will automatically be
filled in for you in the SB.

"General Tab": All you should need to fill in is the "App Name" and "Version
Number" field - once you exit the Verison Number field, it automatically
sets the File Description, File Version and Product Version fields on the
Windows tab (as well as the Short Version, Long Version, and Get Info fields
on the Mac OS X tab).

So if changed to meet the above concepts, for a quick build you'd need to
just enter the App Name and Version Number.


> As a result of all my endeavours I have now got two extra folders in my
> destination directory, namely "Version" and "Version 1". Folder
> "Version" is empty, "Version 1" contains two subfolders "Build" and
> "Build 1". "Build" also is empty, "Build 1" eventually contains folder
> "Windows" with the three standalone files I managed to create in these
> two days. All indeed bear their "App Names" I had chosen in the
> "General" tab, but two of them refuse to run and throw an error
> "Standalone origin mismatch". -

When you build with the SB, a subfolder of the Destination Folder is created
based on the version number  in the "Version" field, and a subfolder of the
Version folder for the build number. So if the version is "1.0" and the
build number is "1", and the app name is "Test", when you build it you get
this in the Destination Folder:

<Destination Folder>
    Version 1.0
        Build 1
            Test.exe

Apparently if you leave the "Builder Number" (should be "Build Number")
field empty, it will create a folder based on the Version field and a
subfolder just called "Build", but will then throw an error, giving you:

<Destination Folder>
    Version 1.0
        Build

 If you then put "1" into the field and re-build, it creates the "Build 1"
folder and puts the standalone into there:

<Destination Folder>
    Version 1.0
        Build
        Build 1
            Test.exe

If you leave the Version and Build Number fields alone and change the name
of the standalone to "Another Test" and hit Build, you'd have this:

<Destination Folder>
    Version 1.0
        Build
        Build 1
            Test.exe
            Another Test.exe
 
> I am wondering what the meaning of this message could be.

I can't help with that one... it must be thrown by the LC engine itself.

> As I had
> already reported yesterday, one of the non-running standalones has
> deviating entries in its ""cRevStandaloneSettings" that are created
> during the build process
>
>           "Livecode 4.6.1"         for "_GEN_EngineFolder"
> but     "Livecode 4.6"           for "defaultBuildFolder"

Interestingly, I don't have a "defaultBuildFolder" value in my custom
property set for a fresh build.

> I recommend to use something like "cMCStandaloneSettings" in the future
> to avoid such conflicts.
>
> The second non-running standalone, which throws the same error message,
> does *not* have such conflicting "cRevStandaloneSettings", in fact,
> there are none at all, having seemingly disappeared later somehow.

One thing to keep in mind is that all of the settings you make in the SB
don't get written to the stack you're building the standalone from unless
you click the "Save Stack" button in the SB.

So perhaps if you delete the cRevStandaloneSettings custom property set and
then re-save the settings by clicking the "Save Stack" button in the SB?

Ken Ray
Sons of Thunder Software, Inc.
Email: [hidden email]
Web Site: http://www.sonsothunder.com/



_______________________________________________
metacard mailing list
[hidden email]
http://lists.runrev.com/mailman/listinfo/metacard
Reply | Threaded
Open this post in threaded view
|

Re: mcStandaloneBuilder b1 posted

Rob-113
In reply to this post by Richard Gaskin
Wilhelm, I had the same problem with an old stack, Saving the stack in MC fixed it.

Rob


_______________________________________________
metacard mailing list
[hidden email]
http://lists.runrev.com/mailman/listinfo/metacard