TODO.private

   1                                                             -*-Indented-Text-*-
   2 GNU Make TODO List
   3 ------------------
   4
   5 This list comes both from the authors and from users of GNU make.
   6
   7 They are listed in no particular order!
   8
   9 Also, I don't gaurantee that all of them will be ultimately deemed "good
  10 ideas" and implemented.  These are just the ones that, at first blush,
  11 seem to have some merit (and that I can remember).
  12
  13 However, if you see something here you really, really want, speak up.
  14 All other things being equal, I will tend to implement things that seem
  15 to maximize user satisfaction.
  16
  17 If you want to implement some of them yourself, barring the ones I've
  18 marked below, have at it!  Please contact me first to let me know you're
  19 working on it, and give me some info about the design--and, critically,
  20 information about any user-visible syntax change, etc.
  21
  22
  23 The Top Item
  24 ------------
  25
  26 If you know perl (or want to learn DejaGNU or similar), the number one
  27 priority on my list of things I don't have time to do right now is
  28 fixing up the GNU make test suite.  Most importantly it needs to be made
  29 "parallelizable", so more than one regression can run at the same time
  30 (essentially, make the "work" directory local).  Also, the CWD during
  31 the test should be in the work directory or, better, a test-specific
  32 temporary directory so each test gets a new directory; right now
  33 sometimes tests leak files into the main directory which causes
  34 subsequent tests to fail (some tests may need to be tweaked).  Beyond
  35 that, any cleanup done to make writing, reading, or handling tests
  36 simpler would be great!  Please feel free to make whatever changes you
  37 like to the current tests, given some high-level goals, and that you'll
  38 port the current tests to whatever you do :).
  39
  40
  41 The Rest of the List
  42 --------------------
  43
  44  1) Allow variables/functions to expand to other make rules which are
  45     then interpreted, with newlines handled correctly.  This is a
  46     biggee, and is on my plate.  I already have partially-working code.
  47
  48  2) Option to check more than timestamps to determine if targets have
  49     changed.  This is also a very big one.  It's _close_ to my plate :),
  50     and I have very definite ideas about how I would like it done.
  51     Please pick something else unless you must have this feature.  If
  52     you try it, please work _extremely_ closely with me on it.
  53
  54  2a) Possibly a special case of this is the .KEEP_STATE feature of Sun's
  55      make.  Some great folks at W U. in Canada did an implementation of
  56      this for a class project.  Their approach is reasonable and
  57      workable, but doesn't really fit into my ideas for #2.  Maybe
  58      that's OK.  I have paperwork for their work so if you want to do
  59      this one talk to me to get what they've already done.
  60
  61      [K R Praveen <praveen@cair.res.in>]
  62
  63  3) Currently you can use "%.foo %.bar : %.baz" to mean that one
  64     invocation of the rule builds both targets.  GNU make needs a way to
  65     do that for explicit rules, too.  I heard a rumor that some versions
  66     of make all you to say "a.foo + a.bar : a.baz" to do this (i.e., a
  67     "+" means one invocation builds both).  Don't know if this is the
  68     best syntax or not... what if you say "a.foo + a.bar a.bam : a.baz";
  69     what does that mean?
  70
  71  4) Multi-token pattern rule matching (allow %1/%2.c : %1/obj/%2.o,
  72     etc., or something like that).  I have an implementation of this
  73     already, it just needs some refinement... maybe.  Additionally I
  74     think it only works for static pattern rules; it might need to be
  75     fixed up to work with normal pattern rules, too.
  76
  77  5) More robust clock skew detection algorithm: less false hits.  I have
  78     some notes on this from various discussions.
  79
  80  6) Provide MAKETARGETS and MAKEVARIABLES variables, containing the
  81     names of the targets and variables defined in the makefile.
  82
  83     Actually, I now think a $(targets ...) function, at least, would be
  84     better than a MAKETARGETS variable.  The argument would be types of
  85     targets to list: "phony" is the most useful one.  I suppose
  86     "default" might also be useful.  Maybe some others; check the
  87     bitfields to see what might be handy.  This one is pretty easy.
  88
  89  7) Some sort of operating-system independent way of handling paths
  90     would be outstanding, so makefiles can be written for UNIX, VMS,
  91     DOS, MS-Windows, Amiga, etc. with a minimum of specialization.
  92
  93     Or, perhaps related/instead of, some sort of meta-quoting syntax so
  94     make can deal with filenames containing spaces, colons, etc.  I
  95     dunno, maybe something like $[...]?  This may well not be worth
  96     doing until #1 is done.
  97
  98  9) Right now the .PRECIOUS, .INTERMEDIATE, and .SECONDARY
  99     pseudo-targets have different capabilities.  For example, .PRECIOUS
 100     can take a "%", the others can't.  Etc.  These should all work the
 101     same, insofar as that makes sense.
 102
 103 10) A syntax that specifies a build order _without_ implying a
 104     dependency relationship.  That is, a way to say "A must be built
 105     before B" that doesn't force B to be built when A changes.  This is
 106     very important for parallel builds: sometimes you need some stuff
 107     done first but you don't want to rebuild everything because of it.
 108
 109 11) Improved debugging/logging/etc. capabilities.  Part of this is done:
 110     I introduced a number of debugging enhancements.  Tim Magill is (I
 111     think) looking into options to control output more selectively.
 112     One thing I want to do in debugging is add a flag to allow debugging
 113     of variables as they're expanded (!).  This would be incredibly
 114     verbose, but could be invaluable when nothing else seems to work and
 115     you just can't figure it out.  The way variables are expanded now
 116     means this isn't 100% trivial, but it probably won't be hard.
 117
 118 12) Integration of Guile as an embedded scripting language.  This means:
 119     allowing Guile functions to be declared in makefiles somehow, then
 120     providing a syntax for invoking them.  At least one formulation of
 121     that would have the function resolve to a string which would be
 122     substituted in the makefile, kind of like $(shell ...) does now, but
 123     using the embedded interpreter so there's no process forked of
 124     course.  Obviously this is an optional add-on feature.
 125
 126     It could be more advanced than that, even, who knows?  Maybe make
 127     could provide Guile functions that allow Guile scripts more direct
 128     access to internal make structures, somehow.  This kind of thing
 129     needs a lot of thought.
 130
 131     Also there's always the flip side: in some very fundamental ways
 132     make isn't the best choice right now for a complex build tool.  It's
 133     great for simple-to-medium tasks, but there are already other tools
 134     available for the really tough situations.  Ask yourself,
 135     realistically, how much work is worthwhile to add to make, given the
 136     fundamentals you can't really overcome without significantly
 137     affecting backward compatibility--and then why not use another tool
 138     in the first place?
 139
 140     Something to think about.