Building a Development Environment on Ubuntu

[Xiong]

Here is an environment for developing applications in Perl, suitable perhaps for the newcomer. It seems ironic that the rawest newcomer to the Perl Community needs a stable, independent development environment more than the grizzled guru; yet constructing that environment is not an entirely straightforward task (judging from the many blind alleys I have blundered into).

We all have different situations so let me begin by telling mine. If my shoes fit, you are more than welcome to try them on. This discussion may prove quite boring to the experts, of whom I beg pardon.

I'm a solo developer on my own time; my current project is a web application to run on a virtual host to which I have shell access and read-only access to root. My development platform is an old trashy Intel laptop, considerably upgraded, running Ubuntu 9.10. This is a Debian-based Linux distro with the GNOME desktop. While I've written code all my life, it's been to support hardware development and operations. I have about 5 years in, fooling around with Perl; this is my second major project. Also, I'm fairly new to Linux in general.

I have a bias in favor of GUI tools when they are suitable. I use the command line as appropriate but I feel there's some justification in calling GUI an advance in productivity, especially when working with tools infrequently or initially. Also, I prefer when possible not to do things I don't understand, at least at some level. I feel more comfortable with command line invocations when I understand the implications of the funny switches.

The Lesser Issues

When I first began to write Perl scripts, I didn't give much thought to it. A perl executable is installed by default with Ubuntu; any text editor will work; compiling and linking is not required. I was well underway before I realized that I'd made many poor choices. Here are better ones.

How can I manage all my files?

By this, I mean low-level management: starting, editing, and finding them.

The default text editor, gedit, is too basic. I settled on Geany, which is intended for writing code. Geany has symbol completion, plenty of formatting options, syntax highlighting, and many other handy features. Importantly, it has the concept of projects.

A Geany project is nothing more than what you put into it. When you create a new project (Project -> New), Geany will create a file by that name, say myproject.geany. You may then open as many files as you like, each in its own tab. Don't close the tabs; close the project. When next you open the project, all the same files will be there in the same tabs and in the same state. Handy!

You are best to ignore items in the Build menu, which make more sense for compiled languages. Note that Geany can be heavily customized. For example, I edited ~/.config/geany/templates/filetype.perl to create a custom template for my .pl scripts. You are well advised to read the HTML format documentation available from the Help menu.

I found I needed both the GUI file browser, Nautilus, and a set of command line tools to work with files effectively. Nautilus is good for showing an overview of a folder and has tabs; unfortunately, these cannot be saved as a project group. Some operations are easier to do there as well. However, the Search function is rather slow.

Basic command line tools include ls, cd, cp, mkdir, rm, rmdir, chmod, chown, sudo, ln, locate, find, and the all-important man. I got much education by typing man command for each of these and many more.

A frequent issue is file permissions. Files may be read-only, read-and-write, executable or not; and these permissions may extend to owner (you), group (usually not important if you're solo), or everyone. You can make a Perl script executable quickly with Ctrl-I but for more advanced permissions work, you'll need chmod and chown. File permissions sometimes change without warning (when you do other stuff inadvertently, like restoring from backup) and can cause no end of trouble if you're not checking for them. Study up.

Two other text tools deserve mention: Bluefish and PodBrowser (see and this). Bluefish, I feel, is better for editing HTML than Geany. POD, the standard documentation format for Perl stuff, can be written in any text editor but oddly enough, there don't seem to be any really great applications for displaying it. PodBrowser is okay; you may just use gedit.

How can I track changes to my code?

My old standby was always to copy my project folder, name the copy by number or by date, and move on. Then I discovered git. There are other tools for version control but I feel this is best for our needs -- and a world beyond just copying files.

There is much to learn about git; much more than I can squeeze into a single post. The basic idea is to create a git repository inside every project folder; this will appear as a hidden folder, .git, which you can see in Nautilus with Ctrl-H or on the command line with ls -A (but which you do not want to touch directly). Whenever you make a small number of changes to your project, commit the changes to the "repo". Later, you can see what you did, how you did it, and (if you've written good notes) why you did it. You can even go back to an earlier version of your project. So git is an invaluable tool.

You can work with git from the command line and, as usual, you will have more power there; but I find two tools sufficient in most cases: git-gui and gitk. Use git-gui to commit changes; use gitk to see the history of those changes. You will likely have to study up on git to get the hang of it but I promise you the investment will be more than worth it. Tip: It's better to create a repo for an entire project folder and exclude files you don't want to track.

How do I organize all my files?

This was the topic of my first post to PerlMonks and oddly, I still haven't got the definitive answer; better, I'm no longer worried about it. When you have dozens, eventually hundreds of files, no over-arching scheme is going to last. Be willing to create many folders and try to keep things together.

The key to organizing files is the symbolic link or symlink. By creating links to files and putting them in different places, you fix the problem of wanting a thing to be in two (or more) places at once.

You can create a symlink on the command line with ln -s and view its target with ls -l. You can also make a symlink in Nautilus by Shift-Ctrl-dragging a file or folder.

Don't agonize over where to put (most) things. Put them where it seems reasonable and symlink them to other places where they also seem reasonable. Note that it can cause some trouble if you navigate a heavily symlinked directory structure, say, within one of your scripts; or you just forget which is the original and which the link. Don't go crazy.

Tip: I like to create a folder ~/sym, throw symlinks into it to any obscure item, and then put symlinks to ~/sym wherever convenient. This is too sloppy for files your scripts will work with but fine for stuff you need to look at or perhaps edit occasionally.

Another tool that helps with organization is File Roller (here and that). This is how you can make "tarballs" (compressed archives) of entire folder trees. Although git will keep you from having to make too many manual backups, it's still good to roll up your folders from time to time.

Finally, and most important, back up your files! By this I mean you should copy them to an external hard drive, one you can unplug; or better, burn them to DVD. This can't be said enough: A good set of backups will get you out of more trouble than a week's worth of tears in a chat room. Back up regularly.

How do I get all this stuff?

All the tools I mention in this post (with the exception of perl itself) can be got through the Debian package manager, dpkg. There are several command line front ends, which I encourage you to look at; but the easiest way to install applications of any kind is probably to use the GUI Synaptic front end, found under System -> Administration -> Synaptic Package Manager. This will download and install for you most things that you will want on your Ubuntu system.

You do not want to use Synaptic to install perl itself! Ubuntu comes with perl installed already; but you don't want to use that for your laboratory. (More on this later.)

How do I partition my hard drive?

Installing Ubuntu is beyond the scope of this post but there is one key point that any developer needs to take into consideration and that is partitioning.

If you're a newcomer (and I don't think you'll have read this far if not), then you may well have a rather crude partitioning scheme. I'm going to suggest you back up all your files, clear off your hard drive, repartition it, and restore files from backup. If you mess up badly (as I did, and as is easy to do), you'll be doing this anyway some day. You may as well do it before things get complicated.

You can repartition an existing system "hot" but that's a bit risky and very slow. You're better to do this at install time.

Each system is different and I can only tell you how I spent my 111 Gb of storage:

/boot         500 Mb
/           22400 Mb
/home       19500 Mb
swap        21400 Mb
/ark        41000 Mb
/usr        11700 Mb
/usr/share  10200 Mb
/var         2400 Mb
/tmp         1700 Mb

Why so many partitions? There's a reason for each and no simple explanation. Consider this only a starting point for your own meditations; study up. All these names except one are standard and you can find info on them. I made /ark to store archives and rarely-edited files, of which I have several years' worth. Next time I do this, I will probably also create a /lab, /rad, or /run partition, for reasons which will be clear soon.

Building a Development perl Executable

Since perl is indeed installed by default with every Ubuntu installation, it seems reasonable to use it to run your development scripts. This is not bad of itself but next, you will want to use some module you download from the excellent CPAN. This is a vast collection of useful (and sometimes not-so) stuff and you will want to taste it. That will also usually be okay ...

... until the day comes that you happen to install a not-so-good module that conflicts with something that Ubuntu needs to run properly. You see, perl is not installed by default because Somebody thought you might like to play with it. Various parts of the system rely on Perl to work. You might be able to back out of that faux pas and you might not. I didn't, which led me to a clean install and a resolution to Never Tamper with the System Perl. (Others disagree but then, others are not over to my home to fix my broken system.)

So, must needs build a second, development perl. This safe practice is no doubt quite simple for the bewhiskered Saints but for a relative newcomer, I found it tough. I hope you'll find it easier to follow.

Download the Tarball

Go here and download the version of your choice. You probably want the latest 'maint' version; maybe not.

Unpack the tarball with File Roller and do not throw away the tarball. To be human is to err and the installation process changes files in the unpacked folder. You will want to be able to throw it out and re-unpack.

Create the Base Folder

You can put this anywhere but since you'll be going here a lot, you may not want to put it in your home folder; I didn't. I created a folder in the file system root at /rad/perl. (For "radical", anticipating a third, tamer build elsewhere.)

If you try to put this in your root, you may have some trouble, since as a user, you can only create things in your home folder. This is where the command line comes in handy:

$ sudo mkdir -p /rad/perl
$ sudo chown -R /rad xiong:developer

The sudo means you're commanding as superuser, like root. Careful what you do this way. The -p means to create the parent folder, too; the -R means to apply the ownership changes recursively on all contents. You will probably want to reissue the chown a few times, whenever you get a message that something isn't working because of permissions. My username is 'xiong'; I might as well have chown'd to xiong:xiong but I'd created the 'developer' group on my machine previously. (You needn't.)

Build It

$ ./Configure -Dprefix=/rad/perl -Dusethreads

Note that I've chosen to build perl with thread support. This is still considered experimental but -- did you know? -- the system perl shipped with Ubuntu has threads enabled.

Now comes a very long list of questions, which must be answered somehow. In most cases, just hitting return (accepting the default) works. Here are some of the changes I made (and didn't):

Directories to use for library searches?
[/usr/local/lib /lib /usr/lib /usr/lib64]

Note that I (eventually) accepted the default here. This is for other libraries needed to build perl, not libraries of Perl modules, which I wanted to keep separate from the system.

What optimizer/debugger flag should be used? [-O2]

Again, the default is fine. You will see references to compiling with debugging support but you don't need to do this in order to use the Perl debugger.

Pathname where the public executables will reside? (~name ok)
[/rad/perl/bin]

Note that the hashbang line that starts your scripts must now be #!/rad/perl/bin/perl, not the #!/usr/bin/perl that you may see elsewhere (or used with success before). Later, I'll show you a way I shortened that.

Pathname where the private library files will reside? (~name ok)
[/rad/perl/lib/5.10.1] private

I prefer a shorter name, easier to type and grok.

At this point, there's a test for setuid. Don't worry about it. Answer 'no'; then you're asked if you want to emulate; say 'yes'.

Pathname for the site-specific library files? (~name ok)
[/rad/perl/lib/site_perl/5.10.1] /rad/perl/lib/cpan

Again, I don't like excessively long path names and I don't think I'll be installing another version on top. But this may have been a mistake; I think cpanp expects there to be another level of depth. (Anybody?)

Colon-separated list of additional directories for perl to search? [no
+ne] /rad/perl/lib/more

After several attempts, I hit on this safety valve. You see, when you build perl you are also setting the default paths for @INC. You can alter this at run time but you cannot change the default without rebuilding. By including a spare, I was later able to symlink to modules that installed in an unexpected location.

Do you want to install perl as /usr/bin/perl? [n]

Absolutely not. The whole point of the exercise is to leave the system build untouched. As usual, hitting return is almost always best.

Where do the main Perl5 manual pages (source) go? (~name ok)
[/rad/perl/man/man1] 
What suffix should be used for the main Perl5 man pages? [1] 
 
Where do the perl5 library man pages (source) go? (~name ok)
[/rad/perl/man/man3] 
What suffix should be used for the perl5 library man pages? [3]

At this point, there was a great amount of output, which I might have suppressed had I not an obsession with such stuff. Eventually, it's done and we're back to the command line prompt.

$ make
$ make test
$ make install

After each such command, there will be much business. Don't be alarmed that it throws all sorts of warnings. So long as it completes with success, it's okay. When it's all done, chown again for good measure.

Now for a little manual test of our own. Write this script and change permissions on it so that it's executable:

#!/rad/perl/bin/perl
#       hello-simple.pl

use strict;
use warnings;
use feature qw(switch say state);

say 'Hello, World!';

Then run it with ./hello.pl.

(Purists will complain that this is a lot of work to avoid "\n" but I like it.)

Create a symlink as /run to /rad/perl and then you can change the hashbang to #!/run/bin/perl.

There's a couple points to this. By building in /rad/perl instead of just plain /rad, the Configure operation defaults to a shorter path for those module libraries. By symlinking from /run, I can change the link later to point to a different build, leaving my scripts untouched. This makes more sense when you see that perl might be anywhere on my remote webhost, probably /usr/bin/perl.

Congratulations! The new perl works. Now for the hard part.

Getting CPAN

There would be no point at all to any of this if I didn't want to be able to grab CPAN modules and install them into my development environment. This was not quite as easy as it might be.

I install modules from CPAN with the cpan script. But there's already such a script in /usr/bin and if I type cpan at the command line, that's what I'll get. I don't want that; it will try to install into my system. So, I renamed the system cpan and created a symlink to the cpan installed during the perl build.

There are actually four related scripts:

cpan
cpan2dist
cpanp
cpan-run-perl

Each one has a nasty little gubbins up top:

#!/rad/perl/bin/perl
    eval 'exec /rad/perl/bin/perl -S $0 ${1+"$@"}'
    if $running_under_some_shell;
#!/usr/bin/perl

This is only needed if you tend to invoke your scripts from some shell that doesn't understand the hashbang line. (The default shell, bash, is fine with it.) Obnoxiously, when the gubbins is built, the second hashbang isn't even right. Cut the whole thing down to:

#!/rad/perl/bin/perl

Cut the gubbins, rename, and symlink all four scripts.

Now, both cpan and cpanp require various modules to run with all features and unfortunately, neither ship with all of them. So, you start off with somewhat broken tools, which is all you have to fix them with. I cannot say exactly in what order, but I ran first one, then the other, installing what they would; they need different modules and work differently. There may be a way to get just one to load right up and if Somebody will tell me about it, I'll gladly edit this node.

Configuring cpan and cpanp is a bit tricky. They need to know where to put their files and there's quite a bit of typing required. I suggest you copy and paste. Again, if I don't mention it, a simple return (accept default) is enough.

cpan

To reconfigure:

> o conf init

Most of the choices are a matter of taste. This process is both forgiving and unforgiving. If you make the wrong entry, you can't go back; but you can go around again. Difficulty: The next time through, the default will be whatever you chose last time, not the original default.

Would you like me to configure as much as possible automatically? no

No; we want to reconfigure.

Always commit changes to config variables to disk? yes

You may disagree but it's easy to forget to save preferences changes, which is what we're setting here.

Policy on building prerequisites ...? follow
Policy on installing 'build_requires' modules ...? yes

If it's a prerequisite, well, we'd better build it. I don't see any point in downloading something and then not keeping it but you may disagree.

 <makepl_arg>
Parameters for the 'perl Makefile.PL' command? 
    LIB=/rad/perl/lib/cpan 
    INSTALLMAN1DIR=/rad/perl/man/man1 
    INSTALLMAN3DIR=/rad/perl/man/man3 
    INSTALLSCRIPT=/rad/perl/bin 
    INSTALLBIN=/rad/perl/bin

This is the first biggie. Note well that although I've broken the line into parts for readability, this will not work for you when actually doing the configuration! Nor will it help to put backslashes in. It must all be on one line. Suggest you copy and paste the whole mess to a scratch file, make any changes to the paths first, then take out the whitespace, copy again, and paste into cpan.

<mbuildpl_arg>
Parameters for the 'perl Build.PL' command? 
    --lib=/rad/perl/lib/cpan 
    --installman1dir=/rad/perl/man/man1 
    --installman3dir=/rad/perl/man/man3 
    --installscript=/rad/perl/bin 
    --installbin=/rad/perl/bin

Same drill but notice that there are important differences. You want the double dashes and you want the lowercase. Keep it all on one line!

Do you want to turn on colored output? yes

I like the colors but beware that the defaults are kinda ugly and hard to read. If you want normal output plain black on white, don't choose black on_white; just say black. Say black on_blue, not black on blue, for black on blue.

If no urllist has been chosen yet, would you prefer CPAN.pm to connect
to the built-in default sites without asking? (yes/no)? yes

You must say yes or everything fails, if this is your first time through. You'll be prompted through several menus of continents, countries, and eventually CPAN sites. Choose several; you never know when one will go down. I googled to see which were geographically close. I favor .edu mirrors but I throw in some commercial ones. You want a mix of ftp and http sites.

At this point, you're done; but cpan will make all kinds of complaints about various modules being unavailable -- loud complaints, if you've enabled bold_red on_white for such things. Install what you can; quit every so often and restart.

cpanp

To reconfigure:

> s reconfigure

Unlike cpan, cpanp gives you some sub-scripts you can choose from a menu, so you don't have to do it all in one shot.

Again, most are a matter of taste and most defaults are okay.

Section to configure: : 5
Follow prerequisites? : 2

Section to configure: : 6
Makefile.PL flags? : ***

*** Here you enter the whole mess on one line, as above in makepl_arg.

Section to configure: : 6
Build.PL and Build flags? : $$$

$$$ Here the other whole mess, as mbuildpl_arg.

Section to configure: : 7

Again, choose some CPAN mirrors.

Again, install what you can and try cpan again.

Done?

I wish I could offer a better process than fudging back and forth between cpan and cpanp until they both work; but that's what I did. No amount of hammering on just one or the other worked.

I ran into a nasty bit along here, where somehow I failed to build perl with all the right paths in @INC; cpan insisted on building into an unreachable folder. That's where the spare folder, /rad/lib/more, came in useful. I never created that folder as such; I just made a symlink with the unreachable folder as its target. Expect the unexpected.

If you go wrong somewhere, never fear. Throw all your builds out, if you must; and go back and untar the perl tarball. I went through and salvaged some configuration files from each attempt as a guide to the next; but I'm not sure to recommend that, since I fear I may have propagated mistakes that way, too. Don't lose heart; you'll get it done eventually. It took me only 13 tries.

Install some more modules. Write some scripts. Have Fun!

---

Vespers

Monks of much greater serenity than I may scoff not only at the extreme length of this post but also at the weasel words and general fudgery-doo.

First, I apologize to anyone who felt he had to read it all. I offer the defense that I would have loved dearly to have seen the whole gross tome six months ago. I've spent literally hundreds of hours studying up to get this far and no matter what I read, it contained only a small piece of the puzzle. Although I know much more now about building a development environment than I did, I would have been content to have it all handed to me and been free to concentrate entirely on learning Perl.

Second, my regrets to anyone offended due to the time spent explaining not-Perl stuff. I found that stuff essential to doing anything with Perl and it took me months to figure it out, a nybble at a time.

Third, my deepest sympathies to those who come looking for hints on how to develop on anything but Ubuntu, or for any other purpose. When I searched for web pages with practical advice (outside of the standard docs), I almost invariably stubmled on instructions for installing ActivePerl on a BeOS server through telnet. There don't seem to be many tutorials for my situation, since perl is installed by default and anyway, Ubuntu is Linux and any build here must be a snap.

Fourth, I'm more than willing to incorporate reasonable suggestions and sage corrections from anyone who considers to provide them. I'm only too aware of how little I understand what I just did and I'm convinced I only did so-so, perhaps less well considering the investment.

Please take note that I owe far more than I can possibly repay to the many Saints and lights who made these tools available and those who condescended to explain them to me, sometimes five or six times. If oftoccasion these tools have made a poor cut, let us blame the hand that held them.

---

Updates:

s(sudo ./Configure)(./Configure) per duelafn ++

Correct my remotehost access.

Convos:

There are many good reasons to partition. My hope in showing off my table is to provoke the newcomer to study up and think about a plan beyond /, /home, and /swap. I agree with wazoox that this is the absolute minimum. Would anyone like to suggest a starting point for the newcomer to read more about partitions?

Since as an Ubuntu noob I use bash exclusively, is there any reason to retain the gubbins? Has it any purpose? I admire the gubbins as I admire any cute dodge. I detest the gubbins as I loathe obfuscated code in production. It's an extremely clever way to fix an issue that should never have arisen. I wasted much time studying the gubbins before I was certain how to dispose of it and that alone incurs my resentment. I'm not entirely sure of the effect of the second (third?) hashbang (perhaps none) but seeing it there gives me the willies. I should probably extend the list of scripts to trim. There is probably no reason to sudo ./Configure; fixed. Truth be told, I sudo su and did the whole thing from a root shell. (Please don't hit me!) Even worse, I gksu nautilus. This is a step down from logging into GNOME as root. Sorry; I'm not quite in the spirit of doing admin stuff as a humble user on my own machine. I'd probably run as root all day long if it wouldn't so irk my fellow Monks. I'm the sort of person who rarely sets write-protect tabs and often runs heavy equipment with the chain guards off. I admit that age has made me a little more cautious.

I need clarification on using aptitude to install perl. How would I use it to install a second executable for development only? How is that better than downloading the tarball from CPAN? Do I get more stuff that way? Will cpan and friends work better out of the box? What's the win? How many steps above do I bypass this way? When I screw up the build, how do I re-unpack the download and go around again? Note my bias in favor of GUI tools appropriate to the newcomer. I fear that using Synaptic will do nothing at best and wreak havoc at worst. I surely wouldn't want to mislead the newcomer who, like me, has learned to substitute Synaptic for the many apt-get suggestions he reads. I'll be happy to incorporate an aptitude call, though, if there's a commensurate payout.

Originally, I chose /dev, for "development", as my development folder. (You see how raw I really am.) Then I chose /lab, for "laboratory". Then I realized that eventually I would build at least two perl environments (in addition to the preinstalled system perl): one latest-and-greatest and one to match exactly that installed on my remotehost. I chose /rad for "radical" and put a symlink at /run (for "run"), which keeps paths short and gives me some flexibility.

I definitely don't want to install to /usr or any subfolder thereof. That folder is full (> 200,000 items) and I've already put /usr/share on its own partition, also full. Besides, it is, as rowdog points out, the default for many things. I want to be very sure that nothing defaultish hits into my development environment or vice versa.

Yes, /opt (for "optional"?) seems reasonable enough. Perhaps when I feel confident enough to rewrite this personal saga as an authoritative tutorial I'll change over to that.

I very rarely invoke perl from the command line; I'm not a one-liner guy and I expect my script to find its interpreter. I can see some benefit to a modified PATH. I'll have to study up. rowdog++

I certainly need to add a paragraph about development libraries and XS modules. These headers can be installed easily with Synaptic; it takes only a bit of research to figure out which packages are needed. Unfortunately, cpan does not resolve these non-Perl dependencies nor does it emit illuminating errors when they're missing. I also want to expand the section on cpan to include recovery from failed installs.

Upvoted scorpio17's comment because it's nice to see alternatives.

Um, mpeg4codec, you and perhaps duelafn are pushing Debian packages as a way to install perl and CPAN modules. My understanding is that all dpkg tools will put things in the default location, which is exactly what I don't want. If I'm wrong, tell me and I'll study up. If using aptitude, apt-get, or better, Synaptic itself will get anything installed with less hassle and/or more safety (particularly those stubborn XS modules), I'll not only rewrite this post, I'll tear down my devel-environ and start over.

Daydream:

Is it rational to construct and upload some sort of development environment starter package?

[duelafn]

Nice! Some comments:

• partitions: I'm not really sure multiple partitions are worth the hassle for the beginner. There really isn't anything wrong with one big partition (I use the single-partition approach on all my machines except my server which runs LVM and mounts several of the partitions read-only/with different mount options.)
• nasty little gubbins: Is there a reason you feel the need to mess with these?
• Why are you configuring perl with "sudo ./Configure" since you are compiling and installing as your regular user? There is no need to use sudo there.
• You can use sudo aptitude build-dep perl on Debian/Ubuntu to install all the packages needed to compile perl.

Updates: To clarify, sudo aptitude build-dep perl only ensures that you have everything installed that you would need in order to compile perl (c-compiler, make, ...). It is not a way to maintain multiple perl versions on your system.

The arguments for a separate /home partition are good so indeed, someone following this guide may wish to consider /, /home, and swap. For further information check out this Linux Partitioning mini-FAQ. Especially the "Why Partition at All?" section.

Further commentary on gubbins: Indeed the gubbins should no longer be necessary on a modern system, however, I would argue that very few people actually mess with them as they do no harm. If they offend you mightily, feel free to remove them but they will pop back up whenever you re-install perl.

[rowdog]

I second duelafn's recommendation to use a single partition, except maybe a separate /boot is useful. Newbies aren't likely to be able to judge proper sizes for partitions and it's not exactly trivial to resize partitions and filesystems the first time you find yourself with a full partition. It's not that hard to repartition, but your meditation is pretty clearly aimed at newcomers.

A minor nit is that the traditional (and recommended) place for software that is not part of the distribution is either /usr/local or /opt The advantage of using /usr/local is that perl installs there by default so you can just hit return all the way through the configuration script. Myself, I like /opt/perl since I'm exporting /opt via NFS anyhow.

One trick is to modify your PATH for your user but NOT for root. I add the following to the end of my user account's .bash_profile

PATH=/opt/perl/bin:~/bin:"${PATH}"
export PATH

and I "magically" see my installed perl when I just type perl -E but I haven't messed with root's access to the system perl. Another advantage is that when I (as my user account) use cpanp there's no confusion about trashing the system perl by mistake.

I don't recall any problems configuring cpanp as my user. I believe I had to add sudo to the make install command and maybe to the build command, but I'm pretty sure cpanp knows where it's perl is installed by default.

One issue newbies can run into when building modules is that most Linux distros do not include the header files for installed software. The package you want will have a -dev at the end. For example, if you want to use GD then you'll need to install libgd2-xpm and libgd2-xpm-dev (or the noxpm equivalents) to compile the XS. (GD maybe be a bad example but I believe GD requires the headers.) Anyhow, -dev isn't too hard to figure out, but for a novice monk it might help to avoid the "I've got libgd2 installed but I can't install GD?" syndrome.

I suppose I'm showing my long gray beard here but I kind of miss the simple days when we routinely built our own versions of apache, perl, and mod_perl. Sure you had to understand ./Configure && make && make test && make install but you didn't have to do backflips to not mangle your systems. Sure, you can still do that today but it's practically a forgotten art anymore.

Now get off my porch ya darn youngin! ;^)

[wazoox]

I must strongly disagree with both duelafn and rowdog about partitioning. It is generally unnecessary and actually can be a source of hassle to split your drive in lots of partitions, because it's all too hard guessing what you will actually need. On the other hand, using only one partition is absolutely to be forbidden. It should be the Golden Rule of the Linux User : always use a separate /home partition. I insist on it : always.. If your disk's too small, go buy another one to host your /home, they're really dirt cheap anyway.

With a separate /home, you can reinstall the system, you can even easily switch distribution without risking losing all of your data.

Concerning the editors, newcomers are to be advised to look for some threads on this very subject here, particularly Perl Development Tools.

[rowdog]

I must strongly disagree with both duelafn and rowdog about partitioning.

Well, I'll agree with you then. I was trying to think from the point of view a complete newbie and partition hell can be a real nightmare. On the other hand, a separate /home partition makes it easy to switch distros or rebuild from a failed OS upgrade. Personally, I use separate partitions for anything not handled by the package manager, but I also use LVM so it's a snap to repartition.

[scorpio17]

Nice post. I also do a lot of web app development using perl on an Ubuntu machine. I tend to use vi (or gvim) as my editor, but Eclipse with the EPIC plugin is also good. I use svn (subversion) for source code control. Eclipse has a plugin for svn called subclipse, that makes using it pretty easy. I don't compile my own perl, but I tend to install modules from CPAN into a local lib directory. If I have to install an app on another server, then I can just tar up that lib - it saves having to reinstall everything. But I only do this for pure perl stuff. For something like DBI, I use synaptic package manager to install at the system level. I also install apache and mysql, so I can run a complete developer version of my web apps offline, on my local machine.

[mpeg4codec]

Debian and Ubuntu come with a lot of modules from CPAN packaged for the distro.

The naming convention is: convert :: to -, make all the letters lowercase, and add lib to the beginning and -perl to the end. For example: POE::Component::IRC is packaged as libpoe-component-irc-perl.

I've also had limited success with dh-make-perl which fetches from CPAN and builds debs. You often have to manually specify depends and build-deps, which can be tedious and error-prone.

[marto]

"Now comes a very long list of questions, which must be answered somehow. In most cases, just hitting return (accepting the default) works."

Given the above statement and the discussion in the CB and via /msg today on the subject of Configure, it may be a good idea (though some may consider it stating the obvious) to suggest that people building perl in from source read and understand the README file, the INSTALL file and any platform specific readme file as a minimal primer to familiarise themselves with the configuration/installation process and associated terminology.

In the grand scheme of things, we're not talking about reading an excessive amount of documentation here. It's also good practice for new users to familiarise themselves with perls style of documentation.

The README file shows an example installation, explaining calling Configure with the -des flag to accept the default values, along with an an installation prefix:

INSTALLATION

============

If you're using a relatively modern operating system and want to install this version of Perl locally, run the following commands:

./Configure -des -Dprefix=$HOME/localperl
  make test
  make install

The INSTALL file elaborates on this in the Run Configure section, explains how to pass exactly the configuration parameters you want, while accepting the defaults for other things and how to accept defaults after any point of an interactive configure run. That said, you may not know you're happy to skip any of these options, until you've been through the process at least once ;)

Cheers

[Xiong]

I read both INSTALL and README.linux; I Googled hard for more info. I didn't find enough to make the process easy for me. I agree that I should amend this node to point to the appropriate docs.

I feel that I may have made the task unnecessarily difficult by running Configure interactively. (I don't think interactive mode should be so difficult to use but that's another node.) I'm not sure why I was so certain that I needed to be interactive here. I'm going to try a non-interactive build and if it does what I want, I'll amend this node to follow. Thanks for pushing.