-
Notifications
You must be signed in to change notification settings - Fork 684
Build system changes to allow compiler toolchain override #454
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
Closed
akosthekiss
wants to merge
1
commit into
jerryscript-project:master
from
akosthekiss:compiler-override
Closed
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
@akiss77, maybe, we should introduce some set of
toolchain_*.cmake
files for different compilers. The files would set compiler executable names and also apply compiler-specific values of build options (for exampleFLAGS_LTO=-flto
for gcc / g++) / warnings configuration etc.Also, maybe we should extract the architecture-specific part to sub-configuration files for each supported compiler-architecture pair and put compiler-architecture specific flags / options to the files.
In the case, we could remove gcc / g++ specific
if
blocks from CMakeLists.txt, and also would support clang build for arhitectures other than x86_64.What do you think about this?
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.
@ruben-ayrapetyan, having "worked-for-us" defaults in the build system is a good thing (actually, that's what we already have in the cmake listfile) but not letting developers deviate from the defaults (i.e., "set compiler executable names") is not, IMHO. There will always be platforms and/or tool chains what we don't have access to (or setups which slightly differ from our development environment, see #489 ). I'd definitely vote for a solution where developers have the maximum freedom to choose tools and settings for the build if they want to adapt to their environment or simply experiment.
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.
@akiss77, I agree to you that we should provide maximum freedom to choose build tools and settings.
I think, we should make the choice as simple, as possible.
To make choice simple, we should provide a simple way of switching to another tool (from predefined set or some new / unknown).
In current version of CMakeLists.txt there are some dependencies on gcc / g++.
I think that the dependencies should be moved to configuration files, external to CMakeLists.txt and also add another necessary configurations (currently, for clang).
In the way, we could save logic and structure of CMakeLists.txt.
In the case, any developer would have simple way to add support of another compiler, without changing logic of CMakeLists.txt.
If there would be some features that would not be provided up to the moment, the CMakeLists.txt could be generalized for the cases.
What do you think about this?
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.
Would the above-described approach allow overriding the defaults from command line as usually expected to work with make, e.g.,
make CC=xxx CFLAGS=xxx
or only by defining configuration files?