Editing Documentation/Maemo 5 Developer Guide/GNU Build System

Warning: You are not logged in. Your IP address will be recorded in this page's edit history.

Warning: This page is 68 kilobytes long; some browsers may have problems editing pages approaching or longer than 32kb. Please consider breaking the page into smaller sections.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision Your text
Line 579: Line 579:
=== Brief History of Managing Portability ===
=== Brief History of Managing Portability ===
-
When discussing portability challenges with C code, various issues crop up:
+
When discussing portability challenges with C code, various issues will crop up:
* Same library function has differing prototypes in different UNIX-style systems.
* Same library function has differing prototypes in different UNIX-style systems.
-
* Same library function has differing implementations between systems (this is a difficult problem).
+
* Same library function has differing implementations between systems (this is a hard problem).
* Same function can be found in different libraries in different UNIX systems, and because of this, the linker parameters need to be modified when making the final linking of the project.
* Same function can be found in different libraries in different UNIX systems, and because of this, the linker parameters need to be modified when making the final linking of the project.
-
* Besides these not so obvious problems, there is also of course the problem of potentially different architecture, and hence different sizes for the standard C data types. This problem is best fixed by using GLib (as in this case), so it is not covered here.
+
* Besides these not so obvious problems, there is also of course the problem of potentially different architecture, and hence different sizes for the standard C data types. This problem is best fixed by using GLib (as in this case), so it will not be covered here.
* GLib also provides the necessary macros to do endianess detection and conversion.
* GLib also provides the necessary macros to do endianess detection and conversion.
The historical solutions to solve these problems can be roughly grouped as follows:
The historical solutions to solve these problems can be roughly grouped as follows:
-
* The whole software is built with one big shell script, which tries to pass the right options to different compilers and tools. However, such scripts are very hard to maintain and their use is strongly discouraged.
+
* The whole software is built with one big shell script, which will try to pass the right options to different compilers and tools. Most of these scripts have luckily remained in-house, and never seen the light of the world. They are very hard to maintain.
-
* Makefiles (GNU or other kind) allow some automation in building, but do not directly solve any of the portability issues. The classical solution is to ship various makefiles already tailored for different UNIX systems, and make it the user's responsibility to select the appropriate Makefile to use for their system. However, quite often this method required the Makefile to be edited, so the user had to be knowledgeable in UNIX programming tools. A good example of this style is found in some of the older versions of the game nethack.
+
* Makefiles (GNU or other kind) allow some automation in building, but do not directly solve any of the portability issues. The classical solution was to ship various makefiles already tailored for different UNIX systems, and it was the end user's responsibility to select the appropriate Makefile to use for their system. This quite often also required editing the Makefile, so the end user needed to be knowledgeable in UNIX programming tools. A good example of this style is found in the game nethack (if looking at a suitably old version).
-
* Some parts of the Makefile selection above can be automated by a suitable script that tries to guess the system on which it is running and select a suitably prepared Makefile. However, maintaining such scripts is quite hard, because there have been so many different kinds of systems, such as different library versions and different compilers.
+
* Some parts of the Makefile selection above can be automated by a suitable script that tries to guess the system on which it is running and select a suitably prepared Makefile. Maintaining such scripts is quite hard, as there were historically so many different kinds of systems (different library versions, different compilers, etc.).
-
* Even the creation of Makefiles can be automated from a script that guesses the system. Such scripts are normally called '''configure''' or '''Configure''' and are marked as executable for the sake of convenience. The name of the script does not automatically mean that the script is related to GNU autotools.
+
* Even the creation of Makefiles can be automated from such guessing script. Such scripts are normally called '''configure''' or '''Configure''', and are marked executable for the sake of convenience. The name of the script does not automatically mean that the script is related to GNU autotools.
-
* Two major branches of these master configure scripts evolved, each operating slightly differently and catering for differing needs.
+
* Two major branches of such master configure scripts evolved, each operating a bit differently and suiting differing needs.
-
* These two scripts and a third guessing script were then combined into GNU autoconf. Because this happened many years ago, most of the historical code has already been purged from GNU autoconf.
+
* These two scripts and a third guessing script were then combined into GNU autoconf. Since this happened many years ago, most of the historical code has already been purged from GNU autoconf.
-
Besides autoconf, it became evident that a more general Makefile generation tool can be useful as part of the whole process. This is how GNU automake was born. GNU automake can also be used outside autoconf. A simple autoconf configuration file is presented next.
+
Besides autoconf, it became evident that a more general Makefile generation tool could be useful as part of the whole process. This is how GNU automake was born. It can also be used outside autoconf. Automake will be covered a bit later, but first there will be a look at a simple autoconf configuration file (historically called a driver, but this is an obsolete term now).
=== GNU Autoconf ===
=== GNU Autoconf ===

Learn more about Contributing to the wiki.


Please note that all contributions to maemo.org wiki may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see maemo.org wiki:Copyrights for details). Do not submit copyrighted work without permission!


Cancel | Editing help (opens in new window)

Templates used on this page: