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 unnecessarily, triggering this warning would seem appropriate to me. Either that or disabling this warning with more hard coded flags would also be appropriate. The current status in not ideal. On Sun, Dec 9, 2018, 7:55 AM Mateusz Loskot On Sun, 9 Dec 2018 at 14:09, Marc CHEVRIER > wrote: > > > > I think the discussion is shifting from the initial problem which was > unwanted warning « Command line warning D9025: overriding '/W3' with '/W4' > ». > > I disagree with your opinion. > Fixing just the warning would be a symptomatic treatment. > > > Changing defaults is not a good idea from my point of view because > relying on defaults can be problematic if Microsoft decide to change the > default behaviour. > > Although I think it is a long shot at something that is (highly) > unlikely to change, YAGNI consideration, > I understand CMake developers may be reluctant to change the long-time > defaults. > > > The real question is how to manage cleanly target specific flags > overriding global or directory defaults? > > From end-user point of view (I have not checekd CMake implementation), > I'd either do not explicitly set -W defaults or strip any -W option > prior re-setting > with (possibly) new value passed to target_compile_options. > > Best regards, > -- > Mateusz Loskot, http://mateusz.loskot.net > -- > > 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 the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake-developers > -- 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 the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake-developers
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 asked before. I work in the embedded
> > field and there it is usually to have at least two different build
> > platforms. The Host platform, where unit tests are build (and where
> > CMake is running) and an embedded Target platform, where targets are
> > build with a cross compiler. Sometimes such a system comes with
> > self-written tools that are build and run on the Host platform to
> > build a target for the embedded Target platform (adding meta data to a
> > binary to be used by a bootloader for example).
> >
> > Usually I have two different build folders, one for the Host platform
> > and one for the Target platform, using different calls to cmake to
> > choose from a set of tools and targets. But when using this approach,
> > it is necessary that the Host platform build ran before the Target
> > platform build, so that tools that are required for the Target
> > platform are build during the Host target build.
> >
> > One solution I’ve came up with, is to build the required tools during
> > the Target platform build, using an add_custom_target() to invoke the
> > Target compiler directly. This works fine, as long as the tools are
> > basically build just out of a couple of files.
> >
> > What would be the „CMake-Way“ to add the tools (that have to be build
> > on the Target platform) as dependency to targets that have to be build
> > for the Target (cross compile) platform?
>
> TL;DR: there is not "good" way yet. But there should be one.
>
> I'm hijacking this and move it to the developers list, because that is
> something "big", and we need to think about how to do that. I find it
> important to correctly solve this as it would simplify a lot of things.
> Especially given that Qt is thinking to use CMake to build Qt itself,
> which I bet all of us would love to see. But they will be after us if we
> don't offer a solution for this. And given the increasing amount of
> cross-setups these days I'm sure that a lot of other people would
> benefit.
>
> My first idea was to have something like add_host_executable(), which
> would only be called when this is not CMAKE_CROSSCOMPILING, but at the
> end I think this clutters things too much.
>
> Then I came up with:
>
>add_host_build("relative source dir" "build dir" [VARS])
>
> This would create an entirely new CMake scope (with it's own
> CMakeCache.txt and the like) in "${CMAKE_CURRENT_BUILD_DIR}/build dir",
> and would not take the CMAKE_TOOLCHAIN_FILE into account. People are
> free to pass "." as relative source dir in case they want to start at
> top level, but they may as well pass "tools", "generators" or whatever
> they call it. This is not intended to be called multiple times from the
> same project as it would scan for compiler and environment once for
> every call, but doing so does no harm beyond being slow(er) and the
> targets of one such sub-build not being visible to the others.
>
> My idea would be that things added by add_executable() inside such a
> sub-build are visible as targets from the outer build. Other things like
> libraries and the like need not to be, they can't be linked in the outer
> world. The user is free to build with shared libs inside, and running
> the things from the build tree would result in the correct freshly build
> libs being picked up because of RPATH or whatever. There is no install
> of those targets possible from the outer build, this can entirely be
> managed from the host build. Of course one must be possible to set
> variables on the host build, that's where VARS comes into play. This
> holds a list of variable names that will be passed to the hostbuild. No
> values, to avoid all sorts of quoting issues. Helpful would be a special
> variable for CMAKE_INSTALL_PREFIX as this needs a bit of attention (and
> a non-sysroot thing prefix in the toolchain file). Confused? Granted,
> here is an example:
>
> if (CMAKE_CROSSCOMPILING)
> set(HOST_INSTALL_DIR "/some/where")
> add_host_build(. host HOST_INSTALL_DIR)
> endif ()
> add_executable(magic magic.cpp)
> install(TARGETS magic DESTINATION bin) # installs both the host and the
> target tool!
> add_custom_command(OUTPUT ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp COMMAND
> magic) # will call the host build
> if (NOT CMAKE_HOST_BUILD)
> add_executable(foo ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp)
> install(TARGETS foo DESTINATION bin)
> endif ()
>
> This should end up in a layout like this:
>
> /tmp/install/prefix/tools/bin/magic.exe # Windows host
> /tmp/install/prefix/sysroot/usr/bin/magic # Unix guest
> /tmp/install/prefix/sysroot/usr/bin/foo
>
> The toolchain file would look somehow like this:
>
> set(CMAKE_HOST_PREFIX prefix
> set(CMAKE_SYSROOT
[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 things to enable cmake --build to work, so why not this as well?) Something like cmake --build --verbose would be good. Best regards, Ray. -- 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 the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] FindPythonLibs repaired for MINGW -vs- WIN32 version confusion
On Wed, Sep 2, 2015 at 7:59 PM, Greg Jung <gvj...@gmail.com> wrote: >> Would: >> if (MSVC) >> .. not be a better discriminator here? There's probably some people >> who use MSYS2 in conjunction with MSVC compilers. >> > If they are doing that, won't they want the MSYS-installed version? If it's > not found then the library > reverts to the windows-registered version. It just gives the possible python > living under the designated path the first crack. > Not necessarily; I mean, if MSVC is set, then CMake is going to use MSVC and if it then 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 <mingw.andr...@gmail.com> > wrote: >> >> On Wed, Sep 2, 2015 at 10:33 AM, Greg Jung <gvj...@gmail.com> wrote: >> > To revive this issue, I show a comparison of the CMakeCache entries for >> > cmake run from the same configuration, 1) cmake 3.2.3 with "old" >> > PythonLibs >> > .vs. 2) cmake 3.3.1 with the new FindPythonLibs.cmake. >> > >> > Cmake 1): >> > >> > # This is the CMakeCache file. >> > # For build in directory: d:/mingw/msys32/tmp/bld-32 >> > # It was generated by CMake: D:/mingw/msys32/mingw32/bin/cmake.exe >> > [...] >> > //Path to a program. >> > PYTHON_EXECUTABLE:FILEPATH=D:/mingw/msys32/mingw32/bin/python.exe >> > >> > //Path to a file. >> > PYTHON_INCLUDE_DIR:PATH=D:/mingw/msys32/mingw32/include/python2.7 >> > >> > //Path to a library. >> > PYTHON_LIBRARY:FILEPATH=E:/Python27/libs/libpython27.a >> > >> > //Dependencies for the target >> > >> > _plplotcmodule_LIB_DEPENDS:STATIC=general;plplot;general;E:/Python27/libs/libpython27.a; >> > >> > //Dependencies for the target >> > >> > plplot_widgetmodule_LIB_DEPENDS:STATIC=general;plplot;general;E:/Python27/libs/libpython27.a; >> > //Path to CMake executable. >> > CMAKE_COMMAND:INTERNAL=D:/mingw/msys32/mingw32/bin/cmake.exe >> > //Details about finding PythonLibs >> > >> > FIND_PACKAGE_MESSAGE_DETAILS_PythonLibs:INTERNAL=[E:/Python27/libs/libpython27.a][D:/mingw/msys32/mingw32/include/python2.7][v2.7.10()] >> > >> > >> > Cmake 2): cmake 3.3.1 run from outside the msys tree,using the patched >> > FindPythonLibs.cmake >> > >> > # This is the CMakeCache file. >> > # For build in directory: d:/mingw/msys32/tmp/bld-32 >> > # It was generated by CMake: D:/programs/CMake-3.3/bin/cmake.exe >> > [...] >> > //Path to a program. >> > PYTHON_EXECUTABLE:FILEPATH=D:/mingw/msys32/mingw32/bin/python.exe >> > >> > //Path to a file. >> > PYTHON_INCLUDE_DIR:PATH=D:/mingw/msys32/mingw32/include/python2.7 >> > >> > //Path to a library. >> > PYTHON_LIBRARY:FILEPATH=D:/mingw/msys32/mingw32/lib/libpython2.7.dll.a >> > >> > //Dependencies for the target >> > >> > _plplotcmodule_LIB_DEPENDS:STATIC=general;plplot;general;D:/mingw/msys32/mingw32/lib/libpython2.7.dll.a; >> > >> > //Dependencies for the target >> > >> > plplot_widgetmodule_LIB_DEPENDS:STATIC=general;plplot;general;D:/mingw/msys32/mingw32/lib/libpython2.7.dll.a; >> > //Path to CMake executable. >> > CMAKE_COMMAND:INTERNAL=D:/programs/CMake-3.3/bin/cmake.exe >> > //Details about finding PythonLibs >> > >> > FIND_PACKAGE_MESSAGE_DETAILS_PythonLibs:INTERNAL=[D:/mingw/msys32/mingw32/lib/libpython2.7.dll.a][D:/mingw/msys32/mingw32/include/python2.7][v2.7.10()] >> > >> > >> > So, my windows-y python installation which is registered in the windows >> > registry, interferes with my use of >> > python until I replace the FindPythonLibs.cmake with the modified >> > version. >> > The new routine will find the registry version in the same manner if >> > (WIN32 AND NOT (MINGW OR MSYS)). >> > >> >> >> Would: >> if (MSVC) >> .. not be a better discriminator here? There's probably some people >> who use MSYS2 in conjunction with MSVC compilers. >> >> > Someone using this routine from windows (MSVC) or from a non-win32 >> > environment should have the same results as before. If the MSYS user >> > only >> > has a separate windows-based registry-registered python >> > and there is nothing found
Re: [cmake-developers] [PATCH] FindPythonLibs repaired for MINGW -vs- WIN32 version confusion
On Wed, Sep 2, 2015 at 10:33 AM, Greg Jung <gvj...@gmail.com> wrote: > To revive this issue, I show a comparison of the CMakeCache entries for > cmake run from the same configuration, 1) cmake 3.2.3 with "old" PythonLibs > .vs. 2) cmake 3.3.1 with the new FindPythonLibs.cmake. > > Cmake 1): > > # This is the CMakeCache file. > # For build in directory: d:/mingw/msys32/tmp/bld-32 > # It was generated by CMake: D:/mingw/msys32/mingw32/bin/cmake.exe > [...] > //Path to a program. > PYTHON_EXECUTABLE:FILEPATH=D:/mingw/msys32/mingw32/bin/python.exe > > //Path to a file. > PYTHON_INCLUDE_DIR:PATH=D:/mingw/msys32/mingw32/include/python2.7 > > //Path to a library. > PYTHON_LIBRARY:FILEPATH=E:/Python27/libs/libpython27.a > > //Dependencies for the target > _plplotcmodule_LIB_DEPENDS:STATIC=general;plplot;general;E:/Python27/libs/libpython27.a; > > //Dependencies for the target > plplot_widgetmodule_LIB_DEPENDS:STATIC=general;plplot;general;E:/Python27/libs/libpython27.a; > //Path to CMake executable. > CMAKE_COMMAND:INTERNAL=D:/mingw/msys32/mingw32/bin/cmake.exe > //Details about finding PythonLibs > FIND_PACKAGE_MESSAGE_DETAILS_PythonLibs:INTERNAL=[E:/Python27/libs/libpython27.a][D:/mingw/msys32/mingw32/include/python2.7][v2.7.10()] > > > Cmake 2): cmake 3.3.1 run from outside the msys tree,using the patched > FindPythonLibs.cmake > > # This is the CMakeCache file. > # For build in directory: d:/mingw/msys32/tmp/bld-32 > # It was generated by CMake: D:/programs/CMake-3.3/bin/cmake.exe > [...] > //Path to a program. > PYTHON_EXECUTABLE:FILEPATH=D:/mingw/msys32/mingw32/bin/python.exe > > //Path to a file. > PYTHON_INCLUDE_DIR:PATH=D:/mingw/msys32/mingw32/include/python2.7 > > //Path to a library. > PYTHON_LIBRARY:FILEPATH=D:/mingw/msys32/mingw32/lib/libpython2.7.dll.a > > //Dependencies for the target > _plplotcmodule_LIB_DEPENDS:STATIC=general;plplot;general;D:/mingw/msys32/mingw32/lib/libpython2.7.dll.a; > > //Dependencies for the target > plplot_widgetmodule_LIB_DEPENDS:STATIC=general;plplot;general;D:/mingw/msys32/mingw32/lib/libpython2.7.dll.a; > //Path to CMake executable. > CMAKE_COMMAND:INTERNAL=D:/programs/CMake-3.3/bin/cmake.exe > //Details about finding PythonLibs > FIND_PACKAGE_MESSAGE_DETAILS_PythonLibs:INTERNAL=[D:/mingw/msys32/mingw32/lib/libpython2.7.dll.a][D:/mingw/msys32/mingw32/include/python2.7][v2.7.10()] > > > So, my windows-y python installation which is registered in the windows > registry, interferes with my use of > python until I replace the FindPythonLibs.cmake with the modified version. > The new routine will find the registry version in the same manner if > (WIN32 AND NOT (MINGW OR MSYS)). > Would: if (MSVC) .. not be a better discriminator here? There's probably some people who use MSYS2 in conjunction with MSVC compilers. > Someone using this routine from windows (MSVC) or from a non-win32 > environment should have the same results as before. If the MSYS user only > has a separate windows-based registry-registered python > and there is nothing found in the unix-style searches, the previous behavior > of providing answers from the registry-based installation kicks in. > > Regards, Greg > > On Fri, Aug 7, 2015 at 4:05 PM, Greg Jung <gvj...@gmail.com> wrote: >>> >>> > I have two changes in FindPythonLibs that should make for less >>> > failure in >>> > the MINGW/MSYS camp. >>> >>> While I support this stuff, I think for it to not >>> break other people (who use either mingw.org/MinGW-w64 compilers or >>> the old MSYS with 'normal' Windows CPython), >> >> >> If there is not a python installation to be found in the mingw path, the >> patched routine will drop into the registry search. which will look >> exactly like previous. >> >>> I think you explicitly mean the MSYS2 camp here. We have our own >>> Pythons (4 of them, 2 native and 2 cygwin-y) all of which use a >>> Linux-y layout. >> >> >> I've been running with msys2, and lately I've done a lot of test-running >> of plplot using plain vanilla >> CMake without the patches I used to think were needed. I found that from >> the CMake point of view, >> msys1 or msys2 is a distinction without a difference. >> >>> >>> 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? >> >> I have used CMakeFindMSYSmake and CMakeFindUnixMake to set a variable >> designating >> what /usr translates to: >> # >> # the variable MSYS_USR_PATH is here
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 the changes (already) effected there can co-exist with a normal MSYS (using mingw) module collection. Currently, MSYS is almost exactly parallel to CYGWIN and this would need to be either (MSYS AND CMAKE_HOST_UNIX) or (MSYS AND NOT MINGW). Probably the latter. Greg, Am I right in reading that you use both MSYS/mingw.org and MSYS2/MinGW-w64? Most people are sloppy about terminology so it gets confusing very easily. Regards, Greg On Tue, Aug 11, 2015 at 6:18 AM, Brad King brad.k...@kitware.com wrote: On 08/10/2015 04:07 PM, Greg Jung wrote: There is an msys2-specific cmake version already built along those lines, with several patches in the modules section to parallel the CYGWIN cases, in the msys2 distribution. It does not have a MSYS Makefiles generator option but uses Unix generator as you anticipate. In order to get CMAKE_HOST_UNIX set properly for CMakeDetermineSystem shouldn't we upstream your changes for a msys2-specific CMake? I presume it does a #if defined(__MSYS__) somewhere near where we already do #if defined(__CYGWIN__). You can see our patch to add MSYS2 support here: https://github.com/Alexpux/MSYS2-packages/blob/master/cmake/cmake-3.2.3-msys.patch .. #if defined(__MSYS__) is used and we just set CMAKE_SYSTEM_NAME to MSYS, not MSYS2. If we risk breaking MSYS then we can go for MSYS2 I guess. We might need to patch a few projects we build in that case, but that's fine. There's no compiler flag that identifies MSYS2 as distinct from MSYS though .. I guess GCC version could be used as I'd be surprised if MSYS update their GCC version again. In terms of working on this, initially I was actually keen to try to be able to use MinGW-w64 CMake to build even msys-2.0.dll-linked software, but I guess I was being hopeful as two other MSYS2 developers disagreed with me :-) Alexey Pavlov did all of the work on our msys2/cmake package and he's on holiday this month. I've done a good bit of work on our native MinGW-w64 cmake packages so I know my way around it a bit, if you want to progress this before then. Best regards, Ray. Thanks, -Brad -- 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 the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
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 CMAKE_SYSTEM_NAME should refer to the target application environment. If you're building with the MinGW tools for Windows then the value of CMAKE_SYSTEM_NAME should simply be Windows. For Cygwin we have a CMake built to run in Cygwin and target native Cygwin builds, and that CMake is completely different from the one used for Windows builds. The Cygwin CMake cannot be used to host builds on Windows and the Windows CMake cannot be used to host builds on Cygwin. Does MSYS2 have its own runtime such that binaries can understand POSIX paths like in Cygwin? In that case there should be a separate non-Windows CMake for MSYS2 just like we have for Cygwin. Yes, it's very much like Cygwin (a fork with a few additions) and understands POSIX paths (C:\ - /c/, without the /cygdrive stuff). Our runtime DLL is called msys-2.0.dll instead of cygwin1.dll. It would seem that our msys/cmake package identifies CMAKE_SYSTEM_NAME as MSYS at present: https://github.com/Alexpux/MSYS2-packages/blob/master/cmake/cmake-3.2.3-msys.patch Cheers, Ray. -Brad -- 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 the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
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 2 cygwin-y) all of which use a
Linux-y layout. While I support this stuff, I think for it to not
break other people (who use either mingw.org/MinGW-w64 compilers or
the old MSYS with 'normal' Windows CPython), 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?
1. Distinguish mingw and win32. Avoid the registry lookup.
if(WIN32) = if(WIN32 AND NOT (MINGW OR MSYS)) for the DEBUG library search,
a full unix-style find_library call without reference to possible registry
entries.
+NAMES
+python${_CURRENT_VERSION_NO_DOTS}
+python${_CURRENT_VERSION}mu
+python${_CURRENT_VERSION}m
+python${_CURRENT_VERSION}u
+python${_CURRENT_VERSION}
+#
+NAMES_PER_DIR
+# Avoid finding the .dll in the PATH. We want the .lib.
+# The NAMES_PER_DIR above should allow the library to be found where it was
desired
+# in the prioritized location of PATH - cmake V3.3 behavior;
+#NO_SYSTEM_ENVIRONMENT_PATH works counter to cmake-3.3 improvement
where CMake will look into path.
+#
+ )
+endif()
2. NAMES_PER_DIR replaces NO_SYSTEM_ENVIRONMENT_PATH to modify the search
such that windows/system32/python27.dll
(for instance) is not picked up before finding the proper library under
path component/lib
Instead of throwing all of the possible locations into a single
find_library(), for WIN32+MINGW builds this may latch into a windows'
python.
This is not an issue when CMake is run from /MINGW.
CMake-3.3.0 (and above) can use PATH to discover targets of find_library,
allowing
a user with several MINGW installations to use a single cmake (and
cmake-gui) instead of
installing several copies for each mingw to be built with. Unless the
find_path or
find_library uses NO_SYSTEM_ENVIRONMENT_PATH which kills the new feature.
Even though /mingw32/bin is frontmost in the path,
windows/system32/python27.dll
was latched onto because the name matches earlier in the NAMES list than
python2.7.
to avoid this all of the names are tested as the direcftories are presented,
this via the
NAMES_PER_DIR qualifier.
This makes is possible for me to run builds using Cmake-gui without
installing cmake-gui
in /mingw32/bin (and qt5 along with it!).
Regards,
Greg
--
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 the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
--
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 the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
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 since the MSYS2 environment is distinct from Windows, MinGW, MSYS, and Cygwin. What should CMAKE_SYSTEM_NAME be for MSYS2? Off the cuff, MSYS2 sounds reasonable, but I think we need to carefully think about this .. We have CMake packages built with MinGW-w64 and also CMake packages built with msys2 GCC (that are used for only a few of our packages). Do they need to be separately identifiable? I also wonder whether the msys2 CMake could be done away with if we used some functions to convert paths between shell-system and make-system .. I'll ask the MSYS2 developers who added the msys2 CMake package about this. 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 (so are happy to be using our Python's which are not found in the registry and have a Unix file layout prefixed in /mingw32 or /mingw64). I'd like to hear others' thoughts on this! Thanks, -Brad -- 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 the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[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-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 the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [PATCH] Add --no-install-deps to bootstrapping procedure
I left some debug stuff in the last version. Here it is without that; apologies. 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-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 the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
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 with the packages those DLLs really belong to. I don't think we should require an explicit option for this and should instead just not install runtime dependencies by default. They are needed only when packaging binaries for independent redistribution. Try this: Do not install 3rd-party dependencies by default http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=26f5445b That works for me. Many thanks Brad. Thanks, -Brad -- 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 the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
