How source code works for the end user?

synthead · 2006-05-24 11:38:53

I am jsut a little curious what happens behind the curtains of the while configure, make, make install method. Configure checks to see what your system is capable of, make compiles the source to binaries, and make install ... that copies the binaries to the system folders and creates symlinks and stuff, right? So if I were to extract a tarball to my home directory, do a configure, make, make install, it's fine to erase the directory in ~, right? Also, what would one do if they decide to remove the program later?

I think this is the most elementary thing I am unsure about for how far I've gotten in linux Thought I'd clear it up, thanks all!

lessthanjake · 2006-05-24 11:57:27

If you want to remove it later, you should hope the provider have made a 'make uninstall' script. Usualy they have not. Second solution is using checkinstall instead og 'make install', but it does not work with Arch (I believe). Third and best solution is making a PKGBUILD, and install and uninstall with packman.

user · 2006-05-24 13:22:43

FYI
http://paco.sf.net/

sergej · 2006-05-24 13:44:54

http://aur.archlinux.org/packages.php?d … =1&ID=4559

nightfrost · 2006-05-24 14:19:58

for some applications at least, you don't really need the 'make install' part. Linuxdcpp, for example, is possible to run with ./ldcpp after you've built it with make.

Anyway, to write a PKGBUILD is the best thing to do. It gurantees proper removal of the application.

phrakture · 2006-05-24 16:43:59

synthead wrote:

I am jsut a little curious what happens behind the curtains of the while configure, make, make install method.

Oh oh oh! Goody, I like these things!

The typical configure/make/make install setup is what's referred to as an "autotooled build". They are usually (but not always) created by autotools (autoscan, autoconf, autoreconf, automake). That is, the original developer makes some *.in and *.am files, which are used to generate those huge scripts.

The "configure" script is a bash script, usually generated from a configure.in file. If you take a peek at it, it's usually ridiculously long and complex. Autogenerated stuff usually is. On a typical autotooled build, the configure script converts a "config.h.in" file to "config.h" - for inclusion into the source code, which is usually a series of C #define statements, letting the code know what features the system has.

The configure script also converts Makefile.am files to real Makefiles. These are used by "make" when it is run, to know how to properly do whatever it needs to do (compile this, copy that, etc etc). Makefiles are set up in terms of "rules". By default, running "make" reads the Makefile and looks for a rule named "all". Running "make SOMETHING" looks for a rule named "SOMETHING".

There are usually many rules in a given Makefile, especially an autotooled one. However, the important ones, to an end user, are "all" and "install" (as well as "uninstall" and possibly "clean"). Most of these are created automatically by autotools. Typically, "all" will compile everything it needs to, generate/create documentation files, and so whatever else the developer wants it too. "make install" then copies all those built files where they need to go.

Now, I need to disclaim this. Autotooled builds, while good and portable, are crap. It is much easier to write a Makefile by hand. It just has a bit or a learning curve for some. There are many other alternatives to using autotools, such as SCons, Cons, and some custom scripts. I prefer the simplicity of writing a Makefile and a "rules" file for that Makefile, with simple instructions to edit the rules.

If you're interested in autotools, here's the de facto book:
http://sources.redhat.com/autobook/

Enjoy!

synthead · 2006-05-25 04:40:05

Ahhh, interesting, I think I'm starting to get the jist of it. From all the small talk about uninstalling software, I had a feeling that it was a bit sketchy. Nice links everyone, thanks for the help! I'm definately going to try the pkgbuild method to do things if I need to ... maybe you'll even see a bit of contributed binary from me in the future

codemac · 2006-05-25 13:11:12

phrakture wrote:

... oodles of shite ...

Got a little bit excited there phrakture...

haha, I just tried to tab complete "phra" -> "phrakture". I rock. LIFE IS IRC.

Cerebral · 2006-05-25 13:25:19

One small correction:

phrakture wrote:

By default, running "make" reads the Makefile and looks for a rule named "all". Running "make SOMETHING" looks for a rule named "SOMETHING".

by default, running 'make' builds the first target in the makefile - it doesn't scan for the 'all' target.

For example, copy this into a temp folder and name it Makefile:

testing:
    echo "I'm testing!"
 
all:
    echo "All!"

And run 'make' - it will echo "I'm testing!"

test1000 · 2006-05-25 14:53:36

thanks for the explanation guys, this will come in handy.

phrakture · 2006-05-25 19:03:49

Cerebral wrote:

by default, running 'make' builds the first target in the makefile - it doesn't scan for the 'all' target.

Heh, my fault. For some reason I had a memory of doing "make" with no Makefile and it says "nothing to be done for 'all'" - but I'm wrong.

T-Dawg · 2006-05-25 20:30:17

phrakture wrote:

..I'm wrong

>>> (1.0/5759.0)*100
0.017364125716270183

Not a bad. You've still got it, I'd say.

jakob · 2006-05-26 11:18:07

To have a practical example to see what a (very easy and hand-written) "configure"-file may look like, you can inspect the configure file of "fspanel" (it's in AUR).

Since I spent one night patching it, I understand how that files work...

jakob

ScriptDevil · 2006-05-27 04:15:25

a higly unrecommended but working approach(may have side effects) is to remove manually the various files by using locate and rm
Unlike windows i do not think there is a registry which needs to be updated

iBertus · 2006-05-27 20:52:16

ScriptDevil wrote:

a higly unrecommended but working approach(may have side effects) is to remove manually the various files by using locate and rm
Unlike windows i do not think there is a registry which needs to be updated

No, but the typical 'make install' puts crap in lots of different places and it would be difficult to find all of the stuff by hand. Much better to just use a package manager.

lessthanjake · 2006-05-28 07:31:52

phrakture wrote:

Now, I need to disclaim this. Autotooled builds, while good and portable, are crap. It is much easier to write a Makefile by hand. It just has a bit or a learning curve for some. There are many other alternatives to using autotools, such as SCons, Cons, and some custom scripts. I prefer the simplicity of writing a Makefile and a "rules" file for that Makefile, with simple instructions to edit the rules.

I disaree, trying to make a portable makefil when you do not know the version of make the end user are using, which c-compiler is installed, which shells are available, what OS they are using and so on, is a pita. Autotools may be comprihensive, and making bloated makefile, but at least it is working on (nearly?) any given platform. But maybe there is even better tools, have not been looking for others.

Arch Linux

#1 2006-05-24 11:38:53

How source code works for the end user?

#2 2006-05-24 11:57:27

Re: How source code works for the end user?

#3 2006-05-24 13:22:43

Re: How source code works for the end user?

#4 2006-05-24 13:44:54

Re: How source code works for the end user?

#5 2006-05-24 14:19:58

Re: How source code works for the end user?

#6 2006-05-24 16:43:59

Re: How source code works for the end user?

#7 2006-05-25 04:40:05

Re: How source code works for the end user?

#8 2006-05-25 13:11:12

Re: How source code works for the end user?

#9 2006-05-25 13:25:19

Re: How source code works for the end user?

#10 2006-05-25 14:53:36

Re: How source code works for the end user?

#11 2006-05-25 19:03:49

Re: How source code works for the end user?

#12 2006-05-25 20:30:17

Re: How source code works for the end user?

#13 2006-05-26 11:18:07

Re: How source code works for the end user?

#14 2006-05-27 04:15:25

Re: How source code works for the end user?

#15 2006-05-27 20:52:16

Re: How source code works for the end user?

#16 2006-05-28 07:31:52

Re: How source code works for the end user?

Board footer