How Create Makeself Self Executable Archive File in Linux? What Is The Steps to Create Makeself Self Executable File in Any Operating System

How create Makeself self executable archive file in LINUX? What is the steps to create Makeself self executable file in any Operating System?

Here I am giving example of archiving UBUNTU ISO in self executable archive. (This is only for understanding)

1.First download makeself into your machine.

apt install makeself 

              OR

You could download makeself from official website Or Press here
Then you will get file names as makeself-2.4.0.run.
Simply run this file by ./makeself-2.4.0.run .
It will automatically create one directory named as makeself-2.4.0.

• Inside that directory you get makeself.sh script. This is your directly executable script.
  You can use this file instead of apt install makeself.

2.Then create a directory which you want to archive .

mkdir ISO

3.Then copy your ISO file in this directory.

cp <Source Path> <Destination Path>  // Here destination path is ISO

4.Then create a script named as copy.sh

vim Copy.sh

Inside this script write what you want to do with this ISO.
SO I want to copy this ISO into my /home/Downloads folder. So I write in script

#!/bin/bash
cp -r <filename> /home/Downloads
echo "File Copied Successfully"

##// Remember This script will automatically run after extracting this folder //

Give permssion to script

chmod 777 Copy.sh

then

cd ..

So now you have 1 ISO directory and in that directory 1 ISO(UBUNTU iso) file and 1 script(Copy.sh).

5.Now run this command

makeself --pbzip2 ISO Copy_ISO.run "Copying ISO File" ./Copy.sh

here,

• pbzip2 --- Use pbzip2 instead of gzip for better and faster compression on machines having
  multiple CPUs. (you can use any zipping algorithm mentioned in here)
• ISO --- It is the name of the directory that contains the files to be archived
• Copy_ISO.run --- It is the name of the archive to be created
• "Copying ISO File" --- It is an arbitrary text string describing the package. It will be
  displayed while extracting the files.
• ./Copy.sh --- It is startup_script. It is the command to be executed from within the directory
  of extracted files.

It will generate Copy_ISO.run file.

So you can run this Copy_ISO.run file on any system.

6.Command to run is -->

./Copy_ISO.run

This will copy your UBUNTU ISO file in /home/ directory. You can run this script on any system. You don't need to carry another zip file of UBUNTU ISO.

How do I deploy Node.js applications as a single executable file?

Meanwhile I have found the (for me) perfect solution: nexe, which creates a single executable from a Node.js application including all of its modules.

It's the next best thing to an ideal solution.

CCSprite memory: file VS frame

1. You are not right. In both cases image will be placed into the memory only once. You can check spriteWithFile: code. It tries to find sprite frame in the sprite frame cache and load it only if there is no needed frame was found.

2. Using spritesheets help to save memory. For example, for image with size 129x129 will be created texture with size 256x256. But you can add many of such images in one spritesheet and only one big texture will be created( i mean, it there will be spritesheet 1024x1024 or 2048x2048 there will be only one texture with the same size).

Packaging and shipping a python library and scripts, the professional way

This is not a complete answer but just a bunch of ideas. I wrote an installer for a client that incorporated some ideas that might be useful to you.

It was Linux only so I focussed on just that. We needed to ship specific custom versions of mySQL, lighttpd, python, memcached, a few 3rd party Python modules and some custom scripts. We needed to launch all these services without any problems and let the user control them using regular initscripts. It should work fine on a bunch of popular distros and therefore shouldn't rely on distro specific stuff.

What I did was as follows.

1. Created a 500MB (I'm don't recollect the size) file and formatted it as an ext3fs file system.
2. Mounted it at a point using a loopback device.
3. Ran deb-bootstrap on the mountpoint to create a custom Debian install.
4. Chrooted inside the partition and then ran a bunch of scripts which did an apt-get install on all our dependencies, installed all the eggs and other packages which were necessary for the app, installed the app itself in /opt (inside the chroot), installed supervisord (to do process management) and set things up. Now, this partition was a completely self contained Linux filesystem that contained the application and everything needed to run it. You could dump it anywhere, chroot inside it and launch the app. The only dependency it had with the outside world were the ports it would use for its services and the supervisord control socket. This was the main point. We were able to include exactly what we needed (compiled files, .pycs only etc.) for a few of the applications and didn't have to bother with any limitations in standard installation tools.
5. After this, we packaged a few extra scripts that would go into the external operating system. These were custom made for each distro that we would have to support. This part was distro specific. There were scripts that would go into /etc/init.d and some scripts that would setup the database and stuff at the beginning.
6. We then created an archive of the entire filesystem using makeself. It would checksum stuff and all that and provide a self extracting archive which if run would untar the whole thing into /opt on the host machine, chroot inside the directory and run a setup script that would ask the user a few questions like db username/password etc. and set things up. After that, it would fetch the scripts I mentioned in step 5 and put them on the host OS.

The initscripts would simply chroot into the partition and start supervisord. It would then take care of launching all the services we cared about. Shutting down the application was simply a matter of connecting to running supervisord and running a command. We wrapped this in the initscript so that the user experience was UNIX like.

Now, we'd give clients the self extracting .run file. They'd run it, get asked a few questions and it would create a directory under /opt which contained our app and all it's dependencies. The init scripts would be modified to start our app on bootup and things would work as expected.

I think step 4 gives you the freedom to install whatever you want, however you want so that things would work fine.

---

Related Topics