-
Notifications
You must be signed in to change notification settings - Fork 34
Toolchain independence #717
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
base: main
Are you sure you want to change the base?
Changes from 9 commits
5078b0b
7f958e5
0f02696
16062b3
c42de5f
1984d81
15d7615
1a30591
2bb2ae4
385953f
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Large diffs are not rendered by default.
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -24,12 +24,21 @@ endif | |
| ifeq ($(wildcard ${SDDF}/tools/make/board/${MICROKIT_BOARD}.mk),) | ||
| $(error No Make snippet in ${SDDF}/tools/make/board for ${MICROKIT_BOARD}) | ||
| endif | ||
| TOOLCHAIN ?= clang | ||
|
|
||
| include ${SDDF}/tools/make/board/${MICROKIT_BOARD}.mk | ||
| include ${SDDF}/tools/make/toolchain/${TOOLCHAIN}.mk | ||
|
|
||
| MICROKIT_TOOL ?= $(MICROKIT_SDK)/bin/microkit | ||
|
|
||
| # For submakes | ||
| export SUPPORTED_BOARDS | ||
| export MICROKIT_BOARD | ||
| export MICROKIT_CONFIG | ||
| export BOARD_DIR | ||
| export MICROKIT_SDK | ||
| export TOOLCHAIN | ||
|
|
||
| ifneq ($(ARCH),x86_64) | ||
| DTS := $(SDDF)/dts/$(MICROKIT_BOARD).dts | ||
| DTB := $(MICROKIT_BOARD).dtb | ||
|
|
@@ -56,11 +65,20 @@ eth_driver.elf: ${ETH_DRIV} | |
|
|
||
| # Magic to ensure stuff gets recompiled if we change | ||
| # board name, or use a different Microkit etc. | ||
| CHECK_FLAGS_BOARD_HASH := .board_cflags-$(shell echo -- ${CFLAGS} ${MICROKIT_SDK} ${MICROKIT_BOARD} ${MICROKIT_CONFIG} ${SMP_CONFIG} ${BENCH_PMU_EVENTS} | shasum | sed 's/ *-//g') | ||
|
|
||
| COMMON_CONFIG += ${TOOLCHAIN} \ | ||
| ${CFLAGS} \ | ||
| ${MICROKIT_SDK} \ | ||
| ${MICROKIT_BOARD} \ | ||
| ${MICROKIT_CONFIG} \ | ||
| ${SMP_CONFIG} \ | ||
| ${BENCH_PMU_EVENTS} | ||
|
|
||
| CHECK_FLAGS_BOARD_HASH := .board_cflags-$(shell echo -- ${COMMON_CONFIG} | \ | ||
| shasum | sed 's/ *-//g') | ||
|
|
||
| ${CHECK_FLAGS_BOARD_HASH}: | ||
| -rm -f .board_cflags-* | ||
| touch $@ | ||
|
|
||
| REBUILD_CANDIDATE_OBJECTS := $(shell find . -name '*.o') | ||
| ${REBUILD_CANDIDATE_OBJECTS): .EXTRA_PREREQS = ${CHECK_FLAGS_BOARD_HASH} | ||
| .EXTRA_PREREQS = ${CHECK_FLAGS_BOARD_HASH} | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. FYI Peter: #715. (I suspect this might be the BSD make instead of GNU make thing again? IDK)
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Could be; I will check this.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We use so many GNUmake idioms I'd be surprised if BSD make builds the system at all.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is it possible to make make error if it's not GNUmake? That would solve this as well, I think. (I do recall us decided that we basically need GNUmake: our CI needs it explicitly)
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Correction: macOS default is GNUmake 3.8, from 2006...
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So I don't know what the difference is but @0aids was reporting that I don't know what the difference is between them.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do you mean with 'EXTRA_PREREQS' or with Courtney's patch? Either way, we're adding a prerequisite to ensure that stuff is rebuilt; and
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, Courtney's patch. But it also included all the .h files listed in the compiler emitted .d files. What confuses me is I don't see what the difference is because the list of dependencies in the compiler-depfile would contain the headers always but why does it only sometimes appear in
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. On the first run, the .d files haven't been created, so Make doesn't know about the header files. On subsequent runs it does. A prerequisite in Make terms is any file, that if newer than a target, means the target has to be rebuilt: any header file a C file includes, if changed, means that the .o target needs rebuilding. So the complete prerequisite list for a .o file will always include the C file it is built from, and the transitive closure of header files that that C file includes directly or recursively. There is almost never a reason to use
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Well, a lot of our Makefile rules do... In some ways I think we need to redo all our Makefiles to be of better quality. At the moment they have a hodegpoge of styles and techniques, but at the same time I don't know of any golden references. |
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can understand wanting to remove these disabled warnings but it has nothing to do with GCC vs Clang... These should be separate commits not squished in with the rest silently.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is GCC-versus clang ... the arguments are not available for gcc, and the warnings they suppress need to be fixed in-line in the code instead.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
GCC doesn't support -Wno-unused-function? but it says it does: https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wunused-function (and I'm pretty sure these pre-date clang-as-default).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
-Wunused-command-line-argument is the one it doesn't seem to accept... and if we can get rid of them, let's go ...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we can get rid of
-Wunused-command-line-argumentunfortunately, there's some issues with the Nix-packaged sysroots, and a few other cases.