Error while generating a Linux standalone
Richmond Mathewson
richmondmathewson at gmail.com
Mon Jan 4 07:08:21 EST 2010
On Sun, Jan 3, 2010 at 5:17 PM, Richard Gaskin
<ambassador at fourthworld.com>wrote:
> Andre Rombauts wrote:
>
>> anybody else tells me it is a BIG MISTAKE spinning off standalones
>>> for any
>>> platform from a platform other than the target one.
>>>
>>
>> It is one of RunRev assets to produce easily multi-platforms
>> applications.
>> Testing on each, might not be a problem but why should I generated on
>> an another platform?
>> If this is an issue why is it offered as a feature in Runrev?...
>>
>
> I can't speak highly enough of the benefits of testing and tweaking on each
> of the platforms one develops for, but as far as the mechanics of building
> standalones I've had good success for many years building for OS X, Win, and
> Linux from my Mac.
I, certainly, have had great success spinning off Windows standalones from
RR 4.
I find Linux standalones are not always reliable.
However, working with earlier versions of RR I have had nothing but grief
spinning off
both Windows and Linux standalones.
The last sentence should be taken in the context that before I acquired RR 4
I used
RR 2.0.1 to spin off standalones; and there has been an awful lot of water
under the
bridge between RR 2 and RR 4. I still use the FREE version of RR 2.2.1 for
Linux
(spins off standalones for Linux only) that was given out by Novell quite a
few years
ago because the machines I run in my language school run on Ubuntu 5.10, and
RR 4 studio for Linux does not work on that system, nor do standalones
generated
by RR 4 studio for Linux on a machine running a later form of Ubuntu.
As setting up a functioning Linux system cost me about $25 and a couple of
hours
work that seems a small trade-off for guaranteeing my Linux standalones
behave the
way they should.
I have a similar system (headless) running Windows XP Home (OEM XP cost me
$25)
in Bulgaria (I am still in England at the moment), and it really is the best
way of
ensuring that things go exactly as they should. I previously used VPC with
Windows,
but it was grindingly slow.
This also allows you to see what the thing looks like running on your target
system.
I feel that developing and hiving off standalones on one system for another
without
access to that target system is a bit like fumbling around in a dark room
looking for
the light switch; I usually end up either falling over a chair or sticking
my fingers into
something that hurts.
If you have a new INTEL Mac you can spend your money on one of the 'things'
that
will allow you to run Windows and Linux on your Mac; the end-result is much
the same.
> Win standalones run without alteration, and the Linux builds run as soon
> as I set their executable bit within Linux.
This is an extremely important point - setting the executable property of a
Linux
standalone - unless you expect the end-user to do this for herself you HAVE
to have
access to a Linux system.
> The build process itself has always been flawless here (with the only
> exceptions being "user error", things I may have forgotten to include or set
> up properly, easily remedied).
>
The only problem about statements such as "The build process itself has
always been flawless here" is that 'here' is not 'there', and all you need
is one end-user to make a big
noise and your reputation gets dragged through the mud.
Unless you live and work in a 3-foot square box with no space there is
really no reason
not to have a few test machines to hand. I work in a 3-foot by 6-foot
'office' and still
manage to have 4 machines packed in there as well as bags of room for a
record-player
and coffee cups. Needless to say, I come out of the office to live; but,
hey, let's face
it, if spending one's time hunched over a computer constitutes living we are
all in line
for padded cells and straitjackets down at the funny farm. . . :)
-----------------------------------------------------------------------
I am the author of Devawriter
http://andregarzia.on-rev.com/richmond/dwriter.html
-----------------------------------------------------------------------
More information about the use-livecode
mailing list