On master, components in a package are identified by their name together with their type.
Rephrased, within a package, components may share their name as long as their type differs.
This design is directly copied from Cargo and from Cabal:
In a Cargo manifest, crates appear in different “tables”, e.g. [lib], [[bin]], [[example]], [[test]] and names are local to a table. In a Cabal manifest, package components appear in different “stanzas” / “sections” and names are local to a section.
Further, all Lushui package components are either “primary” or “secondary”. There may only exist one primary component per type. Components are “primary” if they share their name with the package name (if no explicit name is given to a component, it defaults to the package name). The original reason behind this classification is that primary components have in some sense certain “perks” / a higher “priority”: The primary executable is supposed to be executed when a package is run and the flag --exe <name> was not supplied. However, that was never correctly implemented.
As for primary libraries, well, they are public by default (however, component exposure is not yet implemented).
The issue with this whole design is that it doesn't make any practical sense and it is slightly over-engineered / overly general:
It doesn't make any sense for benchmark and test suites, examples and tests to default to the package name. Really, you always want to name those with a sensible and descriptive name. I mean even for executables that is the case (although Cargo would disagree here). It seems rather hackish to me to default to a “dummy” component name.
Next, I think it is quite unlikely that anyone ever wants to name components of differing type the same. Example “sets” are totally different in nature from benchmark suites (not from an implementation POV but from a user's one) and users will therefore probably name them quite distinctively.
Next, the concept of “primary” versus “secondary” doesn't make any sense for examples, benchmark suites etc (non-library, non-executable). In most cases, all those components are of equal importance.
Re. primary executables, we should just go the Cargo route of requiring disambiguation with (-c/--component <name>) if there is more than one executable in a package. However in addition to that I'd be in favor if we supported a field called default of type bool which is only available for exes. Alternatively, a new component ”type” called default-executable. Basically the new “primary” for exes haha.
Now, “primary” libraries are the most useless. That's why they should go out the window. Well, in some sense, one could consider components named the same as the owning package “primary”. Anyways.
On master, components in a package are identified by their name together with their type. Rephrased, within a package, components may share their name as long as their type differs. This design is directly copied from Cargo and from Cabal: In a Cargo manifest, crates appear in different “tables”, e.g.
[lib],[[bin]],[[example]],[[test]]and names are local to a table. In a Cabal manifest, package components appear in different “stanzas” / “sections” and names are local to a section.Further, all Lushui package components are either “primary” or “secondary”. There may only exist one primary component per type. Components are “primary” if they share their name with the package name (if no explicit name is given to a component, it defaults to the package name). The original reason behind this classification is that primary components have in some sense certain “perks” / a higher “priority”: The primary executable is supposed to be executed when a package is
runand the flag--exe <name>was not supplied. However, that was never correctly implemented. As for primary libraries, well, they are public by default (however, component exposure is not yet implemented).The issue with this whole design is that it doesn't make any practical sense and it is slightly over-engineered / overly general: It doesn't make any sense for benchmark and test suites, examples and tests to default to the package name. Really, you always want to name those with a sensible and descriptive name. I mean even for executables that is the case (although Cargo would disagree here). It seems rather hackish to me to default to a “dummy” component name. Next, I think it is quite unlikely that anyone ever wants to name components of differing type the same. Example “sets” are totally different in nature from benchmark suites (not from an implementation POV but from a user's one) and users will therefore probably name them quite distinctively.
Next, the concept of “primary” versus “secondary” doesn't make any sense for examples, benchmark suites etc (non-library, non-executable). In most cases, all those components are of equal importance. Re. primary executables, we should just go the Cargo route of requiring disambiguation with (
-c/--component <name>) if there is more than one executable in a package. However in addition to that I'd be in favor if we supported a field calleddefaultof type bool which is only available for exes. Alternatively, a new component ”type” calleddefault-executable. Basically the new “primary” for exes haha. Now, “primary” libraries are the most useless. That's why they should go out the window. Well, in some sense, one could consider components named the same as the owning package “primary”. Anyways.