dist-3.0at70b/Wishlist

   1 *** List of wishes for dist version 3.0 ***
   2
   3 =======================================================================
   4 If you wish to implement one of the following, you're welcome :-). In
   5 that case, please let me know about it.  I will probably integrate your
   6 changes in my version (after some sanity checks, because I can't
   7 maintain something I don't understand).
   8
   9 This list has no priority order whatsoever, so you may pick up one of
  10 the following suggestion and start working on it. In that case, you
  11 may want to get all the official patches for dist 3.0 first and make
  12 sure nobody is already working on that topic.
  13 =======================================================================
  14
  15 *** jmake
  16
  17 Make the names used more uniform. For instance, 'Simple' appears in
  18 many rules, but with different meanings, thus making the Jmakefile
  19 harder to understand at a first glance.
  20
  21 Allow per-system compilation rules, so that objects and source file
  22 do not inter-mix but are kept in separate directories.
  23
  24 *** metaconfig
  25
  26 Write some "generic" templates for writing new units, so that the user
  27 only needs to fill up some fields. For instance, there could be a
  28 template for d_* and i_* units. [That's done, they are under mcon/files.
  29 Now I only need to write the generator on top of them]
  30
  31 Make Configure know about cross-compiling.
  32
  33 Make Configure know about VPATH for separate object directory, with
  34 proper support from jmake.
  35
  36 Implement the ?I: and ?L: lines. The ?I: fills in inclwanted for you,
  37 while ?L: fills in the libswanted variable. For instance, when using
  38 a socket() call, one may need to look at -lbsd. If d_socket.U lists
  39 'bsd' within its ?L: line, then the libswanted variable will be
  40 correctly set. [Note: there are some hooks for this already]
  41
  42 Build a library of PD routines that may be otherwise missing on
  43 some older systems, eg: getopt(). Those routines will be automagically
  44 added to the package by relying on ?P: lines, something like:
  45
  46         ?P:getopt (HAS_GETOPT): getopt.c
  47
  48 which would include getopt.c in the package (under some PD dir)
  49 when getopt is used and HAS_GETOPT is *not* used within the sources,
  50 in order to achieve transparent implementation.
  51
  52 *** metalint
  53
  54 Process '@' pre-processor lines, and signal mismatches, unrecognized
  55 commands, etc... Also warn when testing wantedness of unknown symbols
  56 or obsolete ones, etc...
  57
  58 *** pat tools
  59
  60 Clean that stuff.