I've just tried to generate *.exe files from Perl scripts by using Par::Packer, the tool works fine as expected.
The situation now is I would like to distribute my Perl based application as a group of utilities (exe files), for each of them there is a corresponding Perl scripts, and they are sharing some common modules (including Perl stuff) pretty much. This results in each of the generated *exe files are bloated by similar codes.
I tried to attach --dependency option to pp, which reduce the size in some extent, while it just move the perl.dll out of the packaged file, the common modules are still there. I think there should be some other approaches to resolve this.
Any suggestions? Thank you in advance.
http://cava.co.uk/ provides that out of the box, allows you to easily create a .msi style installer, with however many scripts you want available as .exe files (and all modules and everything else required is shared)
You could also pack Par::WebStart's perlws, and pack each app using its make_par, then invoke each app using appshortcut.lnk or appshortcut.bat, or appshortcut.exe which just does system "perlws.exe appshortcut.pnlp"
or you could turn all your utilities into modules (you should do that anyway), and then pack them all with pp into a single single .exe, then create
foo.exe bar.exe baz.exe ... which just do system "mybigexe.exe foo.exe"
change the icons... with exe_update (from cpan)
Related
I am developing an OS for embedded devices that runs bytecode. Basically, a micro JVM.
In the process of doing so, I am able to compile and run Java applications to bytecode(ish) and flash that on, for instance, an Atmega1284P.
Now I've added support for C applications: I compile and process it using several tools and with some manual editing I eventually get bytecode that runs on my OS.
The process is very cumbersome and heavy and I would like to automate it.
Currently, I am using makefiles for automatic compilation and flashing of the Java applications & OS to devices.
All steps, roughly, for a C application are as follows and consist of consecutive manual steps:
(1) Use Docker to run a Linux container with lljvm that compiles a .c file to a .class file (see also https://github.com/davidar/lljvm/tree/master)
(2) convert this c.class file to a jasmin file (https://github.com/davidar/jasmin) using the ClassFileAnalyzer tool (http://classfileanalyzer.javaseiten.de/)
(3) manually edit this jasmin file in a text editor by replacing/adjusting some strings
(4) convert the modified jasmin file to a .class file again using jasmin
(5) put this .class file in a folder where the rest of my makefiles (the ones that already make and deploy the OS and class files from Java apps) can take over.
Current options seem to be just keep using makefiles but this is a bit unwieldly (I already have 5 different makefiles and this would further extend that chain). I've also read a bit about scons. In essence, I'm wondering which are some recommended tools or a good approach for complicated builds.
Hopefully this may help a bit, but the question as such could probably be a subject for a heated discussion without much helpful results.
As pointed out in the comments by others, you really need to automate the steps starting with your .c file to the point you can integrated it with the rest of your system.
There is generally nothing wrong with make and you would not win too much by switching to SCons. You'd get more ways to express what you want to do. Among other things meaning that if you wanted to write that automation directly inside the build system and its rules, you could also use Python and not only shell (should that be of a concern though, you could just as well call that Python code from make). But the essence of target, prerequisite, recipe is still there. And with that need for writing necessary automation for those .c to integration steps.
If you really wanted to look into alternative options. bazel might be of interest to you. The downside being the initial effort to write the necessary rules to fit your needs could be costly. And depending on size of your project, might just be too much. On the other hand once done with that, it'd be very easy to use (apply those rules on growing code base) and you could also ditch the container and rely on its more lightweight sand-boxing and external rules to get the tools and bits you need for your build... all with a single system for build description.
Just out of curiosity, I would like to understand the behaviors of those self contained installer programs and try to write a simple installer myself.
I did some search on Google and did not really find a useful article explaining it. However AFAIK, an installer should have a small chunk of code residing in the top of the executable. It pulls data out from the rear of the executable and interprets them as files according to an inventory file (probably xml?). Other operations such as writing register entries can also be specified in the inventory file.
Now is my guess of the file structure true? If so I think I just need to read about the PE format and then it would be conceptually easy for me to implement it. If my guess is wrong, I would love to know how exactly it works.
Thanks for your time!
Normally installer packages are self-contained compressed executables (SFX) that contains:
A small installer executable
A compressed file structure with files to extract
Some configuration files (xml, ini, json, properties) to define file destinations, registry entries, desktop/start menu shortcuts, instalation modes
Extra files (dll, icon/image resources) to make the installer work.
For MSI packages, it's a bit more complex. It's a propietary format packaged as a SQL database in a COM structured storage file. It contains also a virtual file system inside the installation package (file access using file streams).
You can review some free tools and check many typical features to make installer executables like:
Wix (For MSI installers) http://wixtoolset.org/
Nullsoft Installer (NSIS) http://nsis.sourceforge.net/Main_Page
Inno Setup http://www.jrsoftware.org/isinfo.php
For Windows it's pretty much
Declarative: MSI, AppX, ClickOnce
Imperative: any number of third party tools, scripts and home grown EXEs
MSI is typically your best choice. The runtime is already part of windows so when you double click the MSI database MSIEXEC takes over. The point of the declarative models is to separate what needs to be done from how you do it. The imperative models are basically some simple to complex framework to write procedural code to do the actual installation work.
It's far to broad of a question to ask in detail how any of these work at a low level. For MSI it's all in the Windows Platform SDK documentation on MSDN.
I'm using JavaFX to build a GUI for the software I'm working on. I call it software but it's actually a series of automated steps, compiled into a standalone .exe file. I have about 6 of these executable files, which is why I'm building a GUI to act as the front-end, main menu of sorts.
Ideally I'd have the entire package (GUI, exes) combined into one file Jar which I'd then send to clients, or wrap it with JSmooth or Launch4j.
Questions:
1) Is it possible to combine all 6 .exe files into a package along with the GUI.? So if I click button 2 on the GUI, it runs .exe #2, etc. Which concepts should I understand?
2) Is this best practice, or is there a better method? I'm new to Java which is why I haven't built the entire software with it, just the GUI.
3) I've read that its best to extract the exe from the parent jar (or exe?) into a temp file on the users PC. Is this correct? Even for multiple wrapped exes?
Any answer is helpful. I'm trying to avoid building something only to realize I can't do what I needed. Thanks
It would be much easier to write an answer if you were a bit more specific regarding what those 6 .exe files do. Nevertheless, a few things can be pointed out. Answers are in the same order as questions.
Yes, you can package exe files into a jar. No, you can't run exe from within the jar. A common solution is to unpack exe either temporarily (while your application is active) or permanently, and then tell OS to execute it.
I'm not entirely sure what "best practice" refers to in your question. Ideally, your logic (back-end) code would be written in Java and all your 6 exe files would be a part of a single Java application. I respect that you are new to Java, so in your particular case having a front-end to your executables is perfectly fine. However, do keep in mind that your solution is Windows specific, unless you plan to provide other OS executables too.
Yes, you will need to extract the exe files. It doesn't really matter what parent executable you use (exe or jar). For the sake of simplicity, I'd go with the jar, because you won't need to use any 3rd party software to build such a jar.
Just to sum up, considering your situation, package your JavaFX app and the .exe files into a single executable jar. When the user needs to execute an ".exe", extract that ".exe" into the same directory where JavaFX is running from. When the app exits, delete all ".exe" files from that directory
Is it hard to compile software so that it is a single .exe file? I have been publishing the program in the traditional manner and the resultant program consists of a setup file and a couple data files. Ideally I would like to have a lone exe that runs program without having to install.
In general, if you're using Visual Basic, you'll always need to, at a minimum, guarantee the target computer has the proper .NET Framework installed.
If that's the case, then you can just deploy your .exe from your Console or WIndows Application project, and it will work, provided you don't use any references or types outside of the standard framework types. If you have any assemblies you use, or require any extra data to exist, then an installer is the correct way to go.
In general, building an installer makes sure that all of the dependencies are in place, which is why it's the "traditional" manner of publishing. Without that, you (or somebody) has to verify the dependencies before running your program manually.
I would like to create an installer of my program.
However because the installation is quite complicated, I need something more advanced than installshield limited edition.
I have to run another installer from my current one. It doesn't matter if the user press "cancel" or installs the program, I just need to run it.
I have to install a directory structure on user computer which has a lot of files, that's why i'm going mad with wix: 100 files and I should write all of them with my hands in that xml file? Are we mad?
I have to install files from point 2 into a registry key. That's why I was using wix
I played with nsis long time ago and I liked it, but the language is not so nice.
Wix has "similar" problem. I would love using something like C# and things like that otherwise I'll stick with wix but I need a way to add files faster to xml file, can't add 100 files manually.
Any suggestion?
You can give Advanced Installer a try. It has folder synchronization, which means it can batch add contents of folders, with the possibility to filter out certain file name patterns, for example you'd want to filter *.pdb files and add all the rest to the project automatically.
I use it myself and never had a problem.
Wix Heat can generate the wxs source files for you.
You should look at InnoSetup. It has an IDE available that allows drag and drop of files (and multiple select in a file selection dialog), can launch other applications (including additional setup files), create and modify registry settings, and supports pretty complex scripting if needed. It's pretty easy to use, and the documentation is pretty good. It comes with pretty comprehensive sample installations, too.
The installation scripts are created by the IDE and then compiled into an installer, so the script source is editable by hand if needed. It's also not XML, but more like an INI file, so it's a little easier to work with manually as well.
Best of all it's free, and so is the IDE.
I would go back to using NSIS, if you use the HMNSIS editor http://hmne.sourceforge.net/ to write your scripts you can use the Wizard mode to make a list of the files and directory structure you will use in your installer.
Running other installers and registry settings are also easily done with NSIS.