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

Makefile.m32: drop CROSSPREFIX and manual CC/AR defaults [ci skip] #9698

Closed
wants to merge 1 commit into from

Conversation

vszakats
Copy link
Member

@vszakats vszakats commented Oct 11, 2022

This patch aimed to fix a regression [0], where CC initialization moved beyond its first use. But, on closer inspection it turned out that the CC initialization does not work as expected due to GNU Make filling it with cc by default. So unless implicit values were explicitly disabled via a GNU Make option, the default value of $CROSSPREFIX + gcc was never used. At the same time the implicit value cc maps to gcc in (most/all?) MinGW envs.

AR has the same issue, with a default value of ar.

We could reintroduce a separate variable to fix this without ill effects, but for simplicity and flexibility, it seems better to drop support for CROSSPREFIX, along with our own CC/AR init logic, and require the caller to initialize CC, AR and RC to the full (prefixed if necessary) names of these tools, as desired.

We keep RC ?= windres because RC is empty by default.

Also fix grammar in a comment.

[0] 10fbd8b

This patch aimed to fix a regression [0], where `CC` initialization
moved beyond its first use. But, on closer inspection it turned out that
the `CC` initialization does not work as expected due to GNU Make
filling it with `cc` by default. So unless implicit values were
explicitly disable via a GNU Make option, the default value of
`$CROSSPREFIX` + `gcc` was never reached. At the same time the implicit
value `cc` maps to `gcc` in (most/all?) MinGW envs.

`AR` has the same issue, which has a default value of `ar`.

We could reintroduce a separate variable name to fix this without ill
effects, but for simplicity and flexibility, it seems better to drop
support for `CROSSPREFIX`, along with our own `CC`/`AR` init logic, and
require the caller to initialize `CC`, `AR` and `RC` to the full
(prefixed if necessary) names of these tools, as desired.

We keep `RC ?= windres` because `RC` is empty by default.

Also fix grammar in a comment.

[0] 10fbd8b
@vszakats vszakats added build Windows Windows-specific labels Oct 11, 2022
@vszakats vszakats closed this in aa970c4 Oct 11, 2022
@vszakats vszakats deleted the m32autodet-regression branch Oct 11, 2022
obonaventure pushed a commit to mptcp-apps/curl that referenced this pull request Oct 12, 2022
This patch aimed to fix a regression [0], where `CC` initialization
moved beyond its first use. But, on closer inspection it turned out that
the `CC` initialization does not work as expected due to GNU Make
filling it with `cc` by default. So unless implicit values were
explicitly disabled via a GNU Make option, the default value of
`$CROSSPREFIX` + `gcc` was never used. At the same time the implicit
value `cc` maps to `gcc` in (most/all?) MinGW envs.

`AR` has the same issue, with a default value of `ar`.

We could reintroduce a separate variable to fix this without ill
effects, but for simplicity and flexibility, it seems better to drop
support for `CROSSPREFIX`, along with our own `CC`/`AR` init logic, and
require the caller to initialize `CC`, `AR` and `RC` to the full
(prefixed if necessary) names of these tools, as desired.

We keep `RC ?= windres` because `RC` is empty by default.

Also fix grammar in a comment.

[0] 10fbd8b

Closes curl#9698
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
build Windows Windows-specific
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant