NAME
TODO
- List of things to be done before Buildtool 1.0 is ready
INTRODUCTION
Before Buildtool 1.0 can be released, there are lots of things to do.
This file tries to list some of them (not all), so you can get an idea
about where we want to go.
If you feel you can help developing some of these items (or providing
design ideas), please tell us.
Each module is detailed in its own section. Todo items are in no
special order.
COMMON
-
Fix bugs, of course. ;-)
-
Make scripts use the new
`global'
keyword in bt_sh, to the extent that
-w
shows no warnings.
-
Verify Cygwin support (mainly test if it works and add support for .exe
extensions).
-
Rewrite the testsuite; it's useless as it's now.
It should provide regression tests for almost all features provided by
Buildtool.
MODULE SPECIFIC
-
Improve shared library support.
Currently checks rely on system's name; this is okay for some details
but we need checks for compiler specific stuff.
-
More automated checks, for common programs, headers, and libraries.
Ideally, a non-trivial program (I have pkgsrc's bootstrap system in mind)
has to be converted to see which useful checks are missing, compared to
GNU autoconf.
-
Now that bt_sh has the isfunc command, we can implement real support
for multiple languages (avoiding the
`current language'
hack, probably).
-
An idea: add binary targets like DEB or RPM.
I will not add this myself as I have no knowledge of how these files
work.
If anybody is interested in adding this, contact me.
-
Add more checks, as Buildtool standards are developed.
-
Implement support for other kind of standards (like The GNU
Standards), using a variable in the defs file to indicate it.
-
Just an idea: create compiler wrappers during the configuration stage (like
pkgsrc's buildlink does).
This may make parsing of options faster as some conditions can be decided
during configuration time (i.e., just once), and also may make portability
easier (i.e., a different wrapper for each compiler).
-
Deprecate pkgflags file support (anyone using that? I doubt it).
It's starting to look stupid to try to force people use a new format,
because pkgconfig files are already doing a good job (when written
correctly).
Therefore, pkgconfig support needs to be reviewed and improved in this
module before this can happen.
-
Add more questions to tune the resulting output files.