Re: [CMake] cmake on MinGW64; which generator

The problem is the time required to upstream such work. Unfortunately I do not have that time. On Tue, Jun 25, 2019, 12:15 AM Alan W. Irwin wrote: > On 2019-06-24 07:39-0600 Christopher Webster wrote: > > > Thank you Benjamin, that [install and use mingw-w64-x86_64-cmake in the > mingw64 shell]

Re: [CMake] [cmake-developers] [MSVC] Setting warning level on target feels like long-time bug

Cmake is already full of do much hardcoded logic / flags and does new releases so frequently (maybe there's some correlation between these two) that adding this would hardly impact upon its quality or maintainability. So to that end, hardcoding the default per msvc version so that it's not added

Re: [cmake-developers] [CMake] [MSVC] Setting warning level on target feels like long-time bug

Cmake is already full of do much hardcoded logic / flags and does new releases so frequently (maybe there's some correlation between these two) that adding this would hardly impact upon its quality or maintainability. So to that end, hardcoding the default per msvc version so that it's not added

Re: [CMake] dependencies of cross compiliations

> which I bet all of us would love to see. This is not correct. I would strongly prefer they continue with QBS instead. Cmake is defacto, but very suboptional. On Tue, Nov 27, 2018, 10:28 AM Rolf Eike Beer Am 2018-11-09 10:04, schrieb Torsten Robitzki: > > Hi, > > I hope this question was not

Re: [cmake-developers] [CMake] dependencies of cross compiliations

> which I bet all of us would love to see. This is not correct. I would strongly prefer they continue with QBS instead. Cmake is defacto, but very suboptional. On Tue, Nov 27, 2018, 10:28 AM Rolf Eike Beer Am 2018-11-09 10:04, schrieb Torsten Robitzki: > > Hi, > > I hope this question was not

[cmake-developers] Generalized verbose option for cmake --build.

Hi CMake developers, Why do I need to know the necessary verbose flag to make each back-end that cmake --build calls emit more information? If forces my build script to switch on the platform in a really ugly way for something I'd consider a very important feature (you already hardcode various

Re: [CMake] Automoc fails on MSYS2/MinGW

Hi Dmitry, You should report this on MSYS2's github repo (Alexpux), we apply some patches to Qt's CMake files and one of those may have caused this issue. It's unlikely to be a problem with CMake. On Thu, Oct 4, 2018 at 12:14 PM Dmitry Mikushin wrote: > > Dear all, > > I'm currently looking into

Re: [CMake] Issues trying to use the Anaconda compiler tools with CMake

On Wed, Aug 15, 2018, 3:05 PM Sebastián Mancilla wrote: > My 5c: Docker is just too annoying to work with if you are targeting users > to run your packages. > > From the point of view of the final user of your "binary distribution" > (some Docker image): > > - You have to figure out / copy paste

Re: [CMake] Issues trying to use the Anaconda compiler tools with CMake

Our compiler activation scripts (highlighting the bit of most interest to you I hope) are here: https://github.com/AnacondaRecipes/aggregate/blob/master/ctng-compilers-activation-feedstock/recipe/activate-gcc.sh#L84-L101 On Wed, Aug 15, 2018 at 11:44 AM, Ray Donnelly wrote: > Hi Sebast

Re: [CMake] Issues trying to use the Anaconda compiler tools with CMake

Hi Sebastián, Without having time to properly go through this, I feel I should correct some technical inaccuracies, but *all* of your issues can be sidestepped by using conda-build. Installation and RPATHs are always very tricky for projects to get right so we side step any issues here by running

Re: [CMake] Issues trying to use the Anaconda compiler tools with CMake

Docker is unnecessary overhead here and irrelevant to the question of which compilers to use when building conda packages (use ours or risk binary incompatibility with the rest of the ecosystems, please do not attempt to use e.g. CentOS6 system compilers to compile modern software either!). Docker

Re: [CMake] Issues trying to use the Anaconda compiler tools with CMake

ks that is not even necessary on Linux, because the > RPATH is already set by the toolchain. > > El lun., 13 de ago. de 2018 a la(s) 13:35, Isaiah Norton > (isaiah.nor...@gmail.com) escribió: >> >> See also: >> >> https://gitlab.kitware.com/cmake/cmake/merge_r

Re: [CMake] Approach to both shared and static lib (again, sorry)

On Sat, May 19, 2018 at 11:55 PM, Elvis Stansvik wrote: > 2018-05-19 21:49 GMT+02:00 Mateusz Loskot : >> On 19 May 2018 at 15:00, Elvis Stansvik wrote: >>> I know this has been asked before, but I've never seen a

Re: [CMake] Approach to both shared and static lib (again, sorry)

On Sat, May 19, 2018, 9:38 PM Mateusz Loskot <mate...@loskot.net> wrote: > On 19 May 2018 at 22:16, Ray Donnelly <mingw.andr...@gmail.com> wrote: > > On Sat, May 19, 2018, 8:50 PM Mateusz Loskot <mate...@loskot.net> wrote: > >> On 19 May 2018 at 15:00, Elvis St

Re: [CMake] Approach to both shared and static lib (again, sorry)

vide some distinction, at least. > > > > *From: *CMake <cmake-boun...@cmake.org> on behalf of Ray Donnelly < > mingw.andr...@gmail.com> > *Date: *Saturday, May 19, 2018 at 6:10 AM > *To: *Elvis Stansvik <elvis.stans...@orexplore.com> > *Cc: *CMake MailingList <

Re: [CMake] Approach to both shared and static lib (again, sorry)

On Sat, May 19, 2018, 8:50 PM Mateusz Loskot wrote: > On 19 May 2018 at 15:00, Elvis Stansvik > wrote: > > I know this has been asked before, but I've never seen a really > > authoritative answer. > > > > Say I have a simple single-library

Re: [CMake] Approach to both shared and static lib (again, sorry)

And the situation is *far* worse on Windows where the extension for a dll import library is the same as for a static library because cmake refuses to try to move the needle on this awful 'defacto' decision with respect to msvc when it is exactly the sort of thing cmake should strive to take the

Re: [CMake] find_package() for static only / shared only

Our why doesn't cmake set a long needed standard here of .dll.lib and be done with this nonsense? On Thu, Mar 22, 2018, 11:58 PM P F via CMake wrote: > Why not install shared libraries in one location and static libraries in > another? > > > On Mar 21, 2018, at 4:55 AM, Mario

Re: [CMake] RPATH cross-compile issue with CHECK_*_EXISTS

On Mon, Feb 27, 2017 at 9:39 PM, Brad King <brad.k...@kitware.com> wrote: > On 02/27/2017 03:54 PM, Ray Donnelly wrote: >> This is why my PR asks the linker that the compiler will use for the >> actual list of implicit link dirs. I'm sorry I've not had time to >> write

Re: [CMake] RPATH cross-compile issue with CHECK_*_EXISTS

On Mon, Feb 27, 2017 at 8:50 PM, Jörg Krause <joerg.krause@embedded.rocks> wrote: > Hi Brad, > > On Mon, 2017-02-27 at 11:43 -0500, Brad King wrote: >> On 02/07/2017 04:40 AM, Ray Donnelly wrote: >> > > > I have a PR that asks the linker (via the

Re: [CMake] RPATH cross-compile issue with CHECK_*_EXISTS

cks> wrote: > Hi Ray, > > Am 2017-02-07 02:46, schrieb Ray Donnelly: >> >> I have a PR that asks the linker (via the compiler) what its implicit >> search directories are instead. >> >> It is the right way to do it IMHO, but I need to find time to finish

Re: [CMake] RPATH cross-compile issue with CHECK_*_EXISTS

I have a PR that asks the linker (via the compiler) what its implicit search directories are instead. It is the right way to do it IMHO, but I need to find time to finish it unfortunately. On Feb 6, 2017 11:16 PM, "Jörg Krause" wrote: > On Mon, 2017-02-06 at 22:22

Re: [CMake] NO_SYSTEM_ENVIRONMENT_PATH globally?

On Mon, Dec 14, 2015 at 2:42 AM, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote: > On 2015-12-14 01:06- Ray Donnelly wrote: > >> Hi, >> >> I ran into a problem on MSYS2 recently building llvm+clang for >> mingw-w64 using CMake 3.4.1 (we carry a few lo

Re: [CMake] NO_SYSTEM_ENVIRONMENT_PATH globally?

On Mon, Dec 14, 2015 at 12:43 PM, Ray Donnelly <mingw.andr...@gmail.com> wrote: > On Mon, Dec 14, 2015 at 2:42 AM, Alan W. Irwin > <ir...@beluga.phys.uvic.ca> wrote: >> On 2015-12-14 01:06- Ray Donnelly wrote: >> >>> Hi, >>> >>> I

Re: [CMake] NO_SYSTEM_ENVIRONMENT_PATH globally?

On Mon, Dec 14, 2015 at 8:02 PM, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote: > On 2015-12-14 12:43- Ray Donnelly wrote: > >> The issue I've got here is that on MSYS2 we've decided that we don't >> want to provide libdl for mingw-w64 but do provide it for msy

[CMake] NO_SYSTEM_ENVIRONMENT_PATH globally?

aves somehow. If you can guide me on an acceptable way to achieve this I'd like to try to come up with a patch. -- Best regards, Ray Donnelly. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers vari

Re: [cmake-developers] [PATCH] FindPythonLibs repaired for MINGW -vs- WIN32 version confusion

n finds our Python and links to it then you'll have two c-runtimes in play .. not good .. so my vote is for "if MSVC" or "if MINGW" with no reference to "MSYS" as that's just a general purpose build environment. > On Wed, Sep 2, 2015 at 4:13 AM, Ray Donnelly <

Re: [cmake-developers] [PATCH] FindPythonLibs repaired for MINGW -vs- WIN32 version confusion

Make? >> >> I have used CMakeFindMSYSmake and CMakeFindUnixMake to set a variable >> designating >> what /usr translates to: >> # >> # the variable MSYS_USR_PATH is here created for use >> # where the /usr provided by an MSYS app needs to be translated for >>

Re: [cmake-developers] [PATCH] CMakeDetermineSystem.cmake distinguishes-MSYS-MINGW32 (was Re: Distinguishing MSYS2

On Tue, Aug 11, 2015 at 9:09 PM, Greg Jung gvj...@gmail.com wrote: Do note that I am an observer or reporter and not responsible for the posix-version cmake in msys2. Ray Donnelly is much closer to that than I am. What I can do, though, is bring in the modules (.cmake files) and make sure

Re: [cmake-developers] Distinguishing MSYS2

On Fri, Aug 7, 2015 at 2:21 PM, Brad King brad.k...@kitware.com wrote: On 08/07/2015 08:33 AM, Ray Donnelly wrote: Finally, there's the consideration as to whether MSYS2 implies you are using just the minimum amount of the MSYS2 shell or whether you've gone all-in with MSYS2

Re: [cmake-developers] [PATCH] FindPythonLibs repaired for MINGW -vs- WIN32 version confusion

On Fri, Aug 7, 2015 at 7:58 AM, Greg Jung gvj...@gmail.com wrote: Hi there, A patch for review: I have two changes in FindPythonLibs that should make for less failure in the MINGW/MSYS camp. I think you explicitly mean the MSYS2 camp here. We have our own Pythons (4 of them, 2 native and

Re: [cmake-developers] Distinguishing MSYS2 (was: FindPythonLibs repaired for MINGW -vs- WIN32 version confusion)

On Fri, Aug 7, 2015 at 1:16 PM, Brad King brad.k...@kitware.com wrote: On 08/07/2015 05:25 AM, Ray Donnelly wrote: CMake needs to be able to identify MSYS2 distinctly from both MINGW and MSYS first. Would a patch making that distinction be acceptable to CMake? Yes, I think that makes sense

[cmake-developers] [PATCH] Add --no-install-deps to bootstrapping procedure

MSYS2 uses Pacman to manage package dependencies so without this patch, our mingw-w64-cmake-git package ends up bundling all the DLLs it depends on which causes conflicts with the packages those DLLs really belong to. Please review. -- Best regards, Ray Donnelly. 0001-configure-Add-no-install

[cmake-developers] [PATCH] Add --no-install-deps to bootstrapping procedure

to. Please review. -- Best regards, Ray Donnelly. 0001-configure-Add-no-install-deps-option.patch Description: Binary data -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support

Re: [cmake-developers] [PATCH] Add --no-install-deps to bootstrapping procedure

On Wed, Aug 5, 2015 at 6:34 PM, Brad King brad.k...@kitware.com wrote: On 08/05/2015 11:16 AM, Ray Donnelly wrote: MSYS2 uses Pacman to manage package dependencies so without this patch, our mingw-w64-cmake-git package ends up bundling all the DLLs it depends on which causes conflicts

Re: [CMake] Mixed linking

On Sat, Feb 21, 2015 at 9:59 AM, Stephen Kelly steve...@gmail.com wrote: Ray Donnelly wrote: 1) Am I right when I say CMake, Qt and static linking don’t mix ? They should mix fine. What I meant when I wrote this was 'they should mix fine, but some convenience is not available - you need

[CMake] Mixed linking

'. Qt static built with MinGW-w64 does though as the msvcrt.dll we use is present on all Windows releases all the way back to Windows XP. Maybe I used the wrong one though, as the Qt SDK seems to be static enough. Best regards, Ray Donnelly. -- Powered by www.kitware.com Please keep messages