Bug 17069 – rdmd code should be split in reusable libraries

Status
RESOLVED
Resolution
WONTFIX
Severity
critical
Priority
P1
Component
tools
Product
D
Version
D2
Platform
x86
OS
All
Creation time
2017-01-07T23:21:44Z
Last change time
2021-01-09T11:00:45Z
Assigned to
No Owner
Creator
Timothee Cour

Comments

Comment #0 by timothee.cour2 — 2017-01-07T23:21:44Z
rdmd is insufficient to build D applications: (A) mainly because of this 6 year old bug https://issues.dlang.org/show_bug.cgi?id=7016 local import does not create -deps dependency (B) no support for partial recompilation (blocked by lack of -oq, which ldc has but not dmd: https://github.com/dlang/dmd/pull/1871 has been pending for 4 years; see also https://issues.dlang.org/show_bug.cgi?id=3541: Add -oq to dmd (use fully qualified module name as object filename) ; https://issues.dlang.org/show_bug.cgi?id=12116: dmd -op -od broken) I built a build system for my use cases that addresses (A) and (B) (suboptimally though) based on forking off rdmd but it's very hard to keep in sync with rdmd because of rdmd's monolithic design: * it contains a main function (so can't be used as a library) * it's one big file, the private functions can't be reused elsewhere * in some sense it does too much (--eval=code, --loop should belong in a separate module) Recommendations: * split rdmd into several reusable modules (eg: dtools.rdmd.dependency, etc) * make the main subject to a switch
Comment #1 by pro.mathias.lang — 2020-06-05T12:14:21Z
Wouldn't it be a better case for DMD as a library ?
Comment #2 by pro.mathias.lang — 2021-01-09T11:00:45Z
Going to close this as there is [a pull request for it](https://github.com/dlang/tools/pull/344) that has attracted a lot of controversy, especially by Andrei. There are a few good point which highlight actual missing features / borderline bugs, which would be more suited to their own issues. If you are inclined to pursue this, please open issues at https://github.com/dlang/tools/.