-
Notifications
You must be signed in to change notification settings - Fork 593
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
meson: correctly set WIN32 in config.h #3660
Conversation
To match the autotools build.
An alternative would be to replace all checks for WIN32 in the code with _WIN32, but there are lots of places.. |
And they are in ctags code, so this would have to be fixed upstream. Not tested, but looks OK. |
I have created a pull request to fix it in upstream ctags repository. |
Is |
|
This underlying issue has been fixed in upstream ctags repository. |
Ok, will get included when the ctags is next updated from upstream. |
Yep, looks good.
And natively in MSYS2 on Windows:
|
Is there anything wrong with merging this? Even if it would be cooler to not have to set the flag, as it is done by Autotools as well, it might be ok. And if uctags is updated next time, we could try to remove it again. |
Yes, gcc and clang both defines those macros which are not official or documented by Microsoft. Those are probably for compatibility with ancient code. Android has similar issue about Meanwhile in Linux side 🤦
|
@@ -185,6 +185,10 @@ if python_command == '' or python_command == 'auto' | |||
endif | |||
cdata.set('PYTHON_COMMAND', python_command) | |||
|
|||
if host_machine.system() == 'windows' |
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 fine, but we probably should stop using target_machine
everywhere else…
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.
LGTM as far as 0-testing goes
I don't see any reason not to merge this indeed, if it fixes something. |
Since the changes in upstream ctags have been pulled into Geany already, the last use was in So, what do you think about #3878 to remove the |
@eht16 no, it's ctags, or rather glibc 2.10. Apparently though upstream ctags switched to gnulib's in universal-ctags/ctags#3054, so we might want to follow that… which might or might not solve this. |
To match the autotools build.