Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build Subset Dependencies #63729

Open
MarcasRealAccount opened this issue Jan 13, 2022 · 3 comments
Open

Build Subset Dependencies #63729

MarcasRealAccount opened this issue Jan 13, 2022 · 3 comments

Comments

@MarcasRealAccount
Copy link

When using build.cmd or build.sh to build certain subsets, you might end up with a few errors stating that you're missing executables.
That's because build.cmd and build.sh expects all subset dependencies are already built, which to my belief is very bad.

For instance building Libs requires that you first build some things from both Clr and Host.

I think build.cmd and build.sh should not only build the target subset but also that subset's dependencies, such that instead of doing
build.cmd Clr+Host+Libs because you only wanted the Libs, you'd instead just do build.cmd Libs and it would build the dependencies from Clr and Host.

@dotnet-issue-labeler dotnet-issue-labeler bot added area-Infrastructure-libraries untriaged New issue has not been triaged by the area owner labels Jan 13, 2022
@ghost
Copy link

ghost commented Jan 13, 2022

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

Issue Details

When using build.cmd or build.sh to build certain subsets, you might end up with a few errors stating that you're missing executables.
That's because build.cmd and build.sh expects all subset dependencies are already built, which to my belief is very bad.

For instance building Libs requires that you first build some things from both Clr and Host.

I think build.cmd and build.sh should not only build the target subset but also that subset's dependencies, such that instead of doing
build.cmd Clr+Host+Libs because you only wanted the Libs, you'd instead just do build.cmd Libs and it would build the dependencies from Clr and Host.

Author: MarcasRealAccount
Assignees: -
Labels:

area-Infrastructure-libraries, untriaged

Milestone: -

@ghost ghost added this to Untriaged in Infrastructure Backlog Jan 13, 2022
@safern
Copy link
Member

safern commented Jan 13, 2022

Thanks, @MarcasRealAccount for your input, we appreciate it.

In my opinion, I think that would slow down innerloop and complicate things. There are various scenarios where you don't want to build dependencies for a subset, say CI scenarios, or even a scenario where I already have Clr built locally and I'm just iterating over Libs, I don't want to spend time building Clr and just build Libs.

We could perhaps enable this if we fixed our incremental story and make it super fast to incrementally build all subsets, which we are investing on, but I don't know how much time people would waste building things they no longer need to build.

@dotnet/runtime-infrastructure for more thoughts/ideas.

@ghost
Copy link

ghost commented Jan 14, 2022

Tagging subscribers to this area: @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.

Issue Details

When using build.cmd or build.sh to build certain subsets, you might end up with a few errors stating that you're missing executables.
That's because build.cmd and build.sh expects all subset dependencies are already built, which to my belief is very bad.

For instance building Libs requires that you first build some things from both Clr and Host.

I think build.cmd and build.sh should not only build the target subset but also that subset's dependencies, such that instead of doing
build.cmd Clr+Host+Libs because you only wanted the Libs, you'd instead just do build.cmd Libs and it would build the dependencies from Clr and Host.

Author: MarcasRealAccount
Assignees: -
Labels:

area-Infrastructure, untriaged

Milestone: -

@ViktorHofer ViktorHofer added this to the Future milestone Jul 11, 2022
@ViktorHofer ViktorHofer removed the untriaged New issue has not been triaged by the area owner label Jul 11, 2022
@ViktorHofer ViktorHofer moved this from Untriaged to Future in Infrastructure Backlog Jul 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: No status
Development

No branches or pull requests

3 participants