creating stand-alone versions for easy distribution etc 
Author Message
 creating stand-alone versions for easy distribution etc

hi list,

I was looking around for a way to package a ruby-app of mine for easy
distribution to some of my non-ruby/non-programmer friends. I didn't come
across anything other than a program by Robert Feldt which was Windows only. I
wasn't happy and searched further among other scrpting languages and came
across something from the python community called 'Installer':
http://www.*-*-*.com/

To me this seems very doable for ruby too, and a direct port not that hard.
Anyone has any thoughts on this? I will probably start looking into this
during the holidays if no one else does before.

--
---------------------------------------------------------------------------.
Patrik Sundberg    Address: Rydsv?gen 100C, 584 31 Link?ping, Sweden       |

                   Phone:   +46 13 178567 || +46 707 602240                |
.---> Applied Physics and Electrical Engineering student                   |
|-----> Master of Science in Business Administration and Economics student |
|-------> UNIX/Programming consultant                                      |
`--------------------------------------------------------------------------'



Sat, 05 Jun 2004 17:35:34 GMT  
 creating stand-alone versions for easy distribution etc

Quote:

> hi list,

Hi Patrik,

Quote:
> I was looking around for a way to package a ruby-app of mine for easy
> distribution to some of my non-ruby/non-programmer friends. I didn't come
> across anything other than a program by Robert Feldt which was Windows only. I
> wasn't happy and searched further among other scrpting languages and came

I think better methods for this are needed so would be great if you have
the time to work on this!

Quote:
> across something from the Python community called 'Installer':
> http://www.mcmillan-inc.com/install5_ann.html

Could you summarize the method they use? I couldn't find a clear
description on the web page. The stuff about archives and appending to an
exe sounds very much like what rbwrap does. But it was a quick hack for a
specific need so may not be something you can use. If you can then feel
free to steal!

Quote:
> To me this seems very doable for ruby too, and a direct port not that hard.
> Anyone has any thoughts on this? I will probably start looking into this
> during the holidays if no one else does before.

Great, good luck!

I'd be interested in hearing about any better ways to find dependencies of
a Ruby program you find. The approach used by rbwrap is a bit crude: run
the script to be wrapped and see what is added to '$.'. The user can also
explicitly name files that should be included. You might want to check out
the design document in rbwrap to see some ways to do (and not do!?) it. I
guess the main other approaches would be to parse all the source files and
analyze them (overkill) or hook into require/load. But there might be
other ways?

Would be great if your solution would work together with the UPX
packer (there were some quirks when I tried to get it to work with
rbwrap but I don't remember the details). UPX works great and can often
reduce the size of executables to 25-40%. And start times can be faster
than without compression since CPU's are fast and discs may not be. And
the uncompress alg is coded in assembler and very fast. And UPX works with
ELF files also (in fact it works on very many platforms). See upx.sf.net.

Regards,

Robert Feldt



Sat, 05 Jun 2004 18:07:24 GMT  
 creating stand-alone versions for easy distribution etc

Quote:


> > hi list,

> Hi Patrik,

> > I was looking around for a way to package a ruby-app of mine for easy
> > distribution to some of my non-ruby/non-programmer friends. I didn't come
> > across anything other than a program by Robert Feldt which was Windows only. I
> > wasn't happy and searched further among other scrpting languages and came

> I think better methods for this are needed so would be great if you have
> the time to work on this!

we'll have to see about the time left to work on this :) but i agree that this
actually is quite an important task.

Quote:
> > across something from the Python community called 'Installer':
> > http://www.mcmillan-inc.com/install5_ann.html

> Could you summarize the method they use? I couldn't find a clear
> description on the web page. The stuff about archives and appending to an
> exe sounds very much like what rbwrap does. But it was a quick hack for a
> specific need so may not be something you can use. If you can then feel
> free to steal!

i actually didn't look into your rbwrap since i recall it was windows only. at
a closer look it might be a lot like what the python application does, in
principle at least.

a description of their approach is at:
http://www.mcmillan-inc.com/standalones.html

Quote:
> > To me this seems very doable for ruby too, and a direct port not that hard.
> > Anyone has any thoughts on this? I will probably start looking into this
> > during the holidays if no one else does before.

> Great, good luck!

> I'd be interested in hearing about any better ways to find dependencies of
> a Ruby program you find. The approach used by rbwrap is a bit crude: run
> the script to be wrapped and see what is added to '$.'. The user can also
> explicitly name files that should be included. You might want to check out
> the design document in rbwrap to see some ways to do (and not do!?) it. I
> guess the main other approaches would be to parse all the source files and
> analyze them (overkill) or hook into require/load. But there might be
> other ways?

> Would be great if your solution would work together with the UPX
> packer (there were some quirks when I tried to get it to work with
> rbwrap but I don't remember the details). UPX works great and can often
> reduce the size of executables to 25-40%. And start times can be faster
> than without compression since CPU's are fast and discs may not be. And
> the uncompress alg is coded in assembler and very fast. And UPX works with
> ELF files also (in fact it works on very many platforms). See upx.sf.net.

i'll look into UPX, never heard of it before.

--
---------------------------------------------------------------------------.
Patrik Sundberg    Address: Rydsv?gen 100C, 584 31 Link?ping, Sweden       |

                   Phone:   +46 13 178567 || +46 707 602240                |
.---> Applied Physics and Electrical Engineering student                   |
|-----> Master of Science in Business Administration and Economics student |
|-------> UNIX/Programming consultant                                      |
`--------------------------------------------------------------------------'



Sat, 05 Jun 2004 18:23:21 GMT  
 creating stand-alone versions for easy distribution etc

Quote:

> i actually didn't look into your rbwrap since i recall it was windows only. at
> a closer look it might be a lot like what the python application does, in
> principle at least.

rbwrap is windows-specific but not very much. The README mentions what you
need to do to make it work on another platform:

Here's what you need to do (I might have missed something...):

        * Make sure find_ruby_binaries identifies all ruby binaries needed
          to run Ruby as a stand-alone app on your platform. Current impl.
          is very Cygwin-specific (and ugly!). I plan to replace it as
soon
          as possible. Any ideas you might have are welcomed.

        * Make sure compiler can be accessed. I currently do
                system "gcc ..."

        * Make memunwrapper.c compilable, linkable and runnable.

            Check file separators. Currently assumes its "\".

            It currently uses some Windows- or Cygwin-specific API calls.
            Nothing fancy and it's straightforward to find corresponding
            calls on your platform:
                GetModuleFileNameA - to get the name of the unwrapper exe
                        This is unnecessary and I plan to take it from
argv
                        instead.
                GetTempPath - Get path to temp dir

Quote:
> a description of their approach is at:
> http://www.mcmillan-inc.com/standalones.html

I guess its more mature than rbwrap so probably focus on their stuff
first?

Good luck,

Robert



Sat, 05 Jun 2004 18:34:02 GMT  
 creating stand-alone versions for easy distribution etc

Quote:


> > i actually didn't look into your rbwrap since i recall it was windows only. at
> > a closer look it might be a lot like what the python application does, in
> > principle at least.

> rbwrap is windows-specific but not very much. The README mentions what you
> need to do to make it work on another platform:

> Here's what you need to do (I might have missed something...):

>         * Make sure find_ruby_binaries identifies all ruby binaries needed
>           to run Ruby as a stand-alone app on your platform. Current impl.
>           is very Cygwin-specific (and ugly!). I plan to replace it as
> soon
>           as possible. Any ideas you might have are welcomed.

>         * Make sure compiler can be accessed. I currently do
>                 system "gcc ..."

>         * Make memunwrapper.c compilable, linkable and runnable.

>             Check file separators. Currently assumes its "\".

>             It currently uses some Windows- or Cygwin-specific API calls.
>             Nothing fancy and it's straightforward to find corresponding
>             calls on your platform:
>                 GetModuleFileNameA - to get the name of the unwrapper exe
>                         This is unnecessary and I plan to take it from
> argv
>                         instead.
>                 GetTempPath - Get path to temp dir

> > a description of their approach is at:
> > http://www.mcmillan-inc.com/standalones.html

> I guess its more mature than rbwrap so probably focus on their stuff
> first?

probably. but for finding dependencies i don't know how much help their
package is, but perhaps some ideas can be copied. I like their idea of
creating an archive (CArchive), like a .jar file,  and modifying the python
'import' somehow.  Exactly how this works I don't know, but my understanding
(as of 20min experience :)) is:

1. analyze your main script and recursivly loaded files etc to get a
dependency list for your application

2. create an archive of these files.

3. create a exe which somehow executes your main script. at the end of this
exe append the archive you created. (executing the main script probably also
uses the method in 4 below)

4. modify require and load to be able to find files also in a archive. this is
done by using the filename of the executable and opening this file and
searching for the archive and creating a archive object from data
(marshalling?)

their are some comments on self-extraction not working with .so files under
unix OS's but I don't quite get this yet. to me it seems doable =)

my ruby solution would be:

1. create a good tool for analyzing dependencies. must also be able to fall
back on explicitly named dependencies.

2. create an archive class for ruby. this would hold just about any file and
have a table of contents to be able to find files.

3. create modified versions of require and load which can use a $ARCHIVEPATH
and a $ARCHIVEARRAY for require/load. in $ARCHIVEPATH we list directories to
search for arhivefiles (which are marshalled versions of archive objects) and
in $ARCHIVEARRAY we put already created archive objects (like the one we will
create from the data at the end of a executable).

4. write a tool which finds dependencies, creates a archive, creates a exe
which will:
  - create a ruby interpreter (link staticly with libruby and we get the
        version used by the packager?) passing any arguments etc.
  - apply the require/load mods
  - read the archive from end of file (using argv[0] to find filename?)
  - create ruby object from data and stuff it into the $ARCHIVEARRAY
  - load the main script using the modified load (i.e from the archive at the
        end of the file)

to me this at a glance seems doable and quite straigt forward :) any
reflections?

--
---------------------------------------------------------------------------.
Patrik Sundberg    Address: Rydsv?gen 100C, 584 31 Link?ping, Sweden       |

                   Phone:   +46 13 178567 || +46 707 602240                |
.---> Applied Physics and Electrical Engineering student                   |
|-----> Master of Science in Business Administration and Economics student |
|-------> UNIX/Programming consultant                                      |
`--------------------------------------------------------------------------'



Sat, 05 Jun 2004 19:16:32 GMT  
 creating stand-alone versions for easy distribution etc

Quote:

> 1. create a good tool for analyzing dependencies. must also be able to fall
> back on explicitly named dependencies.

Make this as stand-alone as possible since other projects will need
it. The recent rdoc discussion springs to mind.

Quote:
> 2. create an archive class for ruby. this would hold just about any file and
> have a table of contents to be able to find files.

> 3. create modified versions of require and load which can use a $ARCHIVEPATH
> and a $ARCHIVEARRAY for require/load. in $ARCHIVEPATH we list directories to
> search for arhivefiles (which are marshalled versions of archive objects) and
> in $ARCHIVEARRAY we put already created archive objects (like the one we will
> create from the data at the end of a executable).

Check out previous discussion on RubyGems. I posted some code that had a
simple Archive class; maybe you can build on it. Was back in
october/november or so. Search for Ryan Leavengood and RubyGems.

Quote:
> 4. write a tool which finds dependencies, creates a archive, creates a exe
> which will:
>   - create a ruby interpreter (link staticly with libruby and we get the
>    version used by the packager?) passing any arguments etc.
>   - apply the require/load mods
>   - read the archive from end of file (using argv[0] to find filename?)
>   - create ruby object from data and stuff it into the $ARCHIVEARRAY
>   - load the main script using the modified load (i.e from the archive at the
>    end of the file)

> to me this at a glance seems doable and quite straigt forward :) any
> reflections?

It should be very doable and useful. It was what I had in mind for rbwrap
but the alpha worked ok for what I needed back then and then I never
updated it.

Regards,

Robert



Sat, 05 Jun 2004 19:48:23 GMT  
 creating stand-alone versions for easy distribution etc

Quote:


> > 1. create a good tool for analyzing dependencies. must also be able to fall
> > back on explicitly named dependencies.

> Make this as stand-alone as possible since other projects will need
> it. The recent rdoc discussion springs to mind.

yes, to my mind also.

Quote:
> > 2. create an archive class for ruby. this would hold just about any file and
> > have a table of contents to be able to find files.

> > 3. create modified versions of require and load which can use a $ARCHIVEPATH
> > and a $ARCHIVEARRAY for require/load. in $ARCHIVEPATH we list directories to
> > search for arhivefiles (which are marshalled versions of archive objects) and
> > in $ARCHIVEARRAY we put already created archive objects (like the one we will
> > create from the data at the end of a executable).

> Check out previous discussion on RubyGems. I posted some code that had a
> simple Archive class; maybe you can build on it. Was back in
> october/november or so. Search for Ryan Leavengood and RubyGems.

I know Hurst also had something along these lines in mind WAY back, will look
into this.

Quote:
> > 4. write a tool which finds dependencies, creates a archive, creates a exe
> > which will:
> >   - create a ruby interpreter (link staticly with libruby and we get the
> >       version used by the packager?) passing any arguments etc.
> >   - apply the require/load mods
> >   - read the archive from end of file (using argv[0] to find filename?)
> >   - create ruby object from data and stuff it into the $ARCHIVEARRAY
> >   - load the main script using the modified load (i.e from the archive at the
> >       end of the file)

> > to me this at a glance seems doable and quite straigt forward :) any
> > reflections?

> It should be very doable and useful. It was what I had in mind for rbwrap
> but the alpha worked ok for what I needed back then and then I never
> updated it.

fine, then i know this seems like a sound idea and something that doesn't
exist. I hope to get some time during the holidays now to actually implement
it :)

--
---------------------------------------------------------------------------.
Patrik Sundberg    Address: Rydsv?gen 100C, 584 31 Link?ping, Sweden       |

                   Phone:   +46 13 178567 || +46 707 602240                |
.---> Applied Physics and Electrical Engineering student                   |
|-----> Master of Science in Business Administration and Economics student |
|-------> UNIX/Programming consultant                                      |
`--------------------------------------------------------------------------'



Sat, 05 Jun 2004 21:18:36 GMT  
 creating stand-alone versions for easy distribution etc

Quote:

> fine, then i know this seems like a sound idea and something that doesn't
> exist. I hope to get some time during the holidays now to actually implement
> it :)

Oh one thing you might want to check how the Python folks solve it is how
to load dll's from memory. I'm sure there is a way but with my limited
knowledge of the Win32 API I couldn't find one. This is of course assuming
you want this to run on win.

/Robert



Sat, 05 Jun 2004 22:11:53 GMT  
 creating stand-alone versions for easy distribution etc

Quote:


> > fine, then i know this seems like a sound idea and something that doesn't
> > exist. I hope to get some time during the holidays now to actually implement
> > it :)

> Oh one thing you might want to check how the Python folks solve it is how
> to load dll's from memory. I'm sure there is a way but with my limited
> knowledge of the Win32 API I couldn't find one. This is of course assuming
> you want this to run on win.

they claim that they do this from what i read, so probably the trick is in
there somewhere. and yes, i would like to have this running under windows, but
i have almost no windows experience and no machine here in my apartment to
expirement with so unix support will come first.

from the python folks it seems windows .dll's are easier to deal with than
elf shared objects, so hopefully the windows part will be painless later on :)

--
---------------------------------------------------------------------------.
Patrik Sundberg    Address: Rydsv?gen 100C, 584 31 Link?ping, Sweden       |

                   Phone:   +46 13 178567 || +46 707 602240                |
.---> Applied Physics and Electrical Engineering student                   |
|-----> Master of Science in Business Administration and Economics student |
|-------> UNIX/Programming consultant                                      |
`--------------------------------------------------------------------------'



Sun, 06 Jun 2004 01:25:38 GMT  
 creating stand-alone versions for easy distribution etc

Quote:

> they claim that they do this from what i read, so probably the trick is in
> there somewhere. and yes, i would like to have this running under windows, but
> i have almost no windows experience and no machine here in my apartment to
> expirement with so unix support will come first.

I can help out with the windows part once you get up and running with some
code.

/Robert Feldt



Sun, 06 Jun 2004 01:41:41 GMT  
 
 [ 10 post ] 

 Relevant Pages 

1. Tkinter: easiest way to create stand-alone dialog?

2. To stand-alone or not to stand-alone

3. How Do You Create Stand Alone Applications?

4. Creating a stand-alone exec???

5. Creating Stand Alone Applications With Oberon-2

6. Tclapp in windows: How to wrap a custom interpreter to create a stand-alone executable

7. How to create one stand alone executable??????

8. Creating a stand alone Python Service (win32)

9. stand alone version of ciforth

10. libs for stand alone programs

11. Can any Smalltalk dialects produce stand-alone DLLs?

12. Newbie: Producing small stand-alone exes for Windows

 

 
Powered by phpBB® Forum Software