From 4121dea6a59367b4431cbe7a3c43d74fec9fd832 Mon Sep 17 00:00:00 2001 From: Paul Smith Date: Tue, 14 Sep 1999 00:17:58 +0000 Subject: * Some configuration fixes. --- TODO.private | 115 +++++++++++++++++++++++++++++++++++++++++++++++------------ 1 file changed, 92 insertions(+), 23 deletions(-) (limited to 'TODO.private') diff --git a/TODO.private b/TODO.private index 21f79e2..ea2c99e 100644 --- a/TODO.private +++ b/TODO.private @@ -14,38 +14,107 @@ However, if you see something here you really, really want, speak up. All other things being equal, I will tend to implement things that seem to maximize user satisfaction. -Also, this list doesn't include things which I'm pretty sure would -require serious, fundamental change to GNU make; those things belong on -the mythical "Make 4.0" list. I admit, that line can be somewhat fuzzy :) +If you want to implement some of them yourself, barring the ones I've +marked below, have at it! Please contact me first to let me know you're +working on it, and give me some info about the design--and, critically, +information about any user-visible syntax change, etc. - * Per-target variable definitions (a la SunOS make's ":=" feature, but - note the syntax here will definitely be different!) +The Top Item +------------ - * Multi-token pattern rule matching (allow %1/%2.c : %1/obj/%2.o, etc.) +If you know perl (or want to learn DejaGNU or similar), the number one +priority on my list of things I don't have time to do right now is +fixing up the GNU make test suite. Most importantly it needs to be made +"parallelizable", so more than one regression can run at the same time +(essentially, make the "work" directory local). Also, the CWD during +the test should be in the work directory; right now sometimes tests leak +files into the main directory which causes subsequent tests to fail +(some tests may need to be tweaked). Beyond that, any cleanup done to +make writing, reading, or handling tests simpler would be great! Please +feel free to make whatever changes you like to the current tests, given +some high-level goals, and that you'll port the current tests to +whatever you do :). - * More robust clock skew detection algorithm. +If someone does this work I'll be able to start including the test suite +with make itself, which would be very cool. - * Provide MAKETARGETS and MAKEVARIABLES variables, containing the - names of the targets and variables defined in the makefile. - * If the user asks for parallelization, rebuild any "include"'d files - in parallel as well (helps esp. when there are many .d files to be - built). +The Rest of the List +-------------------- + + 1) Allow variables/functions to expand to other make rules which are + then interpreted, with newlines handled correctly. This is a + biggee, and is on my plate. I already have partially-working code. + + 2) Option to check more than timestamps to determine if targets have + changed. This is also a very big one. It's _close_ to my plate :), + and I have very definite ideas about how I want it done. Please + pick something else unless you must have this feature. If you try + it, please work _extremely_ closely with me on it. + + 2a) Possibly a special case of this is the .KEEP_STATE feature of Sun's + make. Some great folks at W U. in Canada did an implementation of + this for a class project. Their approach is reasonable and + workable, but doesn't really fit into my ideas for #2. Maybe + that's OK. I have paperwork for their work so if you want to do + this one talk to me to get what they've already done. + + 3) Currently you can use "%.foo %.bar : %.baz" to mean that one + invocation of the rule builds both targets. GNU make needs a way to + do that for explicit rules, too. I heard a rumor that some versions + of make all you to say "a.foo + a.bar : a.baz" to do this (i.e., a + "+" means one invocation builds both). Don't know if this is the + best syntax or not... what if you say "a.foo + a.bar a.bam : a.baz"; + what does that mean? + + 4) Multi-token pattern rule matching (allow %1/%2.c : %1/obj/%2.o, + etc., or something like that). I have an implementation of this + already, it just needs some refinement... maybe. Additionally I + think it only works for static pattern rules; it might need to be + fixed up to work with normal pattern rules, too. - * Allow variables/functions to expand to other make rules which are - then interpreted, with newlines handled correctly. + 5) More robust clock skew detection algorithm: less false hits. I have + some notes on this from various discussions. - * More intelligent submake handling when doing parallel makes: - currently each submake gets a "-j 1" option. It would be good if - make was smart enough to give some/all its slots to the submake - (esp. if there is no other rule that can be run by the parent in - parallel, a common situation). Doing this perfectly might be too - hard, but something less than perfect is certainly possible. + 6) Provide MAKETARGETS and MAKEVARIABLES variables, containing the + names of the targets and variables defined in the makefile. - * Option to check more than timestamps to determine if targets have - changed (MD5 checksumming?) + Actually, I now think a $(targets ...) function, at least, would be + better than a MAKETARGETS variable. The argument would be types of + targets to list: "phony" is the most useful one. I suppose + "default" might also be useful. Maybe some others; check the + bitfields to see what might be handy. This one is pretty easy. - * Some sort of operating-system independent way of handling paths + 7) Some sort of operating-system independent way of handling paths would be outstanding, so makefiles can be written for UNIX, VMS, DOS, MS-Windows, Amiga, etc. with a minimum of specialization. + + Or, perhaps related/instead of, some sort of meta-quoting syntax so + make can deal with filenames containing spaces, colons, etc. I + dunno, maybe something like $[...]? This may well not be worth + doing until #1 is done. + + 9) Right now the .PRECIOUS, .INTERMEDIATE, and .SECONDARY + psuedo-targets have different capabilities. For example, .PRECIOUS + can take a "%", the others can't. Etc. These should all work the + same, insofar as that makes sense. + +10) A syntax that specifies a build order _without_ implying a + dependency relationship. That is, a way to say "A must be built + before B" that doesn't force B to be built when A changes. This is + very important for parallel builds: sometimes you need some stuff + done first but you don't want to rebuild everything because of it. + +11) Improved debugging/logging/etc. capabilities. This area is in + desparate need of work; the current -d, -s, etc. options are simply + insufficient. We need different levels of output: some that are + much less verbose. E.g., maybe just print one line about why make + decides to rebuild each target. Also, we could use something like + the -E option for preprocessors; this would print out makefiles + after resolving all includes, immediate variable reverences, etc. + Also, a way to turn on and off obeying the "@" token for scripts + that's independent of -n (so we could have them in effect for -n, + and have them not in effect without -n). + + Maybe other things. Contact me about the user interface. -- cgit v1.2.3