-
-
Notifications
You must be signed in to change notification settings - Fork 310
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
Teach ParseFlags to understand non-gcc compiler's options #4356
Labels
Comments
Might be simplest for compilers to add/alter the existing list when they're |
In theory, yes. But have to account for some args needing an opt-arg, and others not, so probably a bit of rework still needed in ParseArgs. |
mwichmann
changed the title
Teach ParseFlags to understand other compiler's options
Teach ParseFlags to understand non-gcc compiler's options
May 18, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
At the moment,
MergeFlags
callsParseFlags
, which only understands the syntax of gcc-style compilers. The documentation even says so in the first sentence:https://scons.org/doc/production/HTML/scons-man.html#f-ParseFlags
Old issue #2808 missed this, and reported misbehavior after calling
env.MergeFlags(['/TP'])
. SinceParseFlags
doesn't recognize that option, it put it inLIBS
instead, leading to a build fail (in a configure test, where the source of the problem is semi-hidden and not so easy to spot):It wouldn't be that hard to have tables of options and what should be done with them for other compilers, notably msvc, which of course has a completely different set. At this point, no proposal of what that would look like - would it somehow be toolchain-associated, so a particular option set only works if you're using that toolchain, or expanded so lots of different options are recognized in one big check, or what? This is just to get the concept recorded.
The text was updated successfully, but these errors were encountered: