Open fmease opened 3 years ago
This issue concerns itself with medium/large-sized improvement to the current package system. We plan a systematic overhaul (#123) which however does not render this issue (#100) obsolete. They are mostly independent as far as I can tell at first glance.
public: <true|false>
)packages/transitive-dependencies-are-inaccessible
Diagnostic::undefined_library_component
a: { b: { path: "." } }
should lead to a good error messagepackage
entry in dependency declarationspackages/circular-components-three-packages
packages/circular-components-in-same-package
(re. “outsiders” and “unrelated components”)git
(git dependencies)lushui <new|init>
unless--vsc=none
(create the latter flag as well)registry
(HTTP(s) registry dependencies)--extern=NAME:PATH
--distributed-libraries=PATH
(or hidden behind a new option group-Y=distributed-libraries:PATH
(…)) (should this be called the sysroot or a variation thereof?)More intelligent behavior for(postponed indefinitely; current behavior emits data for target components)-Z emit-<data>
and-Z <pass>-only
: Options for dumping info of every crate or only the goal crate; options for phase restrictions in presence of multiple crateslushui <check|build|run> <path/to/package-folder>
should check/build/run a package at the given path; checking/building/running a file should continue to work (via 8db91a93dd05e043cbd4c554407a45f0b5ce74df)Supportlushui <check|build|run> <path/to/name.metadata>
for somename
but for the fixed extensionmetadata
should check/build/run the package corresp. to the given manifest orlushui <check|build|run> --manifest <path/to/manifest>
(the latter is more robust)