I'm a student. I have made a small language for computer-architectural simulations as a part of my project. I have made a parser+translator for this language using Antlr3. Stuff written in my language gets translated to C++ code, which can be compiled and executed by the user to run the simulation.
I don't have any experience in packaging software (that is, making it suitable for others to install and use easily). Although currently I'm the only one using it, I would like to know what is a good way to package it, so I can share it with others.
I want to package:
antlr generated Lexer+Parser for my language
code that wraps around the antlr-generated stuff
the antlr C runtime library.
How can I distribute all this as a translator for my language?
I remember that when I installed the C runtime library, stuff that was specific to my machine/OS was taken care of. (For example, how end-of-file is represented). Should I assume users of my translator have installed the C runtime separately?
Thanks,
-neha
You want to package it for.... what?
RPM (e.g. CentOS) read here: http://www.gurulabs.com/downloads/GURULABS-RPM-LAB/GURULABS-RPM-GUIDE-v1.0.PDF
For Debian: http://wiki.debian.org/HowToPackageForDebian
On OsX, package via homebrew: https://github.com/mxcl/homebrew/wiki/Formula-Cookbook
Related
Is there any current, relatively simple way to compile and upload full .c/.cpp files for the Arduino DUE on Linux?
I'm beginning to regularly run into issues using the boilerplate code they provide around the sketches and so far, there is very little in the way of documentation or alternative IDE support for the arduino 1.5 SDK... That and the official 1.0.5 IDE is hopelessly broken for linux right now (serial port issues among other things).
There is a great example here.
He explains what you need and how to use it to be able to upload to the due from the terminal of a linux box.
He has done a great job in helping you set up an environment to compile and upload your c programs onto the SAM3X8E. He even gives you a makefile and sample code. What more could you ask for?
Give it a try, see if it works for you.
Even though you can program in c/c++ for the arduio, the arduino does not "use" c/c++ code alone per se. When you use the IDE for arduino, a few libraries are linked when compiled to give you the "arduino" functions like setup(), and loop() as well as constants such as HIGH and LOW. The arduino language is based off a language called Processing which is written in c.
If you are having troubles with the Arduino IDE, it might help to download an older version. Check out the Previous Releases page on their website.
If that still doesn't work, you could try to build it from the source code. https://code.google.com/p/arduino/wiki/BuildingArduino
I wanted to do the same thing as I really don't like IDE like Eclipse. And I didn't want to rely on Arduino environment. Just something minimalist under ubuntu.
For libraries, I downloaded the ASF (Atmel Software Framework) here http://www.atmel.com/tools/avrsoftwareframework.aspx
For compiling, I installed gcc-arm-embedded from here https://launchpad.net/~terry.guo/+archive/ubuntu/gcc-arm-embedded. This provides gcc-arm-none-eabi.
The last part is 'bossac', the upload tool (just do an apt-get install bossa-cli).
Then, just use Vim or your fav editor, adapt a config.mk (configuration of the ASF's MakeFile) for your own project and once okay, upload the .bin to your board with bossac.
Note that bossac has to be run as root (sudo) if you want it to detect your usb port (/dev/ACM0).
After few days playing with examples provided by the ASF library, you'll be able to use a small subset of headers files (only basic definitions like registers names, bits function names in registers ...) to help you and do all the rest by yourself. I personally even don't use 'drivers' files anymore. I directly access registers with my own methods to get smaller code.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
What’s the best way to distribute a binary application for Linux?
We would like publish a proprietary game in Linux. The game is relatively simple, has a custom engine written in C++. We have been using the MinGW compiler on Windows and one person does programming and testing in Linux with the g++ compiler.
The game is written exclusively using open source libraries, which are all cross-platform.
What is the recommended way to make a program for Linux work across all Linux distributions without requiring packaging for any of them? The ideal way for me would be to package it as a .zip or tarball and provide that a download, just like good ol' .exe files under Windows that work with system libraries.
Most games I've played under Linux that provide such downloads offer a shell script (which is a compatibility problem in itself!) that launches it. I have no problem with it, but it reeks of user-unfriendliness. Additionally, a lot of games require additional libraries. For instance, SDL 2.0, the hardware-accelerated new-version of the popular library, is not yet available in most distributions' repositories yet several games are known to use it, and I had to compile it myself. This is even worse.
I would like a solution whereby a customer can click on the binary file in their file manager of choice, and it would run, no 'apt-getting' or 'yumming' of the necessary libraries. I don't mind breaking standards, and if it has to go in /opt, it will.
I would like a solution whereby a customer can click on the binary file in their file manager of choice, and it would run, no 'apt-getting' or 'yumming'. I don't mind breaking standards, and if it has to go in /opt, it will.
First, you have to understand that "yumming" and "apt-getting" are not really the actual installers of the applications (packages), they are simply the front-end programs used to look up / download / update / trace packages on the repositories (from the distro and others that you manually add). So, when you say "no 'apt-getting' or 'yumming'", we have to assume that you mean that you don't want to put up your game on a repository, which makes sense if you want people to pay to get your game (as opposed to other proprietary but free software like flash, graphics drivers, video codecs, and other things you typically find in repositories).
So, there are really just two types of package management systems, RPM and DEB, which use a command-line program, rpm and dpkg, respectively, to actually do the installation. Most distributions also come with a GUI front-end for those programs too (not the Synaptic-style package management software (which is a GUI front-end to apt-get or yum), but something simpler). When you double-click on a .deb or .rpm file, on most distros, you get this GUI front-end to pop up asking you for admin credentials and telling you about dependencies that are required, and, obviously, that you are about to install this package onto your system. From what I can tell, this is exactly what you want. And so, what you need to provide is a .deb file (for Debian distros) and a .rpm (for Red Hat distros), for both 32bit and 64bit versions of your game, just like I would assume you provide a .msi file for your Windows versions.
As for dependencies that might be hard for users to locate. What you should do is include in some directory of your installer a number of additional ('recommended' version) packages for these esoteric dependencies so that they can be installed from those offline packages if a newer version cannot be fetched from the distro's repositories. And that's about it.
And you can either make people pay to get the deb or rpm installers for your game, or include some kind of license-key system to unlock the game (and thus, make the deb/rpm files available for download, and charge for the key / code to unlock it).
The ideal way for me would be to package it as a .zip or tarball and provide that a download, just like good ol' .exe files under Windows that work with system libraries.
Ideal? Really!?! Yeah, if all you do is use system libraries, then it will work. But if there is anything more, it will be a nightmare (nearly as bad as it is under Windows of you don't rely on installers).
The game is written exclusively using open source libraries, which are all cross-platform.
Make sure none of those open source libraries are GPL-licensed, because if that's the case, you can't make your game proprietary. Your dependencies must be licensed under LGPL or BSD, or similar licenses, so watch out for that.
What is the recommended way to make a program for Linux work across
all Linux distributions without requiring packaging for any of them?
That is not recommended to begin with. So you need the less unrecommended way of doing that. I guess that would mean producing a statically linked binary (and you would need a 32bit and a 64bit version anyway).
The recommended way would be to decide a distribution system (RPM, DEB, ...) and verify dependencies on the various target platforms. Then the user could click on the installer package - much like he/she would do with a Windows MSI file - and be also able to uninstall/upgrade the program later on.
Note that in practice you would have to provide testbed environments for the target platforms even if you distributed the static binary, since you can't avoid doing tests. At that point, packaging the RPM/DEB/etc is not really a significant increase in time expenditure; and on the other hand, it would make the package much tighter and easier to download and install.
I am currently working on an opensource C++ project. I don't have much experience in C++ as my daily job mainly involves with Java. I am now planning to release my C++ project and I would like to know how should I should I arrange the packaging of my project. E.g, in Java, all the class files are packaged into jar file. So what is the equivalent approach in C++? Is there any good practise for organizing the source code/binary? My target platform is Linux by the way.
Another question is I am currently using Eclipse CDT plugin for development and building. So is there anyway that I can extract build script from Eclipse project and use it as generic build script? Is there any good reference regarding C++ build/packaging? Thanks in advance.
Edited
To clarify a bit more, I think the release of my project can be considered as an application. It's a command line tool for software configuration management.
I am currently working on an opensource C++ project.
That simplifies many things. You should supply the build scripts for you project and support them for different use cases (learn about Makefiles, there are similar concepts like "target").
I don't have much experience in C++ as my daily job mainly involves with Java.
Most of the things you're used to have (and ask for right now) in Java are invented because they lack in C/C++. Learn at least something about dynamic(shared)/static libraries (.so and .a files to be simple).
I am now planning to release my C++ project and I would like to know how should I should I arrange the packaging of my project.
The "packaging of a C++ project" is something informal. You may supply the sources, build scripts and some project-files for the well-known IDEs.
EDIT: you've specified that you're building the command-line application. I believe all you need is to start from a simple Makfile for that application. The reference Makefile can be automatically generated by Eclipse. If you are planning to deploy your application as a stand-alone software, then you have to earn about packaging (rpm, deb, tgz).
E.g, in Java, all the class files are packaged into jar file.
There are no such thing as a C++ "package" compatible accross compilers (even the "modules" were rejected in the latest C++11 standard)
because there is no binary standard to encode C++ classes (ABI). On linux you're most likely going to use GCC (or Intel's compiler, or LLVM's CLang, or custom build of OpenWatcom or...),
but the version of standard library you are linking to makes the release of binary builds close to useless.
That is the reason for redistibuting source code.
So what is the equivalent approach in C++?
No clear answer here.
Is there any good practise for organizing the source code/binary?
Look at the large-scale projects, see the way they organize their builds. The term "build engineer" as an occupation emphasizes the difficulties of large-scale projects compilation/linking.
My target platform is Linux by the way.
This is also something of an incomplete description. "Linux" is a blurry term. You should speak about the Linux distribution, compiler toolchain and package manager. E.g., Ubuntu 12, amd64, GCC 4.6 toolchain, APT package manager.
There are different "linuxes" built around the same kernel source. There are different compilers. There are at least three major package managers to consider: Debian/Ubuntu(deb,apt), Red Hat(rpm), Slackware(tgz).
Another question is I am currently using Eclipse CDT plugin for development and building. So is there anyway that I can extract build script from Eclipse project
There's a sort of "meta-technique": you write a "description" of your project and then a tool generates the project-file and build scripts for your sources. Have a look at CMake. Since you're on "linux", try looking at the somewhat standard way of autotools (autoconf).
Is there any good reference regarding C++ build/packaging?
You should start by building your application and then move on to the deployment issues. C/C++ is a hard-to-learn legacy with a lot of subtleties which are avoided in Java.
I found SCons, which looks useful, but it's not exactly what I'm looking for. I don't really want a build tool; what I really want is a package manager.
Other languages have similar tools:
Python- easy_install or ppp
JavaScript/NodeJS- npm
Go- goinstall
I would like to have a single database of open-source D projects that can be integrated into a larger application with only a couple commands, such as (assuming dpack is the command):
# get source from database, run build script if there is one
dpack install some_package
# builds current package, grabbing dependencies as necessary
dpack build
# removes source (build will fail without it)
dpack remove
Is there anything like this for D? If not, I'll probably end up writing it myself.
I found this,
http://code.dlang.org/about
It distrubute something called DUB packages.
DUB is s build tool for D projects with support for automatically retrieving dependencies and integrating them in the build process. The design emphasis is on maximum simplicity for simple projects, while providing the opportunity to customize things when needed.
Update: Please see the top rated answer about Dub. It is now the defacto package manager for D and will soon to be the official package manager which will be included with D compilers.
There have been several attempts by various people and a lot of discussion. The only one I know of that is actively being worked on is Orbit by Jacob Carlborg.
I don't think it's being actively worked on, but you could take a look at DSSS
DSSS, the D Shared Software System, builds upon rebuild and intends to
create a standardized system for building, installing, configuring,
acquiring and using D software, licensed as Free and Open Source
Software under the MIT license:
http://www.opensource.org/licenses/mit-license.php . One notable
component of it is its net module, which provides an analogue to
Perl's CPAN or Ruby's Gems for the D programming language.
http://www.dsource.org/projects/dsss
Some time has already passed since the original question (and answers) has been posted, but in late 2021 DUB (https://github.com/dlang/dub) comes preinstalled with DMD (the reference compiler), and there is a central repository of packages available at https://code.dlang.org/.
If you use other compilers (GDC, LDC etc.) you might still need to install DUB manually and use e.g. dub --compiler=gdc ...
I am working on a large open source C++ program that uses the R standalone library (libRmath, Ubuntu/Debian package r-mathlib). I want to remove this dependency: I'd like to include the source code from the R standalone library in my source tree, without the entire R source code. Can this be done?
Unfortunately, the R standalone library seems tightly coupled to the rest of the R code. In the standard R source tarball, the same configure script is used for the main package and the standalone library. This configure script doesn't play well on different platforms. I am hoping that the standalone library is available as its own "standalone" source tree.
Related note: I've looked at the Rinside library, particularly via this thread. I think the method I am describing would make distribution easier, for 2 reasons: 1) users that already have R installed won't have to reconfigure their installation (and can maintain a different version as their default installation); 2) users without R won't have to install it.
Update: fixed a typo - I'd originally referred to Rinside as Rinclude
A few points for you:
Can this be done? Of course it can, just copy and paste the code for r-mathlib into your project. The licensing for that library is a very liberal LGPL. Now, is it a good idea? I don't think so. Shared libraries have upside in that you get bugfixes, easier and shorter build etc/
Seems tightly coupled to the rest of the R code. No, that is factually incorrect. The whole point of r-mathlib is that you can depend just on it. I think it may still needs R headers on your system but if you define the MATHLIB_STANDALONE variable. E.g., on my Ubuntu box I just did gcc -o /tmp/rmathTest /usr/share/doc/r-mathlib/examples/test.c -lRmath -lm and the resulting binary depends on libRmath alone, not libR.
Configure script doesn't play well on other platforms. That is a bold statement, don't make it anywhere near Prof Ripley. R is amazingly portable, and I fear your claim is a little lacking in empirical basics here.
What you are after can be done in different ways, and has been done in different ways.
And yes there is ample documentation as well. Start with 'Writing R Extensions' and 'R Admin + Inst' and by all means come back with follow-up questions.
Lastly, in case you change your mind and you do want R inside C++, you may want to consider RInside as well. That does however create a depedencies on R, Rcpp and RInside itself.