Having to install all of Qt5 for CMake's GUI is a bit over the top, as it means 3GB of disk space is required to get CMake's GUI to function if installed from MSYS2. Could it not be linked to a static Qt version instead?
While I'm raising this point, would it not be sensible to have a set of target-independent packages for cmake and mingw32-make and maybe others so that users don't need to install these twice if developing for both architectures?
I understand this might mix with MSYS-based executables, although most shouldn't. I hope I'm making my point clear, my head is still sleeping...
As an example: the two mingw-w64--cmake packages can well be made into one single "cmake" package. Same for the mingw-w64--make packages, which I believe provide mingw32-make. Both are independent of the architecture they were compiled on.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There's two options, static qt sounds like s good pragmatic idea(please try this Ruben, I'm not near a computer for some hours).
Other than that, qt5 could be split into two packages, qt5 (small) and qt5-devel (massive), but we would need to all agree that is the right thing to do first. I'm willing to do the PKGBUILD work for this.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Some programs install 3rdparty cmake files that cmake use to find/configure programs. This is not possible to move such files from all packages to "universal" cmake.
Also I don't want to mix mingw/msys applications.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was sure, but now I see not, that the cmake.exe would not be linked with qt.
Is that the case for 3.2.3-2, which is installed for me now without qt, or did that one
get built separately?
Currently it is important to have cmake in /mingwXX because it will find /mingwXX/lib and /mingwxx/include. Otherwise, when installed externally it does fine - built with monolithic and compact qt libraries. I'm open to correction on this point.
CMake-3.3.0r4 is available now:
The "find_library()", "find_path()", and "find_file()" commands
now search in installation prefixes derived from the "PATH"
environment variable.
Which nullifies the convenience of hosting cmake in the mingw directories, does it not?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
First, current cmake is 3.2.3-5. Follow this https://github.com/Alexpux/MINGW-packages/issues/702 to update repositories and packages.
Second, right now we don't have cmake linked with static Qt as we install static Qt package in separate prefix to not conflict with shared one. So need somehow specify to use static Qt during cmake build.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sure that the new repos work? I get there are a lot of updates (mainly mingw), but also a lot of:
[...]mingw-w64-x86_64-py... 238,1 KiB 242K/s 00:01 [#####################] 100%errore: impossibile scaricare il pacchetto 'mingw-w64-x86_64-gtk2-2.24.28-1-any.pkg.tar.xz' da 45.59.69.178 : Operation too slow. Less than 1 bytes/sec transferred the last 10 secondserrore: impossibile scaricare il pacchetto 'mingw-w64-x86_64-gtk2-2.24.28-1-any.pkg.tar.xz' da downloads.sourceforge.net : name lookup timed outerrore: impossibile scaricare il pacchetto 'mingw-w64-x86_64-gtk2-2.24.28-1-any.pkg.tar.xz' da www2.futureware.at : name lookup timed out[...]
and
[...]errore: impossibile scaricare il pacchetto 'mingw-w64-x86_64-jbigkit-2.1-3-any.pkg.tar.xz' da 45.59.69.178 : Connection timed out after 10001 millisecondserrore: impossibile scaricare il pacchetto 'mingw-w64-x86_64-jbigkit-2.1-3-any.pkg.tar.xz' da downloads.sourceforge.net : name lookup timed outerrore: impossibile scaricare il pacchetto 'mingw-w64-x86_64-jbigkit-2.1-3-any.pkg.tar.xz' da www2.futureware.at : The requested URL returned error: 404[...]
Angelo
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"Which nullifies the convenience of hosting cmake in the mingw directories, does it not?"
That's missing the point of MSYS2 somewhat. I'll take "pacman -Syu" (and with it issues like a single very large Qt installation) over a mostly out-of-date, hard to maintain, insecure, largely redundant, cobbled-together-with-various-installers system every time.
Last edit: Ray Donnelly 2015-07-23
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The "find_library()", "find_path()", and "find_file()" commands now search in installation prefixes derived from the "PATH" environment variable.
On this point, I await the large amount bug reports regarding things like their "system" Python or random libraries getting picked up due to this change and I'm strongly considering disabling it since I think it's going to cause more trouble than it's worth (for us, on MSYS2).
Last edit: Ray Donnelly 2015-07-23
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Need to see if cmake allow choosing Qt location.
While I'm raising this point, would it not be sensible to have a set of target-independent packages for cmake and mingw32-make and maybe others so that users don't need to install these twice if developing for both architectures?
I understand this might mix with MSYS-based executables, although most shouldn't. I hope I'm making my point clear, my head is still sleeping...
As an example: the two mingw-w64--cmake packages can well be made into one single "cmake" package. Same for the mingw-w64--make packages, which I believe provide mingw32-make. Both are independent of the architecture they were compiled on.
There's two options, static qt sounds like s good pragmatic idea(please try this Ruben, I'm not near a computer for some hours).
Other than that, qt5 could be split into two packages, qt5 (small) and qt5-devel (massive), but we would need to all agree that is the right thing to do first. I'm willing to do the PKGBUILD work for this.
Some programs install 3rdparty cmake files that cmake use to find/configure programs. This is not possible to move such files from all packages to "universal" cmake.
Also I don't want to mix mingw/msys applications.
I was sure, but now I see not, that the cmake.exe would not be linked with qt.
Is that the case for 3.2.3-2, which is installed for me now without qt, or did that one
get built separately?
Currently it is important to have cmake in /mingwXX because it will find /mingwXX/lib and /mingwxx/include. Otherwise, when installed externally it does fine - built with monolithic and compact qt libraries. I'm open to correction on this point.
CMake-3.3.0r4 is available now:
now search in installation prefixes derived from the "PATH"
environment variable.
Which nullifies the convenience of hosting cmake in the mingw directories, does it not?
First, current cmake is 3.2.3-5. Follow this https://github.com/Alexpux/MINGW-packages/issues/702 to update repositories and packages.
Second, right now we don't have cmake linked with static Qt as we install static Qt package in separate prefix to not conflict with shared one. So need somehow specify to use static Qt during cmake build.
Sure that the new repos work? I get there are a lot of updates (mainly mingw), but also a lot of:
and
Angelo
Just rerun the update. Seems many users downloading packages. Server works ok for me
Also, SF seems to be back online.
No. SF works only for downloads, not for uploads. so it not have latest packages
That's missing the point of MSYS2 somewhat. I'll take "pacman -Syu" (and with it issues like a single very large Qt installation) over a mostly out-of-date, hard to maintain, insecure, largely redundant, cobbled-together-with-various-installers system every time.
Last edit: Ray Donnelly 2015-07-23
On this point, I await the large amount bug reports regarding things like their "system" Python or random libraries getting picked up due to this change and I'm strongly considering disabling it since I think it's going to cause more trouble than it's worth (for us, on MSYS2).
Last edit: Ray Donnelly 2015-07-23
Best solve this by splitting the Qt package, so there's a runtime package and a devel package. It's on my to-do list, but I can't promise a date.