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.
DETAILS:
See attachements.
-*-*-
In all honesty, I'm not completely sure the deliverables promised in this
proposal are truly enough to warrant a GSoC assignation; but at the moment
I cannot think how to extend them without risking to make the proposal too
big, thus ending up with an incomplete (or worse malfunctioning) result.
Do you think the deliverables are enough? If not, do you have suggestions
about how they could be extended/improved?
Also, if there are GNU make specific improvements you'd like to see in
Automake-generated Makefiles, but which are not listed in my proposal,
feel free to speak up. Feedback is appreciated.
Thanks,
Stefano
Student Identification
======================
Name: Stefano Lattarini
Email address: stefano.lattar...@gmail.com
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:
<http://lists.gnu.org/archive/html/automake/2011-01/msg00071.html>
<http://lists.gnu.org/archive/html/automake/2011-01/msg00115.html>
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:
<http://lists.gnu.org/archive/html/automake/2011-01/msg00091.html>
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 <automake@gnu.org>
and/or <automake-patc...@gnu.org>, 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:
<http://lists.gnu.org/archive/html/automake/2011-01/msg00050.html>
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.
Tentative roadmap for GSoC project "automake - Exploit more features
of GNU make in Automake".
1. COLLECT INFORMATION: Before April 20
----------------------------------------
Read carefully the GNU make manual for the latest version (3.82).
While I'm already quite familiar with GNU make, there are features of
it I've never used, and worse, probably some advanced features I'm
totally unaware of -- obtaining at least a theoretical knowledge of
the latter is a must.
Read the NEWS of the GNU make distribution, to get a grasp of what
features and bugs have been introduced when, what bugs have been fixed
when, and to find out about possible incompatibilities between the
various versions.
Read/skim the documentation of older GNU make versions (at least
back to 3.80, maybe also 3.79 and 3.78), and start experimenting with
them.
If there's enough time, take a look at Open Source project(s) which
uses GNU make in an advanced fashion, and see what they can teach.
2. EXPERIMENTING: April 20 - May 15 (Before the official coding time)
-----------------------------------------------------------------------
Start to think about, and experiment with, some possible improvements
to Automake-generated Makefiles that can be introduced when GNU make is
assumed.
The best way to do so is probably starting to study and tweak
Automake-generated Makefiles of real-world, medium-size projects
(e.g., GNU coreutils or GNU grep).
This phase should help with the subsequent "real" implementation, by
providing some ideas, and quite likely also code (incomplete of course,
but probably good as a starting point and/or for "cut & paste"), and
tentative testcases.
3. BASIC DESIGN: May 15 - June 5 (Official coding period starts May 23)
-------------------------------------------------------------------------
The mentor has some unfinished patches relevant to this project: see
and discuss them.
Try to find out what is the best strategy to produce GNU make specific
code in the generated Makefile. There might be multiple approaches,
not necessarily mutually exclusive; for example:
- GNU make specific code could be guarded by Automake conditionals;
i.e., it could be activated/deactivated at configure time, either
on autodetection or upon explicit request from the user.
- Automake could support an option instructing it to output *only*
GNU make-specific code in the generated Makefile.in.
- Automake could generate side by side, from a single Makefile.am,
both a Makefile.in and a GNUmakefile.in, both to be shipped; or
offer a more flexible variation of this approach.
These approaches should of course be discussed with the mentor *and*
on the Automake public mailing lists, before a final decision can be
reached.
Ideally, (almost) all the test cases of the Automake testsuite should
continue to pass when running with GNU make and with the GNU make
specific output active. What is the best way to automatize this check
without invasive testsuite modifications? This might not be obvious,
and will require some consideration and thinking.
Finally, in this phase, we could also write some early test cases
and documentation.
4. WRITE BASIC TESTCASES AND DOCUMENTATION: June 5 - June 12
-------------------------------------------------------------
Once we got the design right, the documentation shouldn't be that
difficult to write, mainly because most of the changes should be
transparent to the user (the functionalities of Automake-generated
Makefile wouldn't change, only their implementation would).
And we could use parts of this proposal as a base for the new
documentation ;-)
Also, most (probably almost all, 95% or more) of the pre-existing
testsuite should be reusable to offer coverage of the new GNU make
specific Makefile snippets, so we won't need many new tests.
5. CODING, PART 1: June 12 - July 6 (Until mid-term evaluation)
----------------------------------------------------------------
Preparation: put in place the scaffolding to inject GNU make specific
fragments in the generated Makefiles. This fragments can be just
dummy at first.
Testsuite enhancements: put in place some scaffolding allowing to
easily run the testsuite with the GNU make specific output enabled
everywhere.
Simple optimization: get rid of VPATH hacks, as we can assume GNU
make VPATH semantics.
More substantial optimization: simplify the parallel-tests driver,
both in term of size of generated Makefiles and use of recursive make
invocation; more importantly, enhance it so that it will be able to
cope with very long $(TESTS) (no more "system command-line length
limit exceeded" kind of errors).
Add new testcases where deemed necessary.
5. CODING, PART 2: July 6 - July 23
------------------------------------
Dist-related targets optimization: allow very long $(DIST_FILES) (no
more "system command-line length limit exceeded" kind of errors); some
simplifications and speed optimizations would be nice.
Target-specific flags: experiment how to accomplish this using the GNU
make feature "target-specific variable values", and the fact that '$<'
is defined by GNU make also for "normal" (non-suffix) rules.
Other optimizations (depending on how much time is left):
- saner rules to build info files: put the generated files the build
directory, not in the source directory, as this does not cause any
problem with GNU make (it does with BSD make, sadly); adjust tests
accordingly;
- speed optimization for install rules (maybe allowing for higher
parellelizability?);
- look for other low-hanging fruits.
Add testcases where deemed necessary.
7. STRESS AND PORTABILITY TESTING: July 23 - Until done
--------------------------------------------------------
Test the code on other systems which Automake strives to support (e.g.,
Cygwin, MSYS/MinGW, AIX, HP-UX, IRIX), and (try to) fix all the problems
and incompatibilities that show up. This might require some more help
from the mentor, which has access to an impressive array of testing
systems (all the major proprietary Unix implementations are among them).
8. FINAL CLEANUP: All the time that's left (if any)
----------------------------------------------------
Use this period to polish documentation and code, pick some visible
low-hanging fruits (if any), and maybe add more tests about corner
cases (if such tests seem required).
