Student Identification ====================== Name: Stefano Lattarini Email address: address@hidden The name of the project ======================= automake - Exploit more features of GNU make in Automake Abstract ======== The primary target of this project is to enable Automake-generated Makefiles to exploit more features of GNU make. The exact details of how and on what level this is to be implemented (e.g., at Automake time by the developer, at configure time by the user, or a mixture of both) is to be determined in the design phase of the project. Portability of Automake-generated Makefiles =========================================== One of the main goals of Automake is to produce Makefiles that are highly portable. In fact, Automake-generated Makefiles are expected to work "out-of-the-box" not only with with GNU and BSD make (recent and older versions alike), but also with most vendor implementations of make (Solaris, AIX, HP-UX, IRIX, ...). This portability is much appreciated by many developers who use Automake; see for example these pots of a recent discussion on the automake mailing list: Automake is quite successful in this regard, managing to implement successfully and in portable fashion some advanced, and even tricky, features; among them, automatic dependency tracking, an advanced and highly parallelizable testsuite harness (the "parallel-tests" option) and the ability to dynamically render make's output less verbose and more informative (the "silent-rules" option). Moreover, Automake goes to great length to work around known bugs and limitations of different make implementations, and to accommodate for incompatibilities between them (one example for all: the dreaded VPATH issues). But all this portability comes at a price ... When portability brings disadvantages ===================================== The Makefiles generated by Automake are definitely suboptimal w.r.t. GNU make, which have much more advanced capabilities than those such Makefiles expect and use. The Automake-generated Makefiles are thus slower, larger, and more difficult to understand then they would be by taking advantage of more GNU make features. And while, for example, Autoconf-generated configure scripts can dynamically search for a better shell and/or probe the shell features *at runtime* to try to activate optimized implementations of the offered primitives, a similar approach is nigh to impossible for the Automake-generated Makefiles, due to very limited nature of the make language (both as specified by POSIX, and as implemented by many make programs Automake strives to support). Benefits of this proposal ========================= - Various optimizations in speed, size and clarity of the generated Makefiles, when GNU make is used or can be assumed. - Such optimizations would be particularly useful since they would benefit 80-90% of the user base. In fact, GNU/Linux installations (for which GNU make is the system make) represent a high percentage of UNIX installations; moreover, GNU/make is also the default make program for the two more widespread UNIX-like environments for Microsoft Windows (Cygwin and MSYS/MinGW); finally, lots of BSD and Solaris users have GNU make installed in addition to their native make (FreeBSD offers a port and a package for it, and Sun ships it as third-party officially supported software). - Probably make the use of Automake more widespread and enticing. In fact, in the present state of facts, some projects are scared away because the Automake Makefiles are ugly, complicated, and, worse of all, quite suboptimal when run with GNU make, which might very well be the only make implementation those projects want to support or can afford to support; see for example: Deliverables ============ Design decisions and documentation about how the developer, the user, or both can enable GNU make specific code in the generated Makefiles. Extend the automake script to implement these design decisions, thus offering a base or "scaffolding" upon which future GNU make specific optimizations and extensions might be build. Various optimizations/improvements for GNU make: - Get rid of complex VPATH search emulation and compatibility layer (this should offers small but nice enhancements in simplicity and speed). - Improve the parallel testsuite harness ("parallel-tests" option): make it faster, make its implementation simpler, and above all make it able to cope with very long $(TESTS) without exceeding system command-line length limits (or other system-specific length limits); - Similarly improve the dist target, optimizing it and removing limits on the length of $(DIST_FILES); - Handling of target-specific flags in Automake could be reimplemented using the GNU make support for "target-specific variable values" and the fact that GNU make defines the automatic variable '$<' also in normal (non-suffix) rules. And maybe some further optimizations/improvements that we'll implement only if not short of time (e.g.: build info files into builddir, not into srcdir; optimize install rules for speed and more parallelism; in the recipes, try, where possible, to handle text transformation using GNU make special macros instead of having to rely on forking external programs). Plan and Roadmap ================ Q: How will you and your mentor track your progress as you work on the project? A: Since technical discussions about design and implementation of new Automake features take place on the public lists and/or , most measurable progresses are publicly available there, and thus quite easy to judge. Also, every new feature going in Automake must have proper testsuite coverage, so that we can be confident that the new code will really works. Finally, the project mentor has been the Automake maintainer since 4/5 years now, so that he's surely able to judge how a partial implementation if faring, and what the chances are for it to be completed in time. Q: How the mid-term evaluation of your project will be made? A: 1. The design for the new future must be clearly specified, and there has to be fair consensus about it in the community. 2. Scaffolding for the new feature in the Automake script and scaffolding for enhanced coverage in the testsuite *must* be in place. 3. These scaffolding must have been used to implement some first easy optimization (e.g. simplification of VPATH handling), to ensure that they really works. 4. The improvements described above (in "Deliverables") to the parallel testsuite harnesses must have been implemented Q: Remember to mention any periods during the summer when you won't actually be available to work on the project (though remember, the Summer of Code project is expected to be your main activity). A: I plan to be available for basically all the period of the project. If not the whole day, at least half a day, basically each day (either morning and early afternoon, or later afternoon and evening). There might be *very few* short periods (one, max two days) when I'll be completely off-line and "away from keyboard" -- I'll let the mentor know about them in advance, obviously. Communication ============= First, I'm already in contact with the mentor, due to my on-going involvement with the Automake project. I've also been in contact with the backup mentor, due to my (small) contributions to Autoconf. In the Automake projects, discussions about design and documentation, and proposals and reviews of patches are public, taking place on the project's pre-existing and well-established mailing lists. The mentor reads them regularly, so that posting patches an ideas there is a sure way to have them considered and reviewed by him (and also by other mailing list readers, which might contribute with their own useful insights, questions, and experiences. Finally, my experiences have showed that real-time interaction with the mentor to work on a particular issue (either on-list or off-list) is not only possible, but also efficient and effective. Qualification ============= I'm quite familiar with the policies of the Automake project (especially coding standards, patch review process, and portability concerns). Moreover, the copyright assignment to the Free Software Foundation that allows me to contribute code to the Automake official repository is already in place (and has been for more than a year and a half now). I've started contributing to the Automake project an year and a half ago. During the last year, my involvement with the project has steadily increased: I've posted more patches and participated more actively to discussions on the mailing lists, I've been granted commit rights, and I've started helping with the bug tracker and related issues. I plan to continue my involvement with Automake in the foreseeable future. I have access to some systems to test my work on: Debian GNU/Linux (with custom installation of older version of tools and compilers), FreeBSD 8.0, and Solaris 10. This can help me in finding out early potential portability problems. Finally, I'm principally a GNU make user myself, and I have some personal projects which currently use Automake, but also require GNU make in their build system (an higher portability wouldn't be required nor really useful for them). So I feel honestly motivated at making the user experience better for those who use GNU make. In fact, in the recent past, I had even proposed (on the automake mailing list) that Automake should start supporting *only* GNU make; but many users pointed out that the extra portability currently offered by Automake is really valuable to them, thus rendering the hybrid approach advocated in this proposal a necessity. Here is a link to the relevant discussion: Also, it's worth noting that the opinions and experiences expressed in that thread by real-world users helped shaping this proposal, which IMHO gives it more strength and sense of purpose.