is there a way to compile Erlang to be a stand-alone executable?
this means, to run it as an exe without the Erlang runtime.
While it's possible to wrap everything up in a single EXE, you're not going to get away from having an Erlang runtime. Dynamic languages like Erlang can't really be compiled to native x86 code, for instance, due to their nature. There has to be an interpreter in there somewhere.
It's possible to come up with a scheme that bundles the interpreter and all the BEAM files into a single EXE you can double-click and run directly, but that's probably more work than you were wanting to go to. I've seen it done before, but there's rarely a good reason to do it, so I won't bother going into detail on the techniques here.
Instead, I suggest you use the same technique they use for Python's py2exe and py2app programs for creating Windows and Mac OS X executables, respectively. These programs load the program's main module up into a Python interpreter, figure out which other modules it needs using the language's built-in reflection mechanisms, then write out all those compiled modules along with a copy of the language interpreter and a small wrapper program that launches the program's main module with the interpreter. The directory containing those files is then a stand-alone environment, having everything needed to run the program. The only difference in the Erlang case is that python.exe becomes erl.exe, and *.pyc becomes *.beam. The basic idea is still the same.
You can simplify this if you don't need it to work with any arbitrary Erlang program, but only yours. In that case, you just copy the Erlang interpreter and all the .beam files that make up your program into a single directory. You can make this part of your program's Makefile, for instance.
You can then use your favorite setup.exe or MSI creation method for creating a distributable package that installs this collection of files into c:\Program Files\MyProgram on the end user's system and creates a shortcut for "erl mainmodule.beam" in their Start menu. The end user doesn't care that as part of the program they also get a copy of Erlang. That's an implementation detail.
you can use Warp. I've added examples for wrapping an Erlang release.
Related
Recently I though about scaffolding a little CLI with Ruby, but was concerned about using it on a machine with no Ruby installed. I've searched for examples of popular CLI's and found that Docker CLI is built with Go language. I'm able to use this CLI on my computer with no Go installed. How can one build a tool that will not require you to install Ruby?
My guess is that there's a build process involved and it might be compiled to something present on most systems, like shell or smth. Sorry if this is a lame guess/question!
(note: this is not a detailed answer, just a summary of how it works)
Cli programs are just as other programs, there is nothing special about them.
Go is a compiled language - a program called "compiler" takes the go code and translate it directly to machine language, following the conventions imposed by an operative system. It becames pure 0 and 1, no references to anything else. The main advantage is that is self-contained, but you have to recompile it on every different architecture (32bit, arm processors, ...) and operating system (windows, linux, macos) - it's the operating system that take cares of redirecting input and output on cli.
Ruby, instead, is interpreted. There is a program called "Ruby interpreter" which translates your code to the appropriate machine code on the fly. It's a different approach, it's more "high level".
The advantage is that you don't need to recompile the code. However, the "Ruby interpreter" itself must be written in some compiled language.
Confused a little on ruby. I know it makes .rb files, but does it make exe or com files or is it just used as as web application?
I know a bit writing the code, but what to do with the files after.
the question is a bit too broad.
you have to step back and look at how source code in general ends up being executed (i.e. it is used).
In case of some programming languages (e.g. C/C++) it's compiled to a native form and can be executed directly afterwards;
In case of other languages it's compiled to an intermediate form (e.g. Java/C#) and executed by a vm (jvm/clr)
In case of yet other languages is interpreted at runtime (e.g. Ruby/Python).
So in the specific case of Ruby, you have the interpreter that loads the rb files and runs them. This can be in the context of standalone apps or in th e context of a web server, but you almost always have the interpreter making sense of the ruby files. you don't get an executable the same way as the you get for languages that are compiled to machine code.
Normally you just run the .rb file in the shell or command prompt. For example in the windows command prompt:
C:\path\> ruby filename.rb
This will execute the filename.rb file from the command prompt.
If you need to run a ruby program on a computer without a ruby installation there are a few options out there.
Try this website:
https://www.ruby-toolbox.com/categories/packaging_to_executables
I personally have used OCRA to pass a program to relatives who are less computer literate. It was pretty straight forward,I haven't tried the other tools.
Good luck,
I want to install a driver for Ros (robot operating system), and I have two options the binary install and the compile and install from source. I would like to know which installation is better, and what are the advantages and disadvantages of each one.
Source: AKA sourcecode, usually in some sort of tarball or zip file. This is RAW programming language code. You need some sort of compiler (javac for java, gcc for c++, etc.) to create the executable that your computer then runs.
Advantages:
You can see what the source code is which means....
You can edit the end result program to behave differently
Depending on what you're doing, when you compile, you could enable certain optimizations that will work on your machine and ONLY your machine (or one EXACTLY like it). For instance, for some sort of gfx rendering software, you could compile it to enable GPU support, which would increase the rendering speed.
You can create a version of an application for a different OS/Chipset (see Binary below)
Disadvantages:
You have to have your compiler installed
You need to manually install all required libraries, which frequently also need to be compiled (and THEIR libraries need to be installed, etc.) This can easily turn a quick 30-second command into a multi-hour project.
There are any number of things that could go wrong, and if you're not familiar with what the various errors mean, finding support online could be quite difficult.
Binary: This is the actual program that runs. This is the executable that gets created when you compile from source. They typically have all necessary libraries built into them, or install/deploy them as necessary (depending on how the application was written).
Advantages:
It's ready-to-run. If you have a binary designed for your processor and operating system, then chances are you can run the program and everything will work the first time.
Less configuration. You don't have to set up a whole bunch of configuration options to use the program; it just uses a generic default configuration.
If something goes wrong, it should be a little easier to find help online, since the binary is pre-compiled....other people may be using it, which means you are using the EXACT same program as them, not one optimized for your system.
Disadvantages:
You can't see/edit the source code, so you can't get optimizations, or tweak it for your specific application. Additionally, you don't really know what the program is going to do, so there could be nasty surprises waiting for you (this is why Antivirus is useful....although LESS necessary on a linux system).
Your system must be compatible with the Binary. For instance, you can't run a 64-bit application on a 32-bit operating system. You can't run an Intel binary for OS X on an older PowerPC-based G5 Mac.
In summary, which one is "better" is up to you. Only you can decide which one will be necessary for whatever it is you're trying to do. In most cases, using the binary is going to be just fine, and give you the least trouble. Sometimes, though, it is nice to have the source available, if only as documentation.
I've got a makefile (a file called 'Makefile' which is run by cmake in Linux, but works in Windows via nmake I believe and needs to be run in VS command prompt.)
And most of the 'sample' ones I can see are just one line (and the rest appear to be stuff I don't 'yet' understand and then this same one line.
include $(shell rospack find mk)/cmake.mk
(in the terminal rospack find [package] returns the path to said package, and cmake.mk is obviously the file it wants to include)
My problem is, that this appears (to me at least) to be written for use in a Linux system (which basically the entirety of ros, the program I'm working with, was) and in Windows this appears to just try to be
include /cmake.mk
(which unsurprisingly doesn't work)
Basically I need to know how to do the same thing in windows, generally in a 'dynamic' way, as it will only cause more problems down the line if I get this working by hard-coding the directory path and then it breaks because its not set properly some time in the future)
So I guess if this isn't possible or is particularly hard, a way of hard coding it would be a stopgap.
I tried:
include C:\[directory]\cmake.mk
but it seems to have issues with the ':'
I'm trying to work with Windows, because later in my project I'll be needing to use another program (for i90 robot) for which we only have Windows support.
OK, so apparently it acts differently if the file is actually in the folder.
as in
include C:\[directory]\cmake.mk
Errors with
C:\[directory]\cmake.mk not found
if the file isn't there, and
fatal error U1034: syntax error : separator missing
if it is
While this doesn't really seem to impact on the original problem, I guess it indicates I'm trying to do something funky windows doesn't like.
The short answer is, you'll never get a single makefile that does much of anything complicated that will work both with standard UNIX-style make (such as GNU make from GNU/Linux) and also work with nmake. Nmake is a completely different beast.
As an aside, it's confusing that your makefiles here are called "cmake", because cmake is an actual program, distinct from make (and nmake). I'm assuming, though, from the context that the use of the term "cmake" here doesn't refer to the actual cmake utility. Which is too bad, because if it did use cmake things would be simpler for you. Maybe.
It's not clear exactly what your requirement to use nmake is, though. If you laid out your real requirements, it would be a lot easier for us to advise you. For example, you say you need to use a "another program" which runs only on Windows. What does this program do, exactly, and how will you need to use it? Does it provide libraries that need to be linked with the "ros" code?
Basically, your simplest way forward is to obtain a UNIX-like environment, including tools like GNU make, for your Windows system. There are two main choices: Cygwin, which provides a completely POSIX infrastructure including shell, compiler, etc. which are ports of the GNU environment to Windows but require a POSIX layer, and MinGW, which has various GNU tools that run more or less natively on Windows.
However, if you MUST use Visual Studio as your compiler, for example, then these will be much more difficult to integrate.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
An executable Python app
So I have taken a little online python course and I now have an understanding of simple programming. We made our own scrabble game, for example. However what i dont understand is how these .py .c .class or whatever get to an exe form?
I never as an end user have to open .py files ever, with windows it is always .exe, but how are these made? Are they batch files that merely execute the file? But what about dlls?
I guess my question is in any language how is the finished code executed on the machine. When i run a java program i dont have to fiddle with class files i just click an exe.
EDIT......
What i mean isnt how to make python an exe, but how does software get to thatstage full stop. I know interpreted languages go to the interpreter, i guess you use an intermediate language to make an exe which runs the code.
Generally the code would be compiled into an executable, which may or may not internally contain everything it needs to run. (If it doesn't, then it could come packaged in an installer which distributes what it needs.)
Specific to Python, a quick Google search turned up this. For interpreted languages, since there is really no "compile" step, you'd need some tool to "convert [language] to windows exe" to accomplish what you're asking.
Most software you run on Windows is not written in an interpreted language like Python, and comes with an installer ('setup.exe') which was generated by some software that creates installers for your code. The purpose of the installer is to both install your program and all the files it may depend on that you have installed as a developer but your end users don't.
See these related questions:
How can I create a directly-executable cross-platform GUI app using Python?
py2exe - generate single executable file
very simply and speaking generically, you would either compile or interpret you source code. An exe or dll would be the result of compilation (JITs as another item to learn about).
You should also learn about "server side" and "client side" code. A web based application would run server side code which may generate html (and perhaps javascript) and send that down to the client side browser.
There are many ways to deploy exe's, dlls etc - simply copy them to the target machine, or use an installer or via a browser plug in environment.
When you use a compiled language that generates native code, the compiler is responsible to generate an executable file based on your source code.
If the language is interpreted, running the program usually means launching the interpreter and passing it the main file of the program. Some languages offer tools to package the interpreter and the sources into an executable.
If the language is compiled but generates intermediate code, you need to run the virtual machine, like an interpreted language. However, if you use .NET on Windows, the compiler generates an executable that loads the virtual machine automatically.