boost/build
2
0
Fork 0
mirror of https://github.com/boostorg/build.git synced 2026-02-18 01:52:17 +00:00
Code Issues Projects Releases Wiki Activity

Branch for aix shared linking support

Browse Source 
[SVN r13704]
This commit is contained in:
Dave Abrahams
2002-05-07 03:46:19 +00:00
parent ee94701488
commit 0fb21cdf9b
2 changed files with 0 additions and 326 deletions
Download Patch File Download Diff File Expand all files Collapse all files

163
TODO.txt
View File

@@ -1,163 +0,0 @@
(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.

163
v1/TODO.txt
View File

@@ -1,163 +0,0 @@
(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.