Dear RRM, let me explain some basic concepts and see if that solves your questions.
Computer programs are usually created using a programming language, which contains instructions for the computer.
Programs using a particular programming language may be "compiled" or run directly from its source. Compiling means the computer takes the program and converts it to a faster form, by removing useless code, optimizing what the programmer wrote, etc... We call that faster form the "binary" and the editable one "source code".
In aMule's case, the programming language used is C++, which in general needs to be compiled. Compiling the whole aMule software, which consists of hundreds or source files is called building, and the result of building is called a build. Note that you cannot run source code without compiling unless you are really an expert.
Apart from that, complex programs like aMule allow to set some compiler options, and the binary will be different. Those options are optimization level, debug level, libraries to use, etc... The reason that those options are compile-time and not settable from the Preferences panel is that in general are hard to do. For instance, a debug build will contain extra low-level instructions that are impossible to remove without recompiling.
Now, lets apply all the above to your situation.
First of all, in order to produce an aMule binary you need to fetch the "source code", that is, the form of the program that programmers can easily edit. This is needed so we can easily change aMule behavior and you may test it.
There are several ways of getting aMule's source code, a quick one is using git, a program whose whole purpose is to track changes to source code.
When you do a git clone $url, you "clone" that is to say, fetch the whole source code available at $url. Note that if the developers update the source code git helps you avoiding to download the whole source code. The command to update the source code is git pull, and it will download only the changes you don't have in your local copy. Of course this is much faster than downloading again all the source code. git can be used for a lot of thing (like sending changes to aMule developers), but just knowing git clone and git pull should be enough for you. (By the way, git checkout "extracts" a file from the saved version)
So far so good, you should have learned how to fetch and update aMule source code. Now lets see what can we do with the source code: Generating an aMule binary and misc files, so you can run aMule.
The first step is to "configure" the build process. In this step you tell the build system where will aMule binaries be installed, and may set several options. So that's exactly what prefix means, the install location. (I know prefix is a cryptic name for that) Enabling debug and optimizations are options, you may see all options calling ./configure --help
For packages compiled by the users, Ubuntu follows a convention that binaries should be placed under /usr/local/, but as STU said, you may place the binaries whenever you want. I recommend you to place them under /usr/local/stow/$build-name
Now let me to introduce stow to you. When compiling and installing some software, the default prefix will be /usr/local, so you once you finish the build you'll get a binary like /usr/local/bin/amule
So far so good, /usr/local/bin is in your PATH by default (a variable which tells the system where to look for binaries) , so you can type amule and it will start.
Now imagine you want to change some build options or the actual source code. You build aMule again and you get a new /usr/loca/bin/amule. What happens if you want to have both builds available?
Now stow enters in the equation. Stow allows you to install software in /usr/local/stow/ and select which version should be made the default, that is to say, the one present in /usr/local/bin
This way, using stow you build aMule and set the prefix to install it in /usr/local/stow/amule-myowncoolversion. Now you have a complete aMule build living in /usr/local/stow/amule-myowncoolversion, but as this location is not in the default path you may encounter some problems. So you change the current directory to /usr/local/stow and do
$ stow amule-myowncoolversion. Now that version is the default one.
Now you have some changes in aMule, so you call configure again and tell it to install this new build in other location [always under /usr/local/stow] You may go to /usr/local/stow, unstow the previous one and stow the new one. Do you need to try the old one? Just unstow/stow again and you are set.
Of course, as STU said this is not really needed, but I like to be methodical.
The last bits remaining is to explain make and make install. Make performs the actual build and make install will install the software where prefix indicated.
Really last paragraph: configuration files are stored in a per user location, so changing the binary doesn't affect them. Think of upgrading Firefox, you get a new program, but all your settings are retained because they live in a different location.
Is it always the same, like this?
$ git clone git://repo.or.cz/amule.git
git clone downloads aMule source code from zero. git pull updates it to newer versions, so you should only use git when you want to fetch changes from aMule developers.
[Will that replace the current aMule program (the tilted blue square)?
and if i call
~/tmp/amule$ ./configure --prefix=/usr/local/stow/amule-2/ --enable-geoip --enable-optimize --disable-debug --mandir=/share/bin
$ make
$ sudo make install
I will get a second program in the same folder?
or a second amule folder (amule-2) in the same tmp folder?
But why not like this?
$ make -j 2
$ sudo make install
$ cd /usr/local/stow
$ sudo stow amule-2
You will get the program in the folder you choose in configure using the --prefix parameter. If you make again without changing the folder, the new program will overwrite the old. Both behaviour make sense.
but not like this?
$ make -j 2
$ sudo make install
$ cd /usr/local/stow
$ sudo stow amule-opt
This will build amule (make -j2), install amule in whatever prefix is set (sudo make install) go to stow location (/usr/local/stow) and stow amule-opt.
configure:7621: checking if wxWidgets was built in DEBUG mode
WX_DEBUG='0'
$ head config.log
$ ./configure --prefix=/usr/local/stow/amule-opt/ --enable-geoip --enable-optimize --disable-debug --mandir=/share/bin
You must compile with --enable-debug --with-wxdebug.