-
-
Notifications
You must be signed in to change notification settings - Fork 222
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
Try to make cmake work again #8201
base: master
Are you sure you want to change the base?
Conversation
set(FB_IPC_NAME "FIREBIRD") | ||
endif() | ||
|
||
if (MINGW) | ||
set(FB_BINDIR "${FB_PREFIX}/bin") |
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.
My problem with this is that it makes a windows build to use fixed instead of relocatable paths.
In the past mingw was a Windows build tool, but then seems it (together with msys) become a packaging environment too. I'm not sure just a build using mingw should follow its package conventions.
I never used cmake with Firebird, but I like it (or dislike less than the configure+make approach) and maybe we can have a cmake build with mingw compatible with the current Windows MSVC build.
Don't see this comment as an objection, as a short term solution it may be ok for me.
Does it also work using MSVC?
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.
My problem with this is that it makes a windows build to use fixed instead of relocatable paths.
FB_PREFIX
is only used on build-time. The real final installation location is defined by FB_INSTALL_PREFIX
(at least for mingw). MinGW does not support binreloc, so we add pathtools.cpp
and pathtools.h
to get relocatable paths.
In the past mingw was a Windows build tool, but then seems it (together with msys) become a packaging environment too. I'm not sure just a build using mingw should follow its package conventions.
MinGW generally follows FHS convention.. but, if you guys prefer for it to follow MSVC directory structure, im ok with that. MSys2 can always patch it downstream.
I never used cmake with Firebird, but I like it (or dislike less than the configure+make approach) and maybe we can have a cmake build with mingw compatible with the current Windows MSVC build.
Don't see this comment as an objection, as a short term solution it may be ok for me.
Great to hear that :)
Does it also work using MSVC?
I never tried this setup on msvc. sorry..
I see no need and no way to use MinGW as developer platform on Windows. MinGW could be used by anybody else for any other purposes, of course, but not me and not as main tool for developer. |
Fair enough for me :) |
Did you check cmake build on linux after mentioned changes? |
No, I didnt.. I only have access to windows. I am hoping someone else could help to improve it for other platform. |
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 myself never use cmake build and not ready to fix/check it on linux. I think in current state patch can't be accepted - IMO people sometimes do use it on posix systems while mingw is too exotic case.
bfc4fce
to
525dfa1
Compare
525dfa1
to
053961b
Compare
Built successfully on MinGW-w64 systems (mingw64, ucrt64, clang64):
https://github.com/msys2/MINGW-packages/actions/runs/10094396971?pr=21492