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).