build/TODO.txt

(C) Copyright David Abrahams 2001. Permission to copy, use,
modify, sell and distribute this software is granted provided this
copyright notice appears in all copies. This software is provided
"as is" without express or implied warranty, and with no claim as
to its suitability for any purpose.

Boost Build system TODO
===== ===== ====== ====

* Devise a way to transmit paths with spaces through variables NOT ending in
  PATH to Jam. Be sure that toolsets can be invoked through these variables.

* Complete work on using command-files for linking on windows. Neccessary features:
  1. Factor the response generation code out so it can be re-used
  2. Make the decision about whether to use command-files on a per-toolset,
     per-platform basis.

* Correct the support for find-library. I'm not sure what that entails.

* Consider auto-quoting bound paths containing spaces.

DONE * Fix split-path bug which unroots paths on Unix

DONE * move NEEDLIBS to end of link line

DONE * Fix bug with not found Python scripts

* $(REDIRECT) for toolset invocations:
              Unix: > filename 2>&1 -- puts stdout && stderr in same file

* add "|| exit $?" for unix to get it to exit for multi-line test commands.

* Make it possible to qualify dependencies just like requirements.

* Eliminate the need for <*>

* Support for warnings

* Add support for invoking debuggers from within the build system.

DONE * Fix the subinclude problem with project-wide variable settings (e.g.
BOOST_ROOT) that Beman pointed out to me.

* Move test target rules from status/Jamfile into boost-base.jam

SORTA DONE * Add requested test targets. I think we need at least the following
capability:
1. The ability to run any built executable
2. Two categories of test targets (call them "test" and "full-test") which
are not part of "all". These targets will build a ".test" file which depends
on some executable. The .test file will be regenerated when the executable
needs to be updated by running the executable with stdout redirected to the
.test file. full-test will be used for long-running tests.

* Add support for generalized user "CFLAGS", etc.

* Add examples directory back into CVS

DONE * Support for KCC

DONE * Specific support for GCC-3

* Low-priority: eliminate duplicate header scans.

* Eliminate the need for intermediate dispatching rules (e.g. C++-action) in
each toolset.

* Restructure internals to make better use of dispatching through variables.
I'm thinking of the chain of functions which get called to translate sources
into objects.

* Fix path normalization using regexp replacement. This should make
ALL_LOCATE_TARGET respond correctly to forward slashes.

* Handle #include "" and #include <> separately. Also, allow toolsets to
specify their own header search algorithms.

* Allow users to specify a rule name as part of the requirements or
default-build. Any ungristed element will be taken as the name of a rule to
be evaluated, and will be replaced with the result of calling it. This will
allow people to do a few things that the current system doesn't support
(e.g. Bill's case of needing to add a #define when the code is
dynamically-linkable).

Implement linking with prebuilt libraries. Should be trivial, except for
    choosing different libraries for different variants. This might require
    allowing sources to be qualified with toolset/variant grist. Also argues for
    a different syntax for library dependencies: <lib> is too
    confusable. Perhaps <#> or some other symbolic name.

Implement <sysinclude> feature for separately searching #include <...> paths?
    I think this may be a bad idea, since it isn't a portable feature. Maybe it
    would be best to try to get all compilers to work with the same #include
    search algorithm.

Clean up documentation
    DONE describe gristing
    revise free/path feature definition
    
Add a hook function to allow output directory customization that some people
want (instead of subdirectories, string together short names with '-').

Platform support:
    Unix paths on Mac/VMS
    DONE Integrate Win95/98/ME support


DONE (something better) Compile allyourbase/boost-base.jam into Jam itself.
    It might be best to review differences between allyourbase.jam and Jambase,
    and arrange the new Jambase to be a superset of the perforce Jambase so that
    a boost-compiled Jam can be used on standard Jambase projects without
    modification. OTOH, people can always use -f with the standard Jambase.

Open problem:
    How do we get Metrowerks STDHDRS properly initialized? The corresponding
    shell variables don't end in PATH nor do they follow the correct syntax for
    the -I option (e.g. they have preceding '+' signs).

Testing
    Linux
    Other Unices
    MacOS

Additional toolset descriptions
    DONE Kai (needs refurbishment)
    DONE, but needs rework Intel
    DONE(windows) Comeau
    ...

Better support for single-valued free features. GCC needs a default
    ftemplate-depth-NN setting which can be overridden.

=== for test system ===

Add platform library path to <runtime-link>dynamic executable targets' RUN_PATH,
    so they can be run even without the tools set up in the environment.

Add Jam rules for constructing build/test tools (built exes used for build/test). 
    Must only try to build one compiler/variant of these

Implement some test tools:
    success/failure inverter for expected failures (must prefix build actions to
    be able to use it)
    
    automatic PATH/LD_LIBRARY_PATH adjustment to account for DLL/runtime lib
    dependencies, so even exes with dynamically-linked library dependencies can
    be run through the test system. I think it is possible to do this entirely
    in Jam with some hackery.
    
    Facilities to update boost html compiler status page


=== FTJam core requests ===

DONE In debugging output, indirect rule invocations should reflect the rule name
being invoked.

DONE Fix modulus on nesting in debug output, so my emacs stepping tools don't get
confused.

DONE-ish Expand MAXLINE for NT, possibly as described by Chris Antos.

DONE Implement a way to invert the result of a rule, so that failure becomes success.