Build Script compared to RuntimePackager?

Hello Folks,

 

There is a script from the Smalltalk Daily about 6/22/10 which presents a simple way to build an executable (simply loading parcels, garbage collect, runtime state, ... , build).

 

Does anyone have experience/sugs related to using a scripting approach as compared with the RuntimePackager? (in regard to a pretty basic target executable).

 

If scripting is reasonable, does anyone know of a technique of setting a startup class & method (as opposed to subclassing UserApplication)?

 

Thank you,

 

Gary P

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Our build process scripts RTP. It first loads Store, loads our app from Store, saves a development image, unloads development packages, then runs RTP. Although RTP wasn't designed to be scripted, most of it is easy - just open an instance of its UI then send it the same commands as the button presses. There were a couple of cases where a button press opens a dialog to request a filename, so we have overrides there that allow that to be provided via a shared variable (set by the script) or argument.

 

All the best,

Steve

---

From: [hidden email] on behalf of Maarten Mostert
Sent: Sun 30/06/2013 11:37
To: Gary Peterson
Cc: [hidden email]
Subject: Re: [vwnc] Build Script compared to RuntimePackager?

James is the expert on scripting

But the main advantage of scripting is that it always produces the same results, and it allows you to stay in a ready to deploy mode.

The runtime packager has many options and is a very manual process, prone for errors.

Once setup the scripting is really stable.

@+Maarten, 

Le 29 juin 2013 à 16:55, "Gary Peterson" <[hidden email]> a écrit :

Hello Folks,

 

There is a script from the Smalltalk Daily about 6/22/10 which presents a simple way to build an executable (simply loading parcels, garbage collect, runtime state, ... , build).

 

Does anyone have experience/sugs related to using a scripting approach as compared with the RuntimePackager? (in regard to a pretty basic target executable).

 

If scripting is reasonable, does anyone know of a technique of setting a startup class & method (as opposed to subclassing UserApplication)?

 

Thank you,

 

Gary P

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Thanks James, good points. For our app, we built up for about ten years, and have stripped down for about ten years. IIRC you have experience with both too, but (at least in the last decade) in the opposite order.

 

RTP's stripping is deterministic, and whilst I don't know quite what you mean by "indeterminate", how it chooses what to include makes sense to me. We select all our own packages to be kept in their entirety (tests etc. are in separate packages and not loaded for these builds). We also select a few base packages, where the automatic mechanisms miss things (e.g. only referred via metaprogramming, or based on the current Locale). I like the fact that what RTP selects changes based on my application code - if I start using a new method, it gets included, along with everything that method needs.

 

The downside for us is not so much the points you mentioned, but that RTP's accurate stripping sometimes causes more work down the line. We do quick updates of our deployed app with code patches, and sometimes hit situations where our patched method refers to a base method that previously was not used anywhere. When we test the patch we see the error, check RTP's log of the strip, and see what the base method was. We then have to include that extra base method (and occasionally other new things it needs) manually in our patch. The only times that has been annoying has been when we've needed to include a whole new parcel - often from the net or security world - and in those cases the problem would have been the same if we had been building up rather than stripping down.

 

One other place RTP can't help is if you start using a method from the dev tools: our script unloads those before invoking RTP. The situation is similar with a building-up approach.

 

I agree though that the space saving, although appreciable, is less valuable nowadays than it used to be. Partly that's because if I buy a new disk these days, it's 1.5TB rather than 1.44MB, partly because the base image has grown over the years, partly because we include more Cincom parcels and 3rd party packages, partly because our images are now compressed, and partly because of growth in other things included in our installer.

 

To build up or strip down is partly a matter of taste, and partly dependent on what kind of application you are building and how you deliver it. Either way can be made to work well. IMHO the key thing isn't so much which way you choose, but that you choose one and automate it.

 

All the best,

Steve

---

From: [hidden email] on behalf of James Robertson
Sent: Sun 30/06/2013 17:31
To: VWNC NC
Subject: Re: [vwnc] Build Script compared to RuntimePackager?

I've avoided that approach because I don't like the indeterminate nature of the stripping, and the fact that it can change based on very small changes to your application code.  That, and the fact that running the stripper doesn't save you a lot (space-wise) over simply removing packages you know you don't need.

On Jun 30, 2013, at 7:42 AM, Steven Kelly <[hidden email]> wrote:

Our build process scripts RTP. It first loads Store, loads our app from Store, saves a development image, unloads development packages, then runs RTP. Although RTP wasn't designed to be scripted, most of it is easy - just open an instance of its UI then send it the same commands as the button presses. There were a couple of cases where a button press opens a dialog to request a filename, so we have overrides there that allow that to be provided via a shared variable (set by the script) or argument.

 

All the best,

Steve

---

From: [hidden email] on behalf of Maarten Mostert
Sent: Sun 30/06/2013 11:37
To: Gary Peterson
Cc: [hidden email]
Subject: Re: [vwnc] Build Script compared to RuntimePackager?

James is the expert on scripting

But the main advantage of scripting is that it always produces the same results, and it allows you to stay in a ready to deploy mode.

The runtime packager has many options and is a very manual process, prone for errors.

Once setup the scripting is really stable.

@+Maarten, 

Le 29 juin 2013 à 16:55, "Gary Peterson" <[hidden email]> a écrit :

Hello Folks,

 

There is a script from the Smalltalk Daily about 6/22/10 which presents a simple way to build an executable (simply loading parcels, garbage collect, runtime state, ... , build).

 

Does anyone have experience/sugs related to using a scripting approach as compared with the RuntimePackager? (in regard to a pretty basic target executable).

 

If scripting is reasonable, does anyone know of a technique of setting a startup class & method (as opposed to subclassing UserApplication)?

 

Thank you,

 

Gary P

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

James Robertson

http://www.jarober.com

[hidden email]

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc