Well, the absolute bare minimum, operating entirely on the pi, is
1) Use the nano editor to create the following file, and name it adios.c:
#include
int main (int argc, char *argv[]) { printf ("Adios, el mundo.\n"); return 0; } /* main */
2) run this command:
gcc adios.c -o adios
3) run this command:
./adios
3a) Optional. Run this command to confirm just what gcc has built for you:
file adios
That's it. (This has worked on my Linux desktop, and also on a Raspberry Pi running Raspbian.) Obviously this technique is at its best with "Hello World" kinds of program, but IIRC, you can add extra source modules just by naming them on the gcc command line along with adios.c . The "-o adios" argument is optional, but without it your executable output will be put in a file called a.out .
Have you ever written and compiled a program before?
--
Ineptocracy
(in-ep-toc?-ra-cy) ? a system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers.
That rather depends how much compiling of complex projects you're going to be doing.
In the long run the extra time and effort spent setting up a cross compiling environment will be saved many times over by moving that to a powerful development system.
On the other hand obviously for "hello world" or its LED blinking equivalent, a cross compiler is overkill :)
Yep, Python install includes IDLE, and is on the PI.
Neither is included, but may be installed via Ethernet.
This also may be installed, but not included.
Here is something I need to learn. I have yet to compile anything.
Yes, you may be better off trying to work on the PI than to set up a cross compiler. I still program in ASM on the Apple IIgs rather than use a cross-assembler. It is easier for me.
Get used to using 'make' to run gcc. This mostly involves learning how to specify dependency trees in the Makefile. The Makefile file describes the steps needed to compile your project (compiling all source files and linking the compiler output to create a runnable program file. Better yet, it does the minimum work needed to recompile just the sources you've changed, so compilation is always as fast as possible. Running C compilations with make will save you time, mistakes and a lot of typing. A complete rebuild of even a complex program typically just needs the "make" command to be entered.
If you're going to use Python, you can do more or less the same, though many Python developers use the IDLE IDE instead.
make, gcc all the development libraries needed for writing C programs are included in the standard Raspbian card image along with the manpages describing them.
Similarly, the Python runtime and development system plus IDLE and the relevant documentation are also included in the standard Raspbian card image.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
It might help if you told us how much programming experience you currently have, in which languages, on which platforms, using which tools.
Some of the answers given so far assume a reasonable amount of development experience, wheras your questions seem to hint at a lack of awareness of the compiling process and architecture specific libraries.
Interpreted languages such as Perl give you the ability to develop and test code on a PC then move the code to the Pi once it is working.
With your background you may find a copy of "Linux in a Nutshell" useful. Its fairly terse, but contains a lot of useful stuff in a small package and is organised well enough to be useful for reference as well as a Linux/bash tutorial.
I also hear good things about "Linux for Dummies", though you can do without that if you've bought the "Raspberry Pi User Guide".
Despite some tooth-gritting its not a bad idea to have some familiarity with vi because one of its benefits is that if things really come apart it remains quite useable even when you can't use the function keys and the console thinks its been reborn as a dumb glass teletype. That said, none of my Linuxes have ever come unstuck to anything like that degree (I've never had to resort to single user mode in 15 years of using it) but its still good to be prepared for the worst. Besides, if you get your head around its global replace modes its extremely powerful. I tried nano and don't care if I never see it again. gedit is OK on a GUI desktop, but I normally use microEmacs in a terminal window and yes, one of the first things I did with my RPi was to port microEmacs over from one of my Fedora systems. Took all of 5 minutes to be up and running once I'd compiled and installed libtermcap, downloaded from the Free Software Foundation, and copied /etc/termcap from the Fedora box. HTH Martin
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
Does Windows come with a full set of development tools ready to go? Or even the runtimes that are needed by a load of popular software? Or do you perhaps have to figure out where that software is, download and install it?
- microEmacs is not a mainstream editor outside the OS/9 68000 world, something that has always surprised me since its very easy to port (I've ported and run it on OS/9, DOS, Win95, NCR Unix and Linux without ever needing to do more than edit a list of environmental options) and has worked key-for-key the same in all these places.
- it uses termcap for screen manipulation and keyboard definition. Most people consider termcap to have been obsoleted by terminfo, but the latter isn't as flexible, which is why microEmacs uses it.
Now look at it the other way up. If the program I want is part of my distro I can install the package that contains it, which automatically downloads the latest version of the package and any additional libraries it needs, installs them all (including documentation) and its all ready to rock'n roll in a minute or two unless its a huge package. If I need something that isn't mainstream enough to be part of the distro, I can grab its latest source tarball, untar it and then run:
make configure; make all; make install
and be using the program only 5-10 minutes later.
With all due respect, you can't do that so easily with Windows because:
1) Windows hasn't anything like the one stop package library thats part of every Linux distro for the very good reason that almost all app vendors wouldn't trust anybody to manage it: M$ has a long and gory history of cloning copies of 3rd party apps and putting the original author out of business. The end result is that you have first to spend finding the the app you want, while in Linux you mostly just run "apt-get install package" (Debian) or "yum install package" (RedHat)
2) Most Windows systems don't have any development tools installed or even available unless you but them (or install djgpp or mingw for C or the Java JDK). I don't think there are any Linux distros that don't include a full set of development tools as standard components, i.e. as a Windows user you're not in any position to install an app from source, even if you want to, without spending the time to install and configure a development environment.
I mean, you want to run the RPi in headless mode but you don't even have an SSH client or an Xterm server installed by default on your Windows box.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
If you need a full set of development tools, you are almost by definition not an average Windows luser, and so will be able to easily find the tools you need. As a luser, I expect stuff to "just work", and under Windows, 99+% of the time, it does exactly that. Under Linux, every installation seems to be an adventure.
One example I installed yesterday is a Video editing program designed for Windows 98. I installed it under XP, and it came with the required version of Quicktime Pro, which it uses to generate ,mov files. It "just worked". It also "just works" under Vista and Windows 7.
If Windows software needs a particular version of a runtime package, it will either include it in the program install package or will know the place to download it from, usually with minimal user interaction.
My experiences of GNU Linux over the years have included many instances of failed software installations where required runtimes aren't available and have to be searched for (They weren't in the depository for the distribution or on the developer's website), as well as quite a few (Mostly hardware driver) programs that required me to rebuild the kernel. I've never yet had to rebuild a Windows kernel.
Linux (IMO) can probably best be thought of as either a hobbyists's learning system or as a turnkey system, with all user changes locked out. There is a specialist market, where the users are programmers writing stuff for others to use, but that market also exists and is catered for in Windows, as well as Android and any other OS you care to mention..
Linux comes with around 23000 (!) bundled applications. This is why you need to get your head around apt, the package manager for debian/ubuntu. (You may use synaptic, the graphical front end too. But that needs apt, the command-line utility to get installed in the first place)
If microemacs is ported, you just say
"apt-get install microemacs", and it will find all dependencies etc.
If you are looking for a package, "apt-cache search target" will look for "target" in the respository.
When you have experience with Windows, you know that it does
*absolutely nothing* out of the box, apart from playing solitaire and in some later versions browsing the internet.
For everything else you need to install software. Even for editing (apart from some rudimentary keying in of text, not suitable for program development) you need to install (and often BUY) additional software.
Not so with Linux. It normally comes with a set of standard editors already installed. And the most versatile of them are "vi" and "emacs".
It is not at all necessary to compile programs like that, this is just what the poster did. You can install binary packages just as well, and some of them are installed by default.
When you have experience with "vi" (I have spent my 30 years of experience on Unix systems rather than Windows) you see that in some aspects it dwarves most editors in Windows. And "emacs" does even more.
Well, not when you install from the repositories of the distributor. When you install Microsoft Office, it often works. When you download source of a freeware package and compile it (unusual on Windows) it may have problems.
What do you mean it "just works"? You had to install it, didn't you? On Linux it would be the same, however on Linux it ofen already works before you install it because it is already there. (not a video editing program, but a text editor which this discussion is about is already there. on Windows you first need to find and install that before you can edit, or else you will need to use toys like notepad or wordpad, which are very very inproductive for anything beyond changing a single word or adding a line in a configfile)
The same is true for packaged Linux software. Today's Linux distrubutions consist of packages with defined dependencies on other packages and the whole required tree below a top-level application can be pulled in by a single command.
When you want to write or compile programs yourself, it is different. But on Windows that is the same.
In Windows it is no different. 99.999% of its users are not capable of writing and compiling programs themselves. They can only install packages that others prepared for them.
er no: most people do not have their own opinion about the matter, and their secondhand opinions are irrelevant.
Of those that have some opinion on the matter, it's unclear if "most" is applicable, since termcap is less flexible than terminfo. Keep in mind that ncurses' terminfo has been extensible for more than ten years.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.