Skip to content

Build artifacts/ARCHV/TARGET instead of artifacts/ARCHV/T.#45

Merged
bryanb-h2 merged 1 commit into
masterfrom
bryanb_build_targets
Jun 4, 2026
Merged

Build artifacts/ARCHV/TARGET instead of artifacts/ARCHV/T.#45
bryanb-h2 merged 1 commit into
masterfrom
bryanb_build_targets

Conversation

@bryanb-h2

Copy link
Copy Markdown
Contributor

No description provided.

Signed-off-by: Bryan Bayerdorffer <bryanb@qti.qualcomm.com>
@bryanb-h2

Copy link
Copy Markdown
Contributor Author

We can close #43 if we merge this.

@eplondke eplondke left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me.

@eplondke

eplondke commented Jun 4, 2026

Copy link
Copy Markdown

Is there even T any more? Can we get rid of it if it's confusing?

@bryanb-h2

Copy link
Copy Markdown
Contributor Author

Is there even T any more? Can we get rid of it if it's confusing?

Yeah, there's T. we might be able to get rid of it, but right now it selects which of the opt: or ref: targets from the top-level makefiles get built (with the particular parameters of the given target). Removing T means either sucking those huge stanzas into the TARGET, er, targets (admittedly most of that stuff could go into a separate target that depends on the TARGET) and refactoring so that we don't have {opt|ref}_install in the kernel makefile and so on. We'd have to pass those makefiles a flag that says which of opt or ref to build...kind of like $(T)...

@bryanb-h2

bryanb-h2 commented Jun 4, 2026

Copy link
Copy Markdown
Contributor Author

Is there even T any more? Can we get rid of it if it's confusing?

Yeah, there's T. we might be able to get rid of it, but right now it selects which of the opt: or ref: targets from the top-level makefiles get built (with the particular parameters of the given target). Removing T means either sucking those huge stanzas into the TARGET, er, targets (admittedly most of that stuff could go into a separate target that depends on the TARGET) and refactoring so that we don't have {opt|ref}_install in the kernel makefile and so on. We'd have to pass those makefiles a flag that says which of opt or ref to build...kind of like $(T)...

Now that I think about it, it's really the top-level opt: and ref: targets that get in the way of sanity here. We should just pass $(T) to all the submakes -- it's actually already exported.

I think we want 'make opt' and 'makeTARGET=opt' to do the same thing, and right now they don't necessarily have to.
If we remote the top-level opt and ref targets then 'make opt' etc won't work any more, but I think that's a good thing. Or we can leave them and just have them do $(MAKE) TARGET={opt|ref}

I'll try it out and make a new PR.

@bryanb-h2 bryanb-h2 merged commit 576dfa9 into master Jun 4, 2026
11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants