CMake: Document wxBUILD_INSTALL_LIBRARY_DIR (PR #25780)
Chris Mayo
I think it's worth describing. I certainly didn't get it first time.
You can view, comment on, or merge this pull request online at:
https://github.com/wxWidgets/wxWidgets/pull/25780
Commit Summary
- 7cf858e CMake: Document wxBUILD_INSTALL_LIBRARY_DIR
File Changes
(1 file)
Patch Links:
- https://github.com/wxWidgets/wxWidgets/pull/25780.patch
- https://github.com/wxWidgets/wxWidgets/pull/25780.diff
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Maarten
MaartenBent left a comment (wxWidgets/wxWidgets#25780)All the advanced build options and their descriptions can be seen in cmake-gui. (or via the command line with cmake -LAH). So I don't know if we should document only this specific option here.
And if we keep it, I would word it differently so it is obvious that this is an optional option that overrides the default sub-directory name:
The optional option
wxBUILD_INSTALL_LIBRARY_DIRcan be used to override the default library directory name relative to
CMAKE_INSTALL_PREFIX. ...
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#25780)I'm also not sure if it's worth describing here. In fact, I rather struggle to see a use case for it at all — do people still use lib64 nowadays instead of just lib?
I also still wonder what could explain that all your PRs fail to build with this mysterious error on CircleCI. It's annoying to see them all as failing.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Chris Mayo
cjmayo left a comment (wxWidgets/wxWidgets#25780)I'm also not sure if it's worth describing here. In fact, I rather struggle to see a use case for it at all — do people still use
lib64nowadays instead of justlib?
Yes distributions do. Debian even uses lib/x86_64-linux-gnu:
https://packages.debian.org/trixie/amd64/libwxgtk3.2-1t64/filelist
I also still wonder what could explain that all your PRs fail to build with this mysterious error on CircleCI. It's annoying to see them all as failing.
No, that's a permissions thing as the branch is still in my repo.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Chris Mayo
cjmayo left a comment (wxWidgets/wxWidgets#25780)Maybe x86_64-linux-gnu is the wxPLATFORM_LIB_DIR? Haven't checked.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#25780)Yes distributions do. Debian even uses
lib/x86_64-linux-gnu:https://packages.debian.org/trixie/amd64/libwxgtk3.2-1t64/filelist
I don't think they change libdir for this, at least there is nothing to do it in configure command line used.
I also still wonder what could explain that all your PRs fail to build with this mysterious error on CircleCI. It's annoying to see them all as failing.
No, that's a permissions thing as the branch is still in my repo.
Have you done something special to prevent CircleCI from accessing it? After all, it's a branch in a public repository, so I don't see why wouldn't it be able to get it, especially as it can do it for all the other forks.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Scott Talbert
swt2c left a comment (wxWidgets/wxWidgets#25780)Yes distributions do. Debian even uses
lib/x86_64-linux-gnu:
https://packages.debian.org/trixie/amd64/libwxgtk3.2-1t64/filelistI don't think they change
libdirfor this, at least there is nothing to do it inconfigurecommand line used.
Just FYI - those are just the arguments supplied by the wxWidgets Debian packagers. The Debian build system is injecting additional arguments to configure, including --libdir=\${prefix}/lib/x86_64-linux-gnu. See a recent build log here if curious.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#25780)Ah, I stand corrected, thanks Scott.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#25780)All the advanced build options and their descriptions can be seen in cmake-gui. (or via the command line with
cmake -LAH). So I don't know if we should document only this specific option here.
And if we keep it, I would word it differently so it is obvious that this is an optional option that overrides the default sub-directory name:
The optional option
wxBUILD_INSTALL_LIBRARY_DIRcan be used to override the default library directory name relative to
CMAKE_INSTALL_PREFIX. ...
But I still don't know whether this should be applied or not in light of this Maarten's comment (that I agree with, FWIW).
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Chris Mayo
cjmayo left a comment (wxWidgets/wxWidgets#25780)Have you done something special to prevent CircleCI from accessing it? After all, it's a branch in a public repository, so I don't see why wouldn't it be able to get it, especially as it can do it for all the other forks.
No, as far as I remember I just cloned it. Looks like CircleCI require being granted some additional non-public access. Haven't studied it in detail.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Chris Mayo
@cjmayo pushed 1 commit.
- ca84c3c CMake: Document wxBUILD_INSTALL_LIBRARY_DIR
—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.
Chris Mayo
cjmayo left a comment (wxWidgets/wxWidgets#25780)This is something wxWidgets specific - a lot of software uses CMake's GNUInstallDirs, and so I expect packagers will already be setting CMAKE_INSTALL_LIBDIR and be surprised when that doesn't work. And there are a lot of options to look through, searching for LIBDIR won't help either.
I take onboard the wording comments. My suggestion there is to mention the "lib" default.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Chris Mayo
cjmayo left a comment (wxWidgets/wxWidgets#25780)Otherwise. I don't have anything more. It seems to work for me now (including find_package() in config mode). I haven't tried all of Maarten's changes from #25796 yet, but do certainly need the wxWidgetsTargets.cmake one from that.
I even found an application that does not need any changes to compile with 3.3 in xCHM.
xmlcopyeditor needs just the one change
https://sourceforge.net/p/xml-copy-editor/bugs/244/
And that non-literal msgid is one of the only two types of change needed I have seen. The other is the impact of the change to "+" operators. That seems to arise a fair bit for string concatenation. My simple solution has been to put the non-wxStrings in a wxString(). That might be worth documenting, especially if there is a better solution.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Maarten
MaartenBent left a comment (wxWidgets/wxWidgets#25780)I didn't know about CMAKE_INSTALL_LIBDIR and CMAKE_INSTALL_BINDIR. Maybe the better solution is to use these as default. So you don't need wxBUILD_INSTALL_*_DIR anymore.
For example, if I change it to this, it uses CMAKE_INSTALL_LIBDIR as default. And only if you want an actual custom directory, you need to specify wxBUILD_INSTALL_LIBRARY_DIR.
- wx_get_install_dir(library "lib") + wx_get_install_dir(library ${CMAKE_INSTALL_LIBDIR})
I'll add this to #25796 .
Would this documentation change still be needed if I add this?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.