Date: Sat, 13 Jun 2009 04:48:29 +0300 From: Giorgos Keramidas <keramida@ceid.upatras.gr> To: "Gary Gatten" <Ggatten@waddell.com> Cc: freebsd-questions@freebsd.org Subject: Re: reference for beginner on configure/make/compile/linking/etc. Message-ID: <87hbyk6h02.fsf@kobe.laptop> In-Reply-To: <70C0964126D66F458E688618E1CD008A0793EF4E@WADPEXV0.waddell.com> (Gary Gatten's message of "Thu, 11 Jun 2009 17:09:43 -0500") References: <70C0964126D66F458E688618E1CD008A0793EF4E@WADPEXV0.waddell.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 11 Jun 2009 17:09:43 -0500, "Gary Gatten" <Ggatten@waddell.com> wrote: > As you may recall from a recent post I've been trying to get nTop > compiled and working on Solaris 10 x86. After 40 - 60 hours (I loose > track) I *THINK* it's actually working for the most part. > > Before certain people get pi$$ed off about this not being a Solaris > list - chill for a sec! > > I'm just looking for some materials that can help me understand the > whole configure/make/compile/linking/etc. stuff. Someone that knew > this stuff could've probably resolved my issues in a few hours. It > seems COMPLETELY overly complex to me - maybe cause the developer > tries to make it as portable as possible, but with every *nix like > things putting files wherever they want, different cc's / ld's, etc. - > I can see where it can get hairy. > > Anyway, TIA for your input. Hopefully this experience and the > references you can point me to will help the next time I try to get > something onto FreeBSD! Hi Gary, The whole exercise seems overly complex, because as Mel Flynn has already written is *is*. A nice illustration of all the bits and pieces you have to integrate when using the `GNU build system' is the one at Wikipedia: http://en.wikipedia.org/wiki/GNU_build_system#Tools_included_in_the_GNU_build_system Merely looking at the various parts of the picture makes the mind boggle, but it may help you get a good idea of what the various steps of building software with the GNU build tools entails. Documentation for the various parts of the GNU build system is available online at the web page of each component. Useful starting points are: - The GNU autoconf homepage http://www.gnu.org/software/autoconf/ - The GNU autoconf manual http://www.gnu.org/software/autoconf/manual/index.html - The GNU automake homepage http://www.gnu.org/software/automake/ - The GNU automake manual http://www.gnu.org/software/automake/manual/index.html - The GNU libtool homepage http://www.gnu.org/software/libtool/ - The GNU libtool manual http://www.gnu.org/software/libtool/manual/ Note that the online copies of the manuals refers to particular versions of these tools. Since the various parts of the GNU build system are notorious for introducing new features and for often breaking backwards compatibility, it is a good idea to read the manual version matching the _exact_ version of these tools you have installed. The manuals are installed in Info format as part of the installation process of these tools, so you can commonly read the local version of the manual by typing: % info '(autoconf)' % info '(automake)' % info '(libtool)' One last thing that is useful to know is that the manuals are not always written in the form of educational material for new users. They are a little like a tutorial and a lot like reference guides. So it may take multiple iterations to understand all the concepts described in one of the manuals, and it usually takes multiple attempts at writing a new project ``from scratch'' before you gain enough experience in their use to know where to look in the manual for more help. This is a catch-22 situation, because the manual already contains a LOT of useful information, but you don't know that it is there, or even that it is going to be useful, until you have already read it a few times. After having worked with autotools-based projects for a few years, here are a few suggestions I have: * Read the manuals at least twice, from cover to cover. Don't worry if some things seem to be written in an ancient alien language. They don't make sense the first time through, but they tend to make more sense in the next iterations through the manuals. Make sure that you read the manuals at *least* twice. The first time some things will not make sense. The second time, you will have a general overview in your mind, and more details will fit with the rest of the puzzle. Every time you re-read the manuals you are likely to find more useful details. The manuals contain a HUGE amount of information, but it takes multiple passes to understand and fully appreciate all of it. * Read the code of projects using the GNU build tools... Look at what other projects are doing with the GNU build tools. By reading lots and lots of code, you will be able to see how others have solved their program's "portability" problems; you will see what they did to customize, extend and adapt the GNU build tools; you will learn new tricks and hacks, see how others write code that runs on multiple operating systems, platforms, machine types, etc. * ... but not all the code out there is `good'. Understand that the complexity of a full-blown build system is big, and as a result many of the projects you looked at misuse or flat out _abuse_ the GNU build tools in horrendous ways. That's ok, as long as you don't blindly copy their (bogus) style. * Write a few small tools of your own that use the GNU build tools. There is *no* *way* to experience some of the gotchas other than falling yourself in the same traps, and discovering for yourself how to solve the related problems with GNU build tools. * Understand that there are inherent limitations or even bugs in the GNU build tools. These limitations make some things either very difficult or impossible to do with the tools (i.e. it is nearly impossible to use automake with custom rules that descend into all ${SUBDIRS} and invoke a specific, locally customized target). * Explore alternatives. As Mel Flynn has written, there are quite a few other toolchains for constructing a build system. CMake[1] seems to be a popular alternative (the KDE projects uses CMake with a certain level of success). SCons[2], Apache Ant[3], and Apache Maven[4] are similar tools. [1] http://www.cmake.org/ [2] http://www.scons.org/ [3] http://ant.apache.org/ [4] http://maven.apache.org/ If all the above sounds like an awful lot of work, you are right! Build automation is a large field. There are a few decades of active development and a bewildering array of tools actively in use today. There are even more tools that were useful years ago, and have either been replaced by others, morphed into more modern toolsets, or just died out. It's an amusing field though, with a lot of challenging and *very* interesting things to keep you busy, and entertained for a long time :-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?87hbyk6h02.fsf>