Free Software Magazine - gnuhttp://www.freesoftwaremagazine.com/taxonomy/term/136
enMeasures on the command linehttp://www.freesoftwaremagazine.com/articles/measures_command_line
<div class="field field-name-field-main-image field-type-image field-label-hidden"><div class="field-items"><div class="field-item even"><img src="http://www.freesoftwaremagazine.com/sites/www.freesoftwaremagazine.com/files/main/main_2.png" width="300" height="400" alt="" title="Public domain image, modified" /></div></div></div><div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even"><p>In an <a href="http://www.freesoftwaremagazine.com/articles/find_time_zones_using_command_line">earlier article</a> I promised to demonstrate more 'magic words' for the command line. All you do is open a terminal, enter the magic word, hit Enter – and cool things happen! The magic word this time is <code>units</code>. The <em>GNU Units</em> program isn't installed by default in most Linux distributions, so you'll probably need to install it from your distribution's repository. Also, until you get to know GNU Units, I recommend that you enter <code>units -v</code> (<em>v</em> for <em>verbose</em>) on the command line. This makes the output a little more easy to understand.</p>
<p>The GNU Units program converts quantities from one unit system to another.</p>
</div></div></div><div class="field field-name-field-category field-type-taxonomy-term-reference field-label-inline clearfix"><div class="field-label">Category:&nbsp;</div><div class="field-items"><div class="field-item even"><a href="/category/end_users">End users</a></div></div></div><div class="field field-name-taxonomy-vocabulary-7 field-type-taxonomy-term-reference field-label-inline clearfix"><div class="field-label">Tagging:&nbsp;</div><div class="field-items"><div class="field-item even"><a href="/taxonomy/term/493">command line</a></div><div class="field-item odd"><a href="/taxonomy/term/136">gnu</a></div><div class="field-item even"><a href="/taxonomy/term/1593">conversion</a></div></div></div><div class="field field-name-taxonomy-vocabulary-5 field-type-taxonomy-term-reference field-label-above"><div class="field-label">License:&nbsp;</div><div class="field-items"><div class="field-item even"><a href="/taxonomy/term/49">Verbatim only</a></div></div></div>Mon, 02 Apr 2012 02:43:48 +0000Bob Mesibov3731 at http://www.freesoftwaremagazine.comhttp://www.freesoftwaremagazine.com/articles/measures_command_line#commentsBring Some GNU Goodness to Windows with Gowhttp://www.freesoftwaremagazine.com/articles/bring_some_gnu_goodness_windows_gow
<div class="field field-name-field-main-image field-type-image field-label-hidden"><div class="field-items"><div class="field-item even"><img src="http://www.freesoftwaremagazine.com/sites/www.freesoftwaremagazine.com/files/main/main_1.png" width="300" height="400" alt="" /></div></div></div><div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even"><p>Stuck on Windows? No problem, you can still have some of the best GNU utilities courtesy of <a href="https://github.com/bmatzelle/gow/">Gow</a> (which stands for GNU on Windows). BNQ3WVFXSY7Y Gow is a lightweight alternative to the popular <a href="http://www.cygwin.com/">Cygwin</a> collection of GNU utilities, and as such, it offers only the most essential tools.</p></div></div></div><div class="field field-name-field-category field-type-taxonomy-term-reference field-label-inline clearfix"><div class="field-label">Category:&nbsp;</div><div class="field-items"><div class="field-item even"><a href="/category/end_users">End users</a></div></div></div><div class="field field-name-taxonomy-vocabulary-7 field-type-taxonomy-term-reference field-label-inline clearfix"><div class="field-label">Tagging:&nbsp;</div><div class="field-items"><div class="field-item even"><a href="/taxonomy/term/136">gnu</a></div><div class="field-item odd"><a href="/taxonomy/term/341">windows</a></div><div class="field-item even"><a href="/taxonomy/term/283">cli</a></div><div class="field-item odd"><a href="/taxonomy/term/2169">command-line</a></div></div></div><div class="field field-name-taxonomy-vocabulary-5 field-type-taxonomy-term-reference field-label-above"><div class="field-label">License:&nbsp;</div><div class="field-items"><div class="field-item even"><a href="/taxonomy/term/49">Verbatim only</a></div></div></div>Wed, 07 Mar 2012 07:54:01 +0000Dmitri Popov3728 at http://www.freesoftwaremagazine.comhttp://www.freesoftwaremagazine.com/articles/bring_some_gnu_goodness_windows_gow#commentsChoosing and Using Free Licenses for Software, Hardware, and Aesthetic workshttp://www.freesoftwaremagazine.com/articles/choosing_and_using_free_licenses_software_hardware_and_aesthetic_works
<div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even"><!-- Choosing and Using Free Licenses for Software, Hardware, and Aesthetic works -->
<p>What is this "Free Culture" thing? What is "Free Software"? And how do I get my work out there? If you're looking to participate in the "Commons", you'll need to get comfortable with the idea of <em>free</em>, <em>public</em> <em>licenses</em> and how to use them for your works. This won't be hard at all, especially with this short guide, but there are different traditions that have sprung up around different kinds of works.</p>
</div></div></div><div class="field field-name-field-category field-type-taxonomy-term-reference field-label-inline clearfix"><div class="field-label">Category:&nbsp;</div><div class="field-items"><div class="field-item even"><a href="/category/opinions">Opinions</a></div></div></div><div class="field field-name-taxonomy-vocabulary-7 field-type-taxonomy-term-reference field-label-inline clearfix"><div class="field-label">Tagging:&nbsp;</div><div class="field-items"><div class="field-item even"><a href="/taxonomy/term/136">gnu</a></div><div class="field-item odd"><a href="/taxonomy/term/150">creative commons</a></div><div class="field-item even"><a href="/taxonomy/term/161">software</a></div><div class="field-item odd"><a href="/taxonomy/term/199">licensing</a></div><div class="field-item even"><a href="/taxonomy/term/611">hardware</a></div></div></div>Sun, 26 Sep 2010 09:47:59 +0000Terry Hancock3368 at http://www.freesoftwaremagazine.comhttp://www.freesoftwaremagazine.com/articles/choosing_and_using_free_licenses_software_hardware_and_aesthetic_works#commentsRule #5: Be Bold!http://www.freesoftwaremagazine.com/articles/rule_5_be_bold
<div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even"><!--Rule #5: Be Bold!-->
<p>One of the first rules that entrepreneurs learn is that investors don't like revolutionary new ideas. Even when they work, the reasoning goes, they won't make you any money. Instead, investors want to see "innovative" ideas: ideas that push the existing envelope a little further, but don't totally change the map. With free culture projects, however, the situation is precisely inverted: people don't get as excited about contributing to merely "innovative" projects, they <em>want</em> to make "revolutionary" change in the world. High ambitions attract good company, and free licensed projects will do better not to set their sights too low.</p>
</div></div></div><div class="field field-name-taxonomy-vocabulary-7 field-type-taxonomy-term-reference field-label-inline clearfix"><div class="field-label">Tagging:&nbsp;</div><div class="field-items"><div class="field-item even"><a href="/taxonomy/term/136">gnu</a></div><div class="field-item odd"><a href="/taxonomy/term/278">wikipedia</a></div><div class="field-item even"><a href="/taxonomy/term/429">marketing</a></div><div class="field-item odd"><a href="/taxonomy/term/473">olpc</a></div><div class="field-item even"><a href="/taxonomy/term/1646">cbpp</a></div></div></div>Tue, 14 Apr 2009 20:59:01 +0000Terry Hancock3134 at http://www.freesoftwaremagazine.comhttp://www.freesoftwaremagazine.com/articles/rule_5_be_bold#commentsRule #4: Grow, Don't Buildhttp://www.freesoftwaremagazine.com/articles/rule_3_grow_dont_build
<div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even"><!-- Rule #4: Grow, Don't Build -->
<p>Since free software and other free culture products are formed by an organic, incrementalist process, they tend to be highly organic in their design as well. Free software is not so much built as it is <em>grown</em>. Thus, when considering a new project, you must think not about how to break it down into implementable chunks that can be assembled into a working product, but rather about how the project can organically grow—moving from working product to working product as it does so—becoming progressively more useful as it is developed.</p>
</div></div></div><div class="field field-name-taxonomy-vocabulary-7 field-type-taxonomy-term-reference field-label-inline clearfix"><div class="field-label">Tagging:&nbsp;</div><div class="field-items"><div class="field-item even"><a href="/taxonomy/term/79">free software</a></div><div class="field-item odd"><a href="/taxonomy/term/113">linux</a></div><div class="field-item even"><a href="/taxonomy/term/136">gnu</a></div><div class="field-item odd"><a href="/taxonomy/term/352">development</a></div><div class="field-item even"><a href="/taxonomy/term/1660">releases</a></div></div></div>Thu, 02 Apr 2009 05:07:44 +0000Terry Hancock3132 at http://www.freesoftwaremagazine.comhttp://www.freesoftwaremagazine.com/articles/rule_3_grow_dont_build#commentsWhen do we define freedom???http://www.freesoftwaremagazine.com/articles/when_do_we_define_freedom
<div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even"><p>Its an attempt to define freedom in a general way and why freedom is very essential.
Visit:-
http://ithinkless.blogspot.com/2008/07/when-do-we-actually-define-freedom.html</p>
</div></div></div><div class="field field-name-field-category field-type-taxonomy-term-reference field-label-inline clearfix"><div class="field-label">Category:&nbsp;</div><div class="field-items"><div class="field-item even"><a href="/category/opinions">Opinions</a></div></div></div><div class="field field-name-taxonomy-vocabulary-7 field-type-taxonomy-term-reference field-label-inline clearfix"><div class="field-label">Tagging:&nbsp;</div><div class="field-items"><div class="field-item even"><a href="/taxonomy/term/136">gnu</a></div><div class="field-item odd"><a href="/taxonomy/term/1577">digital freedom</a></div></div></div>Tue, 18 Nov 2008 14:34:05 +0000srikar3058 at http://www.freesoftwaremagazine.comhttp://www.freesoftwaremagazine.com/articles/when_do_we_define_freedom#commentsUnjustifiable Criticism of Richard Stallman by Linus Torvaldshttp://www.freesoftwaremagazine.com/articles/unjustifiable_criticism_richard_stallman_linus_torvalds
<div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even"><p>A recent attack piece against Richard Stallman was written by Linus Torvalds on the eve of Obama's election.</p>
<p><a href="http://torvalds-family.blogspot.com/2008/11/black-and-white.html">Black and white</a> by Linus Torvalds</p>
<p>Linus begins with this:</p>
<blockquote>
<p>So I'm pretty well-known for not exactly being a huge fan of the FSF and Richard Stallman, despite the fact that I obviously love the GPLv2 and use it as the license for all my projects that I care about.</p></blockquote></div></div></div><div class="field field-name-field-category field-type-taxonomy-term-reference field-label-inline clearfix"><div class="field-label">Category:&nbsp;</div><div class="field-items"><div class="field-item even"><a href="/category/opinions">Opinions</a></div></div></div><div class="field field-name-taxonomy-vocabulary-7 field-type-taxonomy-term-reference field-label-inline clearfix"><div class="field-label">Tagging:&nbsp;</div><div class="field-items"><div class="field-item even"><a href="/taxonomy/term/113">linux</a></div><div class="field-item odd"><a href="/taxonomy/term/134">richard stallman</a></div><div class="field-item even"><a href="/taxonomy/term/136">gnu</a></div><div class="field-item odd"><a href="/taxonomy/term/1576">linus torvalds</a></div></div></div>Mon, 17 Nov 2008 02:50:48 +0000Paul Gaskin3057 at http://www.freesoftwaremagazine.comhttp://www.freesoftwaremagazine.com/articles/unjustifiable_criticism_richard_stallman_linus_torvalds#commentsStephen Fry wishes GNU/Linux a happy 25th birthdayhttp://www.freesoftwaremagazine.com/articles/stephen_fry_wishes_gnu_linux_happy_25th_birthday
<div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even"><p>I was surprised and delighted to find this video presentation by one of my favorite performers, Stephen Fry, called "Happy Birthday to GNU", on the <a href="http://www.gnu.org">GNU project</a> homepage.</p>
<p>Posted on September 1st, in honor of GNU's 25th anniversary, it turns out to be only the latest in a series of entries on Mr. Fry's official <a href="http://stephenfry.com/blog/">blog site</a> praising the virtues of free software.</p>
</div></div></div><div class="field field-name-field-category field-type-taxonomy-term-reference field-label-inline clearfix"><div class="field-label">Category:&nbsp;</div><div class="field-items"><div class="field-item even"><a href="/category/opinions">Opinions</a></div></div></div><div class="field field-name-taxonomy-vocabulary-7 field-type-taxonomy-term-reference field-label-inline clearfix"><div class="field-label">Tagging:&nbsp;</div><div class="field-items"><div class="field-item even"><a href="/taxonomy/term/79">free software</a></div><div class="field-item odd"><a href="/taxonomy/term/113">linux</a></div><div class="field-item even"><a href="/taxonomy/term/136">gnu</a></div><div class="field-item odd"><a href="/taxonomy/term/344">video</a></div><div class="field-item even"><a href="/taxonomy/term/1523">endorsement</a></div></div></div>Wed, 10 Sep 2008 09:47:52 +0000Terry Hancock2999 at http://www.freesoftwaremagazine.comhttp://www.freesoftwaremagazine.com/articles/stephen_fry_wishes_gnu_linux_happy_25th_birthday#commentsLinux: has the horse bolted?http://www.freesoftwaremagazine.com/articles/linux_has_horse_bolted
<div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even"><p>Richard Stallman wants to popularise the term GNU/Linux instead of using the currently popular term Linux. He correctly states that the term Linux, besides being thoroughly inaccurate, totally fails to introduce new users to the legal and philosophical concepts that underlie the basis of the GNU/Linux OS; but is it feasible to make such a change at this late stage?</p>
<p>Some weeks ago, trolling through prospective articles for Free Software Daily, I encountered a blog, describing the evolution of “Linux”. It was aimed at Newbies. The blog correctly described Linus Torvalds as the creator of the Linux kernel and a few more recent developments, but that was it. No mention was made that Richard Stallman actually created much of what is now called “Linux”, no mention of the GPL, or how it works, no mention of the copyleft legal concept and no mention of other responsibilities placed on users and developers.</p>
<p>All of Richard Stallman's worst fears confirmed in one blog.</p>
</div></div></div><div class="field field-name-field-category field-type-taxonomy-term-reference field-label-inline clearfix"><div class="field-label">Category:&nbsp;</div><div class="field-items"><div class="field-item even"><a href="/category/opinions">Opinions</a></div></div></div><div class="field field-name-taxonomy-vocabulary-7 field-type-taxonomy-term-reference field-label-inline clearfix"><div class="field-label">Tagging:&nbsp;</div><div class="field-items"><div class="field-item even"><a href="/taxonomy/term/135">fsf</a></div><div class="field-item odd"><a href="/taxonomy/term/136">gnu</a></div><div class="field-item even"><a href="/taxonomy/term/164">gnu/linux</a></div><div class="field-item odd"><a href="/taxonomy/term/232">gpl</a></div><div class="field-item even"><a href="/taxonomy/term/889">blogs</a></div><div class="field-item odd"><a href="/taxonomy/term/1524">stallman</a></div><div class="field-item even"><a href="/taxonomy/term/1525">torvalds</a></div><div class="field-item odd"><a href="/taxonomy/term/1526">fsd</a></div></div></div>Wed, 10 Sep 2008 09:42:49 +0000Laurie Langham3000 at http://www.freesoftwaremagazine.comhttp://www.freesoftwaremagazine.com/articles/linux_has_horse_bolted#commentsAutotools: a practitioner's guide to Autoconf, Automake and Libtoolhttp://www.freesoftwaremagazine.com/books/autotools_a_guide_to_autoconf_automake_libtool
<div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even"><p>There are few people who would deny that Autoconf, Automake and Libtool have revolutionized the free software world. While there are many thousands of Autotools advocates, some developers absolutely <em>hate</em> the Autotools, with a passion. Why? Let me try to explain with an analogy.
<!--break--></p>
<p>In the early 1990's I was working on the final stages of my bachelor's degree in computer science at Brigham Young University. I took a 400-level computer graphics class, wherein I was introduced to C++, and the object-oriented programming paradigm. For the next 5 years, I had a love-hate relationship with C++. I was a pretty good C coder by that time, and I thought I could easily pick up C++, as close in syntax as it was to C. How wrong I was. I fought late into the night, more often than I'd care to recall, with the C++ compiler over performance issues.</p>
<p>The problem was that the most fundamental differences between C++ and C are not obvious to the casual observer. Most of these differences are buried deep within the C++ language specification, rather than on the surface, in the language syntax. The C++ compiler generates code beneath the covers at a level never even conceived of by C compiler writers. This level of code generation provides functionality in a few lines of C++ code that requires dozens of lines of C code. Oh, yes--you can write object-oriented software in C. But you are required to manage all of the details yourself. In C++, these details are taken care of for you by the compiler. The advantages should be clear.</p>
<p>But this high-level functionality comes at a price--you have to learn to understand what the compiler is doing for you, so you can write your code in a way that complements it. Not surprisingly, often the most intuitive thing to do in this situation for the new C++ programmer is to inadvertently write code that works against the underlying infrastructure generated by the compiler.</p>
<p>And therein lies the problem. Just as there were many programmers then (I won't call them software engineers--that title comes with experience, not from a college degree) complaining of the nightmare that was C++, so likewise there are many programmers today complaining of the nightmare that is the Autotools. The differences between make and Automake are very similar to the differences between C and C++. The most basic single-line Makefile.am generates a Makefile.in file (an Autoconf template) containing nearly 350 lines of make script.</p>
<h1>Who should read this book</h1>
<p>This book is written for the open source software package maintainer. I'm purposely not using the terms "free software" or "proprietary software that's free". The use of the term "open source" is critical in this context. You see, open source defines a type of software distribution channel. One in which the primary method of obtaining software functionality is downloading a source archive, unpacking, building and installing the built products on your system. Free software may be published in binary form. Proprietary software may be given away. But open source software implies source-level distribution.</p>
<p>Source-level distribution relegates a particular portion of the responsibility of software development to the end-user that has traditionally been assumed by the software developer. But end-users are not developers, so most of them won't know how to properly build your package. What to do, what to do... The most widely adopted approach from the earliest days of the open source movement was to make the package build process as simple as possible for the end user, such that she could perform a few well-known steps and have your package cleanly installed on her system.</p>
<p>Most packages are built using makefiles, and the make utility is as pervasive a tool as anything else that's available. It's very easy to type <code>make</code>--but that's not the problem. The problem crops up when the package doesn't build successfully, because of some unanticipated difference between the user's system and the developer's system.</p>
<p>Thus was born the ubiquitous configure script--initially a simple shell script that configured the end-user's environment so that the make utility could successfully build a source package on the end-user's system. Hand-coded configure scripts helped, but they weren't the final answer. They fixed about 65 percent of the problems resulting from system configuration differences--and they were a pain in the neck to write properly. Dozens of changes were made incrementally over a period of years, until the script would work properly on most systems anyone cared about. But the entire process was clearly in need of an upgrade.</p>
<p>Do you have any idea of the number of build-breaking differences there are between existing systems today? Neither do I, but there is a handful of developers in the world who know a large percentage of these differences. Between them and the free software community, the Autotools were born. The Autotools were designed to create configure scripts and makefiles that work correctly and provide significant chunks of valuable end-user functionality under most circumstances, and on most systems--even systems not initially considered (or even known about) by the package maintainer.</p>
<p>So, returning to that passionate hate felt by some developers toward the Autotools: If you get your head screwed on straight about the primary purpose of the Autotools, then hate quickly turns into respect--and even appreciation. Often the root of such hate is a simple misunderstanding of the rationale behind the Autotools. The purpose of the Autotools is not to make life simpler for the package maintainer (although it really does in the long run). <em>The purpose of the Autotools is to make life simpler for the end-user.</em></p>
<p>To drive my point home, I'll wager that you'll never see a Linux distribution packager spouting hateful sentiment on the Autotools mailing lists. These people are in a class of engineers by themselves. They're generally quiet on mailing lists--asking an occasional well-considered question when they really need to--but lurking and learning, for the most part. Packagers grasp the advantages of the Autotools immediately. They embrace them by studying them until they know them like an expert C++ programmer knows his compiler. They don't write many Autoconf input scripts, but they do patch a lot of them.</p>
<p>How do you become such an expert? I recommend you start with this book. I've organized it in the best way I know how to help you get your head around the functionality provided by the Autotools. But don't stop there. Pick up the manuals. They're free, and links are provided in the References section of this book, but they're easy to find with a simple internet query. I've left a LOT of details out of this book, because my purpose is to quickly get you up to speed on understanding and using the Autotools. The Autotools manuals are well-written and concise, but more importantly, they're complete. After reading this book, they should be a cake walk.</p>
<p>Then study open source and free software packages that use the Autotools. See what other experts have done. Learning by example is an excellent way to begin to retain the information you've read. Finally, instrument some of your own projects with the Autotools. Doing is by far the best way to learn. The initial reading will reduce the frustration of this exercise to something bearable.</p>
<p>Above all, remember why you're doing this--because you want your end-user's experience with your package to be as delightful as possible. No open source project was ever successful until it had a well-established user base, and you don't get there by alienating your users. You do it by creating a user build, installation and operation experience that shines. You'll still need to handle the operation experience, of course, but Autotools can provide a <em>great</em> multi-platform build and installation experience--with far less effort on your part.</p>
<h1>The book that was never to be</h1>
<p>I've wondered often during the last eight years how strange it is that the <em>only</em> third-party book on Autotools that I've been able to discover is the New Rider's 2000 publication of GNU AUTOCONF, AUTOMAKE and LIBTOOL, affectionately known in the community as "The Goat Book".</p>
<p>I've been in this industry for 25 years, and I've worked with free software for quite some time now. I've learned a lot about free software maintenance and development--most of it, unfortunately, by trial and error. Had there <em>been</em> other books on the topic, I would have snatched them all up immediately, rather than spend hours--even days sometimes--trying to get the Autotools to do something I could have done in a makefile in a few minutes.</p>
<p>I've been told by publishers that there is simply no market for such a book. In fact, one editor told me that he himself had tried unsuccessfully to entice authors to write this book a few years ago. His authors wouldn't finish the project, and the publisher's market analysis indicated that there was very little interest in the book.</p>
<p>No interest?! Let's analyze this picture: There are nearly 200,000 free software projects on sourceforge.net alone. If only 10 percent of those are still active, that's still 20,000 live projects. If 80 percent of those are Linux or Unix based packages, that's 16,000 free software packages that might use the Autotools. And that's only sourceforge.net. Each of those packages has at least one maintainer--often two or three. Each of those maintainers <em>probably</em> uses (or has tried to use) the Autotools. Many of them have a fairly solid understanding of the Autotools by now, but at what expense in time and effort did they gain this understanding?</p>
<p>Publishers believe that free software developers tend to disdain written documentation--perhaps they're right. Interestingly, books on Perl sell like Perl's going out of style--which is actually somewhat true these days--and yet people are still buying enough Perl books to keep their publishers happy. All of this explains why there are ten books on the shelf with animal pictures on the cover for perl, but literally nothing for free software developers.</p>
<p>The authors of the Goat Book, Gary Vaughan, Ben Elliston, Tom Tromey and Ian Lance Taylor, are well known in the industry, to say the least--indeed, they're probably the best people I know of to write a book on the Autotools. But, as fast as free software moves these days, a book published in 2000 might as well have been published in 1980. Nevertheless, because of the need for <em>any</em> book on this subject, <a href="http://www.amazon.com/GNU-Autoconf-Automake-Libtool-Circle/dp/1578701902">the Goat Book</a> is still being sold new in bookstores. In fairness to the authors, they have maintained an <a href="http://sourceware.org/autobook">online version</a> through February of 2006.</p>
<p>The biggest gripe I have with the Goat Book is the same gripe I have with the GNU manuals themselves. I'm talking about the shear volume of information that is assumed to be understood by the reader. The Goat Book is written in a very non-linear fashion, so it's difficult to learn anything from it. It's a great reference, but a terrible tutorial. Perhaps the authors were targeting an audience that had already graduated to more advanced topics. In either case, the Goat Book, while being very complete from a content perspective, is definitely not a great learning resource for the beginner.</p>
<p>And yet a large percentage of their readership today are young people just starting out with Unix and Linux, and most of their issues center around Unix utilities not generally associated with the Autotools. Take <code>sed</code>, for example: What a dream of a tool to work with--I love it! More to the point however, a solid understanding of the <em>basic</em> functionality of <code>sed</code>, <code>m4</code>, shell script and other utilities is critical to understanding the proper use of the Autotools. The Goat Book does cover the m4 macro processor in great detail, but it's not clear to the uninitiated that one might do well to start with Chapter 21. Understanding how something works under the covers is often a good way to master a topic, but a general introduction at an appropriate point in higher-level discussions can make all the difference to a beginner.</p>
<p>Existing GNU documentation is more often reference material than solution-oriented instruction. What we need is a cookbook-style approach, covering real problems found in real projects. As each recipe is mastered, the reader makes small intuitive leaps--I call them minor epiphanies. Put enough of these under your belt and overall mastery of the Autotools is ultimately inevitable.</p>
<p>Let me give you another analogy: I'd been away from math classes for about three years when I took my first college calculus course. I struggled the entire semester with little progress. I understood the theory, but I had trouble with the homework. I just didn't have the background I needed. So the next semester, I took college algebra and trigonometry as half-semester classes each ("on the block", to use the vernacular). At the end of that semester I tried calculus again. This time I did very well--finishing the class with a solid <code>A</code> grade. What was missing the first time? Just basic math skills. You'd think it wouldn't have made that much difference, but it really does.</p>
<p>The same concept applies to understanding the Autotools. You need a solid understanding of the tools upon which the Autotools are built in order to become proficient with the Autotools themselves. For example, here's a message I came across a few days ago while I was perusing the Autoconf mailing list:</p>
<div markdown='0'><pre>
>>> If I do this:
>>>
>>> AC_CHECK_FUNC(
>>> [chokeme],
>>> [],
>>> []
>>> )
>>>
>>> It will yield shell code that ends in:
>>>
>>> if
>>> :
>>> else
>>>
>>> fi
>>>
>>> Which produces a configure script that dies
>>> with:
>>> "syntax error near unexpected token `fi'"
>>>
>>> Is this an autoconf bug, or user error on
>>> my part?
>> The else part is not empty, it consists of
>> explicit whitespace. When collecting arguments
>> only unquoted leading whitespace is skipped by
>> m4, trailing whitespace (quoted or not) is
>> preserved. You need to put the closing paren
>> immediately after the closing quote of the
>> argument.
> Is that something I should always do? I've been
> consistently putting the closing paren on its
> own line. Is that a "never"?
You can instead use dnl to ignore the trailing
whitespace, provided the closing paren is in
column 1.</pre></div>
<p>Now, it's truly wonderful that we have experts on mailing lists who are so willing to respond cheerfully to questions like this, and so quickly--this exchange took place within a few hours. However, without looking, I submit that similar questions have probably been asked dozens of times in the last 5 years. Not because mailing list posters don't read the archives (although I'll admit that they probably don't often do so), but rather because this problem can rear its ugly head in many different ways, none of which look remotely related to each other in the eyes of the uninitiated.</p>
<p>Here are some of the problems with the response to this request: Does the original poster (OP) even know what m4 is? If so, does he realize he's running it when he executes "autoconf" to generate his configure script? Alright, suppose he does; either way, he's clearly not an m4 expert or he wouldn't have needed help with this issue to begin with.</p>
<p>Does the OP understand the concept of quoting as it relates to m4 or to Autoconf? Perhaps he's always simply copied one configure.ac script to another, modifying as little as possible to get it to work with a new project. Given the high-level nature of configure.ac, this is entirely possible (I've done it myself). If so, he may just assume that the square brackets are necessary around each parameter in an Autoconf macro. Given the nature of the question, I'd say the OP believes that the entirety of each parameter is contained within the brackets, so this assumption is not at all improbable.</p>
<p>Another problem is seen in the final response where the OP is told, "...instead use dnl to ignore the trailing whitespace..." If the OP didn't understand m4 whitespace rules, he probably doesn't know about the m4 built-in macro, <code>dnl</code>. If that's the case, then this response made no sense to him whatsoever. Even if he did understand what he was to do--perhaps based on having seen <code>dnl</code> being used in other configure.ac scripts, apparently as a secondary form of comment delimiter--he probably doesn't understand the full impact or use of this macro. Regardless, you can bet there are other mailing list readers who experienced far more confusion over this exchange.</p>
<p>This book attempts to alleviate some of the confusion and reduce the existing learning curve by presenting the Autotools in a manner conducive to an open source beginner learning how to use them.</p>
<h1>How this book is organized</h1>
<p>Chapter 1 presents a general overview of the packages that are considered part of the GNU Autotools. This chapter describes the interaction between these packages, and the files consumed by and generated by each one. In each case, I've provided a graphic depiction of the flow of data from hand-coded input files, to final output files. Don't worry if you feel overwhelmed after reading Chapter 1. The details will become clear later. I recommend that you give this chapter a quick read to start with, and then come back to it later, after you've read the rest of this book.</p>
<p>Chapter 2 covers free software project structure and organization. This chapter also goes into detail on the GNU coding standards and the Filesystem Hierarchy Standard documents, both of which have played vital roles in the design of the Autotools. It presents some fundamental tenets upon which the design of each of the Autotools is based. With these concepts, you'll be prepared to understand some of the most fundamental rationale behind architectural decisions made by the Autotools developers. This chapter designs a simple project (jupiter) from start to finish using a hand-coded configure script and makefiles. It builds on jupiter in a step-wise fashion, as we begin to discover useful functionality to make our's and our end-users' tasks simpler, relative to the jupiter project. The project is built on principles taken from these two documents. As a side benefit, the GNU manuals for the Autotools should begin to make a lot more sense to you.</p>
<p>Chapters 3, 4 and 5 cover the basic purpose and use of the GNU Autoconf, Automake and Libtool packages, respectively. If you already have a basic familiarity with these packages, you can probably skip these chapters, but please feel free to revisit them if you find yourself in over your head with the remaining chapters.</p>
<p>Chapter 6 takes an existing complex open source project (FLAIM) through the process of converting from a hand-coded build system to an Autotools build system, from start to finish. The example provided by this chapter will use the concepts presented in previous chapters to take it from the original hand-coded makefiles to a complete Autotools project, implementing all of the features provided by the original build system. This process should help you to understand how you might "autoconfiscate" one of your own existing complex projects.</p>
<p>Chapter 7 is a compilation of tips and tricks or resusable solutions that I've come across during my experience with the Autotools. I could have shoe-horned this information into more or less appropriate locations in the preceding chapters. I chose not to do this for two reasons: First, I didn't want to clutter the main text with side issues--one of my goals in writing this book was to make it readable. Second, I didn't want to reduce the importance of these items by slipping them in somewhere. My hope is that by enumerating them within their own chapter, they become more accessible to you.</p>
<p>Appendix A provides an overview of those features of the M4 macro processor that are relevant to obtaining a solid understanding of Autoconf.</p>
<p>Finally, the References section includes relevant links to the best material on Autotools available on the internet, including manuals and tutorials.</p>
</div></div></div><div class="field field-name-taxonomy-vocabulary-7 field-type-taxonomy-term-reference field-label-above"><div class="field-label">Tagging:&nbsp;</div><div class="field-items"><div class="field-item even"><a href="/taxonomy/term/79">free software</a></div><div class="field-item odd"><a href="/taxonomy/term/116">cross-platform</a></div><div class="field-item even"><a href="/taxonomy/term/136">gnu</a></div><div class="field-item odd"><a href="/taxonomy/term/352">development</a></div><div class="field-item even"><a href="/taxonomy/term/375">foss</a></div><div class="field-item odd"><a href="/taxonomy/term/1058">make</a></div><div class="field-item even"><a href="/taxonomy/term/1313">autotools</a></div><div class="field-item odd"><a href="/taxonomy/term/1314">autoconf</a></div><div class="field-item even"><a href="/taxonomy/term/1399">automake</a></div><div class="field-item odd"><a href="/taxonomy/term/1400">libtool</a></div></div></div>Thu, 08 May 2008 03:10:18 +0000John Calcote2753 at http://www.freesoftwaremagazine.comhttp://www.freesoftwaremagazine.com/books/autotools_a_guide_to_autoconf_automake_libtool#commentsHow to love Free Software in 3 steps: configure, make, make installhttp://www.freesoftwaremagazine.com/articles/how_love_free_software_3_steps
<div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even"><p>I recently re-read the article <a href="http://www.freesoftwaremagazine.com/columns/how_to_hate_free_software_in_3_easy_steps">how to hate free software in 3 easy steps</a> by Steven Goodwin. I'm no programmer, but then I've also installed a few distributions myself. And frankly, I have trouble relating to that post.</p>
<p>Several points were made in the article's comments, some being that non-programmers don't compile from source anyway, compiling from source requires you to be a programmer, and other operating systems don't crash when you tinker with their partitions.</p>
<p>Excuse me?</p>
<!--[break]-->
</div></div></div><div class="field field-name-field-category field-type-taxonomy-term-reference field-label-inline clearfix"><div class="field-label">Category:&nbsp;</div><div class="field-items"><div class="field-item even"><a href="/category/opinions">Opinions</a></div></div></div><div class="field field-name-taxonomy-vocabulary-7 field-type-taxonomy-term-reference field-label-inline clearfix"><div class="field-label">Tagging:&nbsp;</div><div class="field-items"><div class="field-item even"><a href="/taxonomy/term/113">linux</a></div><div class="field-item odd"><a href="/taxonomy/term/136">gnu</a></div><div class="field-item even"><a href="/taxonomy/term/1058">make</a></div><div class="field-item odd"><a href="/taxonomy/term/1312">source</a></div></div></div>Sat, 08 Mar 2008 00:00:00 +0000Mitch Meyran2728 at http://www.freesoftwaremagazine.comhttp://www.freesoftwaremagazine.com/articles/how_love_free_software_3_steps#comments“GNU”, “Linux”, or neither...?http://www.freesoftwaremagazine.com/articles/gnu_linux_neither
<div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even"><p>I’m sure everyone reading this has heard the debate over whether that top dog free operating system should be called “Linux” or “GNU/Linux”, but how big a contribution <em>is</em> GNU <em>or</em> Linux to that operating system?</p>
</div></div></div><div class="field field-name-field-category field-type-taxonomy-term-reference field-label-inline clearfix"><div class="field-label">Category:&nbsp;</div><div class="field-items"><div class="field-item even"><a href="/category/opinions">Opinions</a></div></div></div><div class="field field-name-taxonomy-vocabulary-7 field-type-taxonomy-term-reference field-label-inline clearfix"><div class="field-label">Tagging:&nbsp;</div><div class="field-items"><div class="field-item even"><a href="/taxonomy/term/76">success</a></div><div class="field-item odd"><a href="/taxonomy/term/79">free software</a></div><div class="field-item even"><a href="/taxonomy/term/113">linux</a></div><div class="field-item odd"><a href="/taxonomy/term/136">gnu</a></div><div class="field-item even"><a href="/taxonomy/term/764">statistics</a></div></div></div>Thu, 29 Mar 2007 12:46:00 +0000Terry Hancock2168 at http://www.freesoftwaremagazine.comhttp://www.freesoftwaremagazine.com/articles/gnu_linux_neither#commentsDoes free software taste great, or is open source less filling?http://www.freesoftwaremagazine.com/node/1838
<div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even"><p>Which do you like best: the satisfying, rich taste of principle in free software? Or do you prefer the less morally filling and pragmatic goodness of open source? Do you wish people would stop endlessly rehashing the whole question of "free" versus "open source?" Or do you enjoy the chance to talk about goals and philosophy? As you might suspect, since I'm bringing it up...</p>
</div></div></div><div class="field field-name-field-category field-type-taxonomy-term-reference field-label-inline clearfix"><div class="field-label">Category:&nbsp;</div><div class="field-items"><div class="field-item even"><a href="/category/opinions">Opinions</a></div></div></div><div class="field field-name-taxonomy-vocabulary-7 field-type-taxonomy-term-reference field-label-inline clearfix"><div class="field-label">Tagging:&nbsp;</div><div class="field-items"><div class="field-item even"><a href="/taxonomy/term/79">free software</a></div><div class="field-item odd"><a href="/taxonomy/term/134">richard stallman</a></div><div class="field-item even"><a href="/taxonomy/term/135">fsf</a></div><div class="field-item odd"><a href="/taxonomy/term/136">gnu</a></div><div class="field-item even"><a href="/taxonomy/term/137">drm</a></div></div></div>Mon, 30 Oct 2006 07:30:00 +0000Scott Carpenter1838 at http://www.freesoftwaremagazine.comhttp://www.freesoftwaremagazine.com/node/1838#commentsThe GNU GPL - a software license for yesterday, today and tomorrowhttp://www.freesoftwaremagazine.com/node/1721
<div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even"><p>With the draft of the GNU General Public License Version 3 (GPLv3) have come many interesting comments, although not all of which I have found positive. While I understand proprietary vendors have offered complaints against a license they do not even use, I was surprised that Linus Torvalds had taken some issues which I thought were in any case misguided criticisms.</p>
</div></div></div><div class="field field-name-field-category field-type-taxonomy-term-reference field-label-inline clearfix"><div class="field-label">Category:&nbsp;</div><div class="field-items"><div class="field-item even"><a href="/category/opinions">Opinions</a></div></div></div><div class="field field-name-taxonomy-vocabulary-7 field-type-taxonomy-term-reference field-label-inline clearfix"><div class="field-label">Tagging:&nbsp;</div><div class="field-items"><div class="field-item even"><a href="/taxonomy/term/136">gnu</a></div><div class="field-item odd"><a href="/taxonomy/term/137">drm</a></div><div class="field-item even"><a href="/taxonomy/term/152">gplv3</a></div><div class="field-item odd"><a href="/taxonomy/term/232">gpl</a></div><div class="field-item even"><a href="/taxonomy/term/302">licenses</a></div></div></div>Wed, 16 Aug 2006 02:44:58 +0000David Sugar1721 at http://www.freesoftwaremagazine.comhttp://www.freesoftwaremagazine.com/node/1721#commentsThe GNU "Lesser" General Public License gets some lovehttp://www.freesoftwaremagazine.com/node/1681
<div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even"><p>With the introduction of the GNU GPLv3, the GNU Lesser General Public License (L-GPL) has seen much less attention. This has changed with the recent GPLv3 conference in Barcelona, and I think it has changed for the better.</p>
</div></div></div><div class="field field-name-field-category field-type-taxonomy-term-reference field-label-inline clearfix"><div class="field-label">Category:&nbsp;</div><div class="field-items"><div class="field-item even"><a href="/category/opinions">Opinions</a></div></div></div><div class="field field-name-taxonomy-vocabulary-7 field-type-taxonomy-term-reference field-label-inline clearfix"><div class="field-label">Tagging:&nbsp;</div><div class="field-items"><div class="field-item even"><a href="/taxonomy/term/136">gnu</a></div><div class="field-item odd"><a href="/taxonomy/term/152">gplv3</a></div><div class="field-item even"><a href="/taxonomy/term/232">gpl</a></div><div class="field-item odd"><a href="/taxonomy/term/301">lgpl</a></div><div class="field-item even"><a href="/taxonomy/term/302">licenses</a></div></div></div>Tue, 18 Jul 2006 14:28:16 +0000David Sugar1681 at http://www.freesoftwaremagazine.comhttp://www.freesoftwaremagazine.com/node/1681#comments