Re: [CMake] cmake on MinGW64; which generator

[Ray Donnelly]

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] fixed it.
>
> I was happy to hear that Benjamin solved this first issue for you.
>
> Just to follow up on what he said, I confirm the good PLplot results
> for the MSYS2 platform that I referred to in my previous post also
> used the "mingw-w64-x86_64-cmake" native package rather than the
> non-native (linked to msys2.dll) "cmake" package.
>
> You (and others reading this thread) should consult the patches at
> 
> to see the various ways that the "mingw-w64-x86_64-cmake" package
> differs from vanilla cmake for Windows from Kitware.  I agree with
> another poster's comments that if indeed some or all of those fixes
> are really necessary for the MSYS2 platform that ideally they should
> be adopted by the upstream CMake developers.  So I hope those
> developers are (i) reading this thread and (ii) willing to follow up
> by looking at those patches.
>
> Alan
> __
> Alan W. Irwin
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.org); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __
>
> Linux-powered Science
> __
> --
>
> 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
>
-- 

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

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

[Ray Donnelly]

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

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

[Ray Donnelly]

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] dependencies of cross compiliations

[Ray Donnelly]

> 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 

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

[Ray Donnelly]

> 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.

[Ray Donnelly]

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] Automoc fails on MSYS2/MinGW

[Ray Donnelly]

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 an error from Automoc below, which gives no clue 
> about the cause of failure (Output is empty). The mechanics of Automoc in 
> CMake is not clear. Looks like "cmake_autogen" only launches a command 
> described in variables. But where the command return value is checked? What 
> places should I look at to debug cmake_autogen/automoc in CMake?
>
> Thanks & Kind regards,
> - Dmitry Mikushin.
>
> $ make
> [  0%] Automatic MOC for target glazomer
> Start
>
> AutoMoc subprocess error
> 
> The content generation command for "moc_predefs.h" failed.
>
> Command
> ---
> /mingw64/bin/x86_64-w64-mingw32-g++.exe -dM -E -c 
> /usr/share/cmake-3.12.2/Modules/CMakeCXXCompilerABI.cpp 
> -I/c/Users/dmikushin/glazomer/glazomer/build/glazomer_autogen/include 
> -I/mingw64/include/QtDBus -I/mingw64/include/QtNetwork 
> -I/mingw64/include/QtTest -I/mingw64/include/qwt 
> -I/mingw64/include/libusb-1.0 
> -I/c/Users/dmikushin/glazomer/glazomer/ThirdParty/eigen 
> -I/c/Users/dmikushin/glazomer/glazomer/src -I/mingw64/include 
> -I/mingw64/include/QtCore -I/mingw64/share/qt5/mkspecs/win32-g++ 
> -I/mingw64/include/QtGui -I/mingw64/include/QtWidgets -DQT_CORE_LIB 
> -DQT_GUI_LIB -DQT_WIDGETS_LIB
>
> Output
> --
>
> make[2]: *** [CMakeFiles/glazomer_autogen.dir/build.make:58: 
> CMakeFiles/glazomer_autogen] Error 1
> make[1]: *** [CMakeFiles/Makefile2:180: CMakeFiles/glazomer_autogen.dir/all] 
> Error 2
> make: *** [Makefile:130: all] Error 2
>
> --
>
> 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
-- 

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

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

[Ray Donnelly]

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 the proper docker command line to
> run the container (mount volumes, open ports, set environment, etc)
> - It runs on a virtual machine if you are not in Linux
> - How to run some graphical application?
> - In Linux if you need to write some output files in the mounted volumen,
> they will have the wrong permissions, unless the image provides a fix for
> it.
> - What if you need some extra package? Now you have to create your own
> image based on the distributed image.
> - You are limited to the package versions available in the Linux
> distribution in which the image is based
>
> Now consider conda:
>
> conda create -n myenv meta-package
> conda activate myenv
> # run all binaries natively, they are already on PATH, access your file
> system, install extra packages, have all your command line tools and IDEs
> at hand.
>
> From the point of view of doing development with Docker, my biggest gripe
> is how to edit the code while running it in the container. Say I have Vim
> in the host (or an IDE).
> When editing the sources in the host, all dependencies and compilers are
> in the container, so I lose linting and compilation errors and
> autocompletion. I would also need to install again all my development tools
> in the container (say tmux, ag, jq, fzf etc).
>
> Trying to do development while inside a Conda environment is something I
> think it should work, and I don't think conda-build is necessary until I am
> ready to create a package.
> Unfortunately I hit the issue of this thread.
>

I already explained how to workaround the issues you saw. The compilers do
work in most normal situations, i use them extensively, even for linking to
rust software (macOS and Linux), the only caveat being that you should
instead so conda cdt packages on Linux for system library dependencies and
on macOS you need to get an old SDK.

>
> I have had no issues creating packages with conda-build and CMake so far,
> and I've packaged a few, including some Qt applications.
>
> El mié., 15 de ago. de 2018 a la(s) 05:29, Eric Noulard (
> eric.noul...@gmail.com) escribió:
>
>>
>>
>> Le mar. 14 août 2018 à 20:38, Sebastián Mancilla  a
>> écrit :
>>
>>> I wanted to try Conda for normal day-to-day C++ development, while
>>> having all the dependencies isolated from other projects and the base
>>> system.
>>>
>>> - Change the sources
>>> - Build
>>> - Run the tests
>>> - Repeat
>>>
>>
>> Hi Sebastian,
>>
>> Just curious on why you would prefer conda over "real" container
>> technology like docker or rkt for the kind of usage you describe ?
>> Do you ultimately want to distribute your software as conda packages?
>>
>> I'm not proficient in conda but AFAIK docker (or rkt) offers
>> easier/better isolation for the usage you describe.
>> The side-effect being that inside your container cmake should behave like
>> as expected.
>> At least this is my own experience.
>>
>> Some people even try to automatize the container creation out of conda
>> packaged software:
>> https://github.com/BioContainers/mulled
>> 
>> I have no experience with that whatsoever, I usually craft my own
>> dockerfile and work with that.
>>
>> If your goal includes the distrubution of your software as conda package
>> may be you can get in touch with people
>> at conda-forge: https://conda-forge.org/#about
>> ,
>> I bet they build a lot of cmake-based projects in there and may
>> have experienced same caveats with the conda compilers usage.
>>
>>
>> --
>> Eric
>>
>
>
> --
> Sebastian Mancilla Matta
> CCTVal, UTFSM
> Valparaíso, Chile
>
-- 

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

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

[Ray Donnelly]

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 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 post-build fixups on these things. We ensure RPATHs have
> the opportunity to add our own, uniquify them (I think!), and make
> them fully relative on macOS and Linux.
>
> WRT RPATHs being added or not, we set LDFLAGs for RPATHs the linker
> activation script *when run under conda-build*. If you want to fake
> that so you get the exact same flags that are used to compile our
> packages do: CONDA_BUILD=1 conda activate envname. If you don't set
> CONDA_BUILD=1 then it'll set all flags *except* -I${PREFIX}/include,
> -L${PREFIX}/lib and -Wl,-rpath,${PREFIX}/lib.
>
> If you want to use our compilers in their completely 'raw' form (of
> course you could unset LDFLAGS, CFLAGS, CPPFLAGS too), then install
> e.g. gcc_impl_linux-64 instead of gcc_linux-64 which really are
> helpers for interfacing the raw compilers with conda-build (and
> setting good default compilation flags for security and performance
> reasons).
>
> You mentioned using [DY]LD_LIBRARY_PATH, I would caution no one to do
> this ever outside of development workflows. FWIW, we run into lots of
> trouble with LD_LIBRARY_PATH and I am *firmly* in the camp that
> LD_LIBRARY_PATH is harmful (i.e. never use it systematically) and I am
> utterly convinced that DT_RUNPATH is a huge mistake. We actually
> consider detection of DT_RUNPATH in any of our DSOs or exes an error
> condition and only allow DT_RPATH. We just had so many bugs due to the
> wrong libs being used by end users due to this, for example there is
> no way a Qt application linked against our Qt libs is going to be
> happy with some random system Qt library that's been interposed.
>
> For macOS, you should also set CONDA_BUILD_SYSROOT= macOS 10.9, 10.10 or 10.11 SDK> (depending on the macOS version you
> want to target). These old SDKs can be gotten from old Xcode builds
> and also on github. Unfortunately the compilers are not compatible
> with the new .tbd file format used in newer SDKs and by the newest
> Apple system linker and the source to enable that has not been
> released yet (there have been no new source drops for Apple's ld64 in
> a while).
>
> But please, just use conda-build! While we try to keep them working in
> as many situations as we can, these tools are primarily focussed
> around conda-build and the technical decisions we make with respect to
> them will be from that perspective.
>
> Hope this helps some?
>
>  Fri, Aug 10, 2018 at 10:48 PM, Sebastián Mancilla  wrote:
>> I am trying to use Conda as a package manager for isolated C++ development
>> environments. But unfortunately, when using CMake with the Anaconda-provided
>> compilers [1] (which are used to compile the binary packages in the Anaconda
>> repositories), things do not work as expected.
>>
>> I have a small test case available here [2], with an executable calling a
>> shared library and a third-party dependency installed with Conda.
>>
>> [1]:
>> https://conda.io/docs/user-guide/tasks/build-packages/compiler-tools.html
>> [2]: https://gist.github.com/smancill/b28ca07ac11fdf285b4d559545a1630b
>>
>> --
>>
>> First, when using the system compiler, all works fine (but I am not sure of
>> the
>> binary compatibility with the Conda packages, that's why I want to use the
>> Anaconda compilers):
>>
>> # create the environment and install XercesC
>> $ conda create -n test-system xerces-c
>> ...
>> environment location:
>> /Users/smancill/.local/share/miniconda3/envs/test-system
>> ...
>> The following NEW packages will be INSTALLED:
>>
>> icu:   58.2-h4b95b61_1
>> libcxx:4.0.1-h579ed51_0
>> libcxxabi: 4.0.1-hebd6815_0
>> xerces-c:  3.2.1-h44e365a_0
>> ...
>>
>> # activate the environment
>> $ conda activate test-system
>>
>> $ mkdir build-osx-system
>> $ cd build-osx-system
>> $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX
>> -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
>> -- The CXX compiler identification is AppleClang 9.0.0.

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

[Ray Donnelly]

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 post-build fixups on these things. We ensure RPATHs have
the opportunity to add our own, uniquify them (I think!), and make
them fully relative on macOS and Linux.

WRT RPATHs being added or not, we set LDFLAGs for RPATHs the linker
activation script *when run under conda-build*. If you want to fake
that so you get the exact same flags that are used to compile our
packages do: CONDA_BUILD=1 conda activate envname. If you don't set
CONDA_BUILD=1 then it'll set all flags *except* -I${PREFIX}/include,
-L${PREFIX}/lib and -Wl,-rpath,${PREFIX}/lib.

If you want to use our compilers in their completely 'raw' form (of
course you could unset LDFLAGS, CFLAGS, CPPFLAGS too), then install
e.g. gcc_impl_linux-64 instead of gcc_linux-64 which really are
helpers for interfacing the raw compilers with conda-build (and
setting good default compilation flags for security and performance
reasons).

You mentioned using [DY]LD_LIBRARY_PATH, I would caution no one to do
this ever outside of development workflows. FWIW, we run into lots of
trouble with LD_LIBRARY_PATH and I am *firmly* in the camp that
LD_LIBRARY_PATH is harmful (i.e. never use it systematically) and I am
utterly convinced that DT_RUNPATH is a huge mistake. We actually
consider detection of DT_RUNPATH in any of our DSOs or exes an error
condition and only allow DT_RPATH. We just had so many bugs due to the
wrong libs being used by end users due to this, for example there is
no way a Qt application linked against our Qt libs is going to be
happy with some random system Qt library that's been interposed.

For macOS, you should also set CONDA_BUILD_SYSROOT= (depending on the macOS version you
want to target). These old SDKs can be gotten from old Xcode builds
and also on github. Unfortunately the compilers are not compatible
with the new .tbd file format used in newer SDKs and by the newest
Apple system linker and the source to enable that has not been
released yet (there have been no new source drops for Apple's ld64 in
a while).

But please, just use conda-build! While we try to keep them working in
as many situations as we can, these tools are primarily focussed
around conda-build and the technical decisions we make with respect to
them will be from that perspective.

Hope this helps some?

 Fri, Aug 10, 2018 at 10:48 PM, Sebastián Mancilla  wrote:
> I am trying to use Conda as a package manager for isolated C++ development
> environments. But unfortunately, when using CMake with the Anaconda-provided
> compilers [1] (which are used to compile the binary packages in the Anaconda
> repositories), things do not work as expected.
>
> I have a small test case available here [2], with an executable calling a
> shared library and a third-party dependency installed with Conda.
>
> [1]:
> https://conda.io/docs/user-guide/tasks/build-packages/compiler-tools.html
> [2]: https://gist.github.com/smancill/b28ca07ac11fdf285b4d559545a1630b
>
> --
>
> First, when using the system compiler, all works fine (but I am not sure of
> the
> binary compatibility with the Conda packages, that's why I want to use the
> Anaconda compilers):
>
> # create the environment and install XercesC
> $ conda create -n test-system xerces-c
> ...
> environment location:
> /Users/smancill/.local/share/miniconda3/envs/test-system
> ...
> The following NEW packages will be INSTALLED:
>
> icu:   58.2-h4b95b61_1
> libcxx:4.0.1-h579ed51_0
> libcxxabi: 4.0.1-hebd6815_0
> xerces-c:  3.2.1-h44e365a_0
> ...
>
> # activate the environment
> $ conda activate test-system
>
> $ mkdir build-osx-system
> $ cd build-osx-system
> $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX
> -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
> -- The CXX compiler identification is AppleClang 9.0.0.939
> -- Check for working CXX compiler: /usr/bin/c++
> -- Check for working CXX compiler: /usr/bin/c++ -- works
> ...
> -- Found XercesC:
> /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libxerces-c.dylib
> (found version "3.2.1")
> -- Configuring done
> -- Generating done
> -- Build files have been written to:
> /Users/smancill/src/conda-test/build-osx-system
>
> $ make -j1 VERBOSE=1
> ...
> [100%] Linking CXX executable bar
> /usr/local/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt
> --verbose=1
> /usr/bin/c++   -isysroot
> /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk
> -mmacosx-version-min=10.12 -Wl,-search_paths_first
> -Wl,-headerpad_max_install_names  CMakeFiles/bar.dir/bar.cpp.o  -o bar
> 

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

[Ray Donnelly]

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
doesn't come with modern compilers patched to support things like c++17 on
CentOS6, they are also slow and to not mitigate against Spectre.

Our compilation story is very good. We use fully isolated pdeudo cross
compilers that both target and run on CentOS6 in Linux and our own builds
of clang on macOS. We repackage CentOS6 rpms into the compiler sysroot for
the few packages that link to system libs.

I like and use for docker but conda has its own story here and docker and
compiler technology are orthogonal in this regard. To t, I still use our
computers on docker.

I honestly believe the isolation fans sometimes go far to far though and
will accept a lot of unnecessary complication and overhead chasing this
goal. Sufficient isolation is possible in other ways.

For testing the packages though (on Linux targets) I love using docker. I
can make sure our conda packages work on all the OSes we support.

You can if you want use our compilers in docker but it's pretty pointless
(and routing conda package building thorough something like docker is a
requirement the community, conda forge in particular does not need).

I dream of a day when docker is seen as one great tool with lots of useful
applications instead of the solution to everything but I don't see it
coming anytime soon.

On Aug 15, 2018 9:29 AM, "Eric Noulard"  wrote:



Le mar. 14 août 2018 à 20:38, Sebastián Mancilla  a
écrit :

> I wanted to try Conda for normal day-to-day C++ development, while having
> all the dependencies isolated from other projects and the base system.
>
> - Change the sources
> - Build
> - Run the tests
> - Repeat
>

Hi Sebastian,

Just curious on why you would prefer conda over "real" container technology
like docker or rkt for the kind of usage you describe ?
Do you ultimately want to distribute your software as conda packages?

I'm not proficient in conda but AFAIK docker (or rkt) offers easier/better
isolation for the usage you describe.
The side-effect being that inside your container cmake should behave like
as expected.
At least this is my own experience.

Some people even try to automatize the container creation out of conda
packaged software:
https://github.com/BioContainers/mulled
I have no experience with that whatsoever, I usually craft my own
dockerfile and work with that.

If your goal includes the distrubution of your software as conda package
may be you can get in touch with people
at conda-forge: https://conda-forge.org/#about, I bet they build a lot of
cmake-based projects in there and may
have experienced same caveats with the conda compilers usage.


-- 
Eric
-- 

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

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

[Ray Donnelly]

Why are you not using conda-build here? Anaconda Distro and
conda-forge build countless CMake projects. It handles so much extra
stuff on top of building (DSO verification, rpath rewriting, more). If
your end goal is not conda packages then you can untar most sets of
conda-packages to make working software installations (caveat for most
being that some software requires what we call 'prefix replacament'
and those aren't trivially relocatable).

IMHO CMake's handling of RPATHs is broken, as per my "determine
implicit linker directories" PR which there seems to be little to no
interest in instead preferring toolchain cmake files for something
that *clearly* should be queried from the link as it is imperative
when building software that CMake and the toolchain agree on things as
fundamental as this.

RPATH is never set by a toolchain except through being passed to it
(by CMake's logic, fixed by
https://gitlab.kitware.com/cmake/cmake/merge_requests/207).

I would again request that this pretty trivial, obvious and important
PR gets some consideration. Without it CMake asks anyone trying to
build a software distro with more than simple system prefix-based
compilation will run into needing this fix or needing to provide a
toolchain just to tell CMake what it should figure out for itself.

On Tue, Aug 14, 2018 at 2:12 AM, Sebastián Mancilla  wrote:
> Thanks for the links.
>
> The problem of setting CMAKE_BUILD_RPATH to $CONDA_PREFIX/lib is that
> for binaries and libraries in the build tree, the list of RPATH
> locations will be in the wrong order: the dependencies library path
> will be first, and then the build tree. This will break the unit tests
> if the library was installed previously (for example, to check the
> library by running other installed programs), and then modified as
> part of normal development, because the installed version will be
> loaded instead of the version in the build tree. CMake supports this
> use case out of the box and it works great (when not using Anaconda).
>
> Note that in Linux the $CONDA_PREFIX/lib seems to be added to the
> RPATH by the Anaconda toolchain itself, and it will appear first, so
> there is nothing that can be done about that with CMake.
>
> It seems that the workarounds when using Anaconda compilers, and doing
> development, are:
>
> - Always install before unit testing changes to the library being
> developed (and set CMAKE_BUILD_RPATH).
> - Never install the library (so the build tree not being first in the
> RPATH is not an issue, and set CMAKE_BUILD_RPATH), create a different
> environment to test installation.
> - Don't use the build RPATH and set the proper environment variables
> ([DY]LD_LIBRARY_PATH) with the right path order when running from the
> build tree.
> - Manipulate the RPATH manually (with patchelf or similar).
> - Don't use Anaconda compilers (will there be binary issues with
> Anaconda dependencies?)
>
> But they are not ideal.
>
>
> If the Conda environment is not being used for development and someone
> wants to just build and use some binary/library, setting
> CMAKE_INSTALL_RPATH to $CONDA_PREFIX/lib and then installing will work
> fine. And it looks 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_requests/207
>>
>>
>> https://gitlab.kitware.com/cmake/cmake/issues/17483 (looks semi-related)
>>
>> Ray Donnelly, who filed those issues, maintains the Anaconda compiler 
>> toolchain -- so you are in good company hitting this issue. It looks like 
>> some conda recipes explicitly define INSTALL_RPATH, likely for this reason:
>>
>> https://github.com/AnacondaRecipes/vtk-feedstock/blob/791a1db9026fa2c81d171c38835b512adf221794/recipe/build.sh#L30
>>
>>
>>
>> On Mon, Aug 13, 2018 at 11:54 AM Isaiah Norton  
>> wrote:
>>>
>>> The RPATH is not included when using Anaconda because CMake considers the 
>>> Anaconda lib path to be an implicit link directory (as reported by the 
>>> compiler). Look at `$build_dir/CMakeFiles/CMakeOutput.log` in the section 
>>> about "implicit link info".
>>>
>>> The simplest work-around is to set BUILD_RPATH manually, and possibly also 
>>> INSTALL_RPATH, depending on what conda-build's fixup routine expects.
>>>
>>> For example, adding this line near the top of your example CMakeList fixed 
>>> the resulting binary, at least in the build directory:
>>>
>>> set(CMAKE_BUILD_RPATH "$ENV{CONDA_PREFIX}/lib")
>>>
>>>
>>>

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

[Ray Donnelly]

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 really
>>> authoritative answer.
>>>
>>> Say I have a simple single-library project.
>>>
>>> The advise I've seen is to not pass SHARED or STATIC to the
>>> add_library(..), but instead let the user pass
>>> -DBUILD_SHARED_LIBS:BOOL=ON/OFF to build the library as either shared
>>> or static.
>>>
>>> That's fine, but leads to packagers having to do ugly things like e.g:
>>>
>>> https://salsa.debian.org/hle/dlib/blob/master/debian/rules
>>>
>>> That is, do two separate configure/build/install, in order to get both
>>> a shared and static version.
>>
>> IMHO, there is nothing ugly in this approach.
>> Not every system allows (or recomments) to generate both,
>> static and shared, from the same object files.
>
> Alright. Yes I'm probably personally leaning towards just using the
> recommended way, with a single add_library(..) and demand
> reconfigure/rebuild/reinstall to get both variants. I was mostly
> curious if you CMake pros on this list had some neat solution I hadn't
> seen before.
>
> Note that I wasn't necessarily suggesting building shared + static
> from the same set of object files (which is indeed not recommended,
> e.g. think of -fPIC),

Static libraries should be compiled with -fPIC on all systems that
support -fPIC. The reason for this is that you should not make
assumptions about the final target of the static library. There is no
reason it should be excluded from being linked into a shared library
or a ASLR capable executable. On Anaconda Distribution, everything is
compiled with -fPIC on Linux for this reason, and on macOS, -fPIC is
the only option and Windows has always been PIC or at least for as
long as I can remember.

but just looking for best practices when having
> CMake do the build of both libraries as part of the same build.
>
> Elvis
>
>> Why not view static vs shared as the similar to 32 vs 64 bit?
>>
>> 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
> --
>
> 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
-- 

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

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

[Ray Donnelly]

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 Stansvik <elvis.stans...@orexplore.com>
> wrote:
> >> > I know this has been asked before, but I've never seen a really
> >> > authoritative answer.
> >> >
> >> > Say I have a simple single-library project.
> >> >
> >> > The advise I've seen is to not pass SHARED or STATIC to the
> >> > add_library(..), but instead let the user pass
> >> > -DBUILD_SHARED_LIBS:BOOL=ON/OFF to build the library as either shared
> >> > or static.
> >> >
> >> > That's fine, but leads to packagers having to do ugly things like e.g:
> >> >
> >> > https://salsa.debian.org/hle/dlib/blob/master/debian/rules
> >> >
> >> > That is, do two separate configure/build/install, in order to get both
> >> > a shared and static version.
> >>
> >> IMHO, there is nothing ugly in this approach.
> >> Not every system allows (or recomments) to generate both,
> >> static and shared, from the same object files.
> >> Why not view static vs shared as the similar to 32 vs 64 bit?
> >
> >
> > Because they are different architectures that in many cases require
> > different compilers and in some cases different host machines to run on.
> > Static vs shared has none of these issues to contend with.
>
> Both, static and shared may use quite different compilation/linking,
> that is enough to treat them differently.
> Apparently, my point hasn't made it through. Nevermind.
>

Yes of course they do but the tooling in and around cmake (including things
like pkg-config and libtool) support this already. All I am pushing for is
for parity between the main 3 OSes here so that users of cmake do not have
to implement ugly hacks purely due to this.

>
> 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

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

[Ray Donnelly]

It most definitely is not. I work on a cross platform software distro that
includes many hundreds on libraries. There are 3 competing standards (4 if
you include mingw-w64):

lib prefix: ugly when the lib is already prefixed with lib.
-static.lib suffix.
.dll.lib vs .lib.

The point is cmake has defaults for this and they work on other platforms,
instead on Windows it ignores this and leaves the entire software
development would to deal with it instead.


On Sat, May 19, 2018, 8:43 PM Shoaib Meenai <smee...@fb.com> wrote:

> The convention in MSVC-land seems to be to prefix (as well as suffix)
> static libraries with lib. E.g. the static CRT is libcmt.lib, the static VC
> runtime support library is libvcruntime.lib (whereas the import library for
> the dynamic equivalent is vcruntime.lib), and so on. It isn't necessarily
> the greatest scheme, but it does provide 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 <cmake@cmake.org>
> *Subject: *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
> lead on creating this new standard here, in cooperation and discussion with
> Microsoft (though for pure cmake based things it can be done without that).
> .dll.lib vs .lib being the obvious extensions here.
>
>
>
> FWIW mingw-w64 fixed this, and it was far from difficult. Here we use
> .dll.a and .a.
>
>
>
> I appeal to the CMake moderators to consider the damage this situation
> causes to the genericness and hygiene of CMakeList.txt files.
>
>
>
> On Sat, May 19, 2018, 2:00 PM Elvis Stansvik <elvis.stans...@orexplore.com>
> wrote:
>
> I know this has been asked before, but I've never seen a really
> authoritative answer.
>
> Say I have a simple single-library project.
>
> The advise I've seen is to not pass SHARED or STATIC to the
> add_library(..), but instead let the user pass
> -DBUILD_SHARED_LIBS:BOOL=ON/OFF to build the library as either shared
> or static.
>
> That's fine, but leads to packagers having to do ugly things like e.g:
>
> https://salsa.debian.org/hle/dlib/blob/master/debian/rules
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__salsa.debian.org_hle_dlib_blob_master_debian_rules=DwMFaQ=5VD0RTtNlTh3ycd41b3MUw=o3kDXzdBUE3ljQXKeTWOMw=bmBNxLvBJFPYO0Kd1_VsRIXq2zQXfPQBW72q5lBMPlo=R7JQmKVI2oxy-AIQVcBC-DX-dqlkBFk5kTCI222ecO8=>
>
> That is, do two separate configure/build/install, in order to get both
> a shared and static version. Note that the above was just an example.
> But many packagers do it like this.
>
> How can I make life easier for the packager?
>
> I could add a -DFOO_BUILD_SHARED_AND_STATIC_LIBS, and use two
> add_library(...), one with SHARED and one with STATIC, but the same
> input source files. I could give the two libraries different output
> filenames, as to not conflict on e.g. Windows (where I think the .lib
> import library containing symbols for the .dll would otherwise
> conflict with the static library .lib, or..?).
>
> To not have to repeat the list of sources, I could keep them in a
> variable. But that's not recommended in modern CMake AFAIK.
>
> I've also seen people add an object library, and then build the shared
> + static lib from that.
>
> What are your thoughts on all this? How do you go about it? Do you use
> the recommended way, with a single add_library(..) and just let
> packagers put up with having to do two builds?
>
> Thanks in advance!
> Elvis
> --
>
> Powered by www.kitware.com
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kitware.com=DwMFaQ=5VD0RTtNlTh3ycd41b3MUw=o3kDXzdBUE3ljQXKeTWOMw=bmBNxLvBJFPYO0Kd1_VsRIXq2zQXfPQBW72q5lBMPlo=V3mYr9Flf9Qf-Pq-_OovKbzrwVWhpIOrjcCHuYvbszk=>
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.cmake.org_Wiki_CMake-5FFAQ=DwMFaQ=5VD0RTtNlTh3ycd41b3MUw=o3kDXzdBUE3ljQXKeTWOMw=bmBNxLvBJFPYO0Kd1_VsRIXq2zQXfPQBW72q5lBMPlo=sX26SQZVFYfGdhl4S0nVhXQDQ6eq_MhGXOy06ZAW9KQ=>
>
> 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
> 

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

[Ray Donnelly]

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 project.
> >
> > The advise I've seen is to not pass SHARED or STATIC to the
> > add_library(..), but instead let the user pass
> > -DBUILD_SHARED_LIBS:BOOL=ON/OFF to build the library as either shared
> > or static.
> >
> > That's fine, but leads to packagers having to do ugly things like e.g:
> >
> > https://salsa.debian.org/hle/dlib/blob/master/debian/rules
> >
> > That is, do two separate configure/build/install, in order to get both
> > a shared and static version.
>
> IMHO, there is nothing ugly in this approach.
> Not every system allows (or recomments) to generate both,
> static and shared, from the same object files.
> Why not view static vs shared as the similar to 32 vs 64 bit?
>

Because they are different architectures that in many cases require
different compilers and in some cases different host machines to run on.
Static vs shared has none of these issues to contend with.

>
> 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
>
-- 

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

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

[Ray Donnelly]

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
lead on creating this new standard here, in cooperation and discussion with
Microsoft (though for pure cmake based things it can be done without that).
.dll.lib vs .lib being the obvious extensions here.

FWIW mingw-w64 fixed this, and it was far from difficult. Here we use
.dll.a and .a.

I appeal to the CMake moderators to consider the damage this situation
causes to the genericness and hygiene of CMakeList.txt files.

On Sat, May 19, 2018, 2:00 PM 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 project.
>
> The advise I've seen is to not pass SHARED or STATIC to the
> add_library(..), but instead let the user pass
> -DBUILD_SHARED_LIBS:BOOL=ON/OFF to build the library as either shared
> or static.
>
> That's fine, but leads to packagers having to do ugly things like e.g:
>
> https://salsa.debian.org/hle/dlib/blob/master/debian/rules
>
> That is, do two separate configure/build/install, in order to get both
> a shared and static version. Note that the above was just an example.
> But many packagers do it like this.
>
> How can I make life easier for the packager?
>
> I could add a -DFOO_BUILD_SHARED_AND_STATIC_LIBS, and use two
> add_library(...), one with SHARED and one with STATIC, but the same
> input source files. I could give the two libraries different output
> filenames, as to not conflict on e.g. Windows (where I think the .lib
> import library containing symbols for the .dll would otherwise
> conflict with the static library .lib, or..?).
>
> To not have to repeat the list of sources, I could keep them in a
> variable. But that's not recommended in modern CMake AFAIK.
>
> I've also seen people add an object library, and then build the shared
> + static lib from that.
>
> What are your thoughts on all this? How do you go about it? Do you use
> the recommended way, with a single add_library(..) and just let
> packagers put up with having to do two builds?
>
> Thanks in advance!
> Elvis
> --
>
> 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
>
-- 

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

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

[Ray Donnelly]

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 Emmenlauer 
> wrote:
> >
> >
> > I've googled this issue for a while now but found only few
> > references (1,2) and no solution. I'd like to enforce that
> > find_package() will only accept static or shared libraries.
> > I would then set this option based on BUILD_SHARED_LIBS=(ON|OFF).
> >
> > I.e. I'd love to have something like:
> >if(BUILD_SHARED_LIBS)
> >BUILD_TYPE="SHARED"
> >else()
> >BUILD_TYPE="STATIC"
> >endif()
> >find_package(XXX ${BUILD_TYPE})
> >find_package(YYY ${BUILD_TYPE})
> >find_package(ZZZ ${BUILD_TYPE})
> >...
> >
> >
> > It seems that this does not exist? I could also not find a
> > good workaround. The best I can find is to use 'NAMES' and
> > add the static or shared library names manually.
> >
> > This is not very suitable, because I have a project with more
> > than 30 dependencies. The project should either build (fully)
> > static or (fully) shared. I can not easily maintain lists of
> > 30 static and shared library names on several platforms.
> >
> > Is there a solution or good workaround?
> >
> > All the best,
> >
> >Mario Emmenlauer
> >
> >
> > (1) https://cmake.org/pipermail/cmake/2012-September/052059.html
> > (2) https://cmake.org/pipermail/cmake/2010-December/041326.html
> >
> >
> > --
> > BioDataAnalysis GmbH, Mario Emmenlauer  Tel. Buero: +49-89-74677203
> > Balanstr. 43   mailto: memmenlauer * biodataanalysis.de
> > D-81669 München  http://www.biodataanalysis.de/
> > --
> >
> > 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
>
> --
>
> 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
>
-- 

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

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

[Ray Donnelly]

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 up a clear explanation yet.
>
> IIUC your case is the opposite of that under discussion in the rest
> of this thread.  You want to include a rpath that is not currently
> included.  Jörg wants to exclude a rpath that is currently being
> incorrectly included.  The detection you're proposing would not
> discover the lib32 entry that is causing Jörg's problem.
>

Not really, my PR is about ensuring that CMake's idea of implicit dirs
isn't mismatched with the linker's actual implicit dirs by actually
asking the linker. AFAICT, it fixes Jörg's problem too. I say that
because as stated:

> CMake passes the host rpath to the linker

CMake does this because it isn't *asking* the linker, it's making
assumptions instead (and adding some predefined values like
`/usr/lib32`). If we just ask the linker instead then everything
should work just fine (I am ignore linkers that cannot tell us here
like Apple's ld64. I'm not sure how to tackle that one yet).

> As I requested in your MR [1] it will be more appropriate to discuss
> your rpath-inclusion use case in a separate issue.
>
> Thanks,
> -Brad
>
> [1] https://gitlab.kitware.com/cmake/cmake/merge_requests/207#note_189880
>
-- 

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

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

[Ray Donnelly]

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 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.
>> > >
>> > > Do you have a link to the PR?
>> >
>> > The PR Is closed pending me writing a test-case, but I just now
>> > updated to the my latest version and rebased on top of master:
>>
>> The MR was:
>>
>>  https://gitlab.kitware.com/cmake/cmake/merge_requests/207
>>
>> See discussion there for why it has not yet been accepted.  Basically
>> I'd like to see a clear explanation of the use case.  The case
>> described
>> in the MR looks to me like the custom compiler should be configured
>> to
>> always pass the needed rpath flags to the linker.
>>
>> On 02/06/2017 06:16 PM, Jörg Krause wrote:
>> > I did a git bisect. The behaviour was introduced in commit
>> > 896ad251de49f167f4ce3cbbcf9a6cce85a16681 [1].
>>
>> Thanks for the bisect.  I don't think there is anything wrong with
>> that
>> change on its own.  It merely exposed some existing behavior in a new
>> case.
>
> The problem is, that we end up with a host rpath when cross-compiling
> which breaks compilations for a number of CMake packages we build on
> Buildroot.

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 up a clear explanation yet.

>
> Buildroot uses /sysroot/usr/lib as target library path and
> /sysroot/usr/lib32 is a symlink to that path. Nothing wrong here.
>
> The addition of FIND_LIBRARY_USE_LIB32_PATHS changes the behavior of
> `find_library()`. Before the commit `/sysroot/usr/lib` was
> found as library path, but now it's `/sysroot/usr/lib32`.
>
> When determining the runtime search path, CMake compares the paths
> found by `find_library()` with a list of implicit runtime pathes. This
> list contains `/sysroot/usr/lib` but not `/sysroot/usr/lib32`.
>
> If the library path found by `find_library()` matches a search path
> from the list of implicit runtime pathes it is dropped, otherwise it is
> added to rpath after removing the `/sysroot` path.
>
> So, as the implicit runtime search paths does *not* contain
> `/sysroot/usr/lib32`, find_library() ends up with a rpath set to
> `/usr/lib32`.
>
>
>
> One example of how cross-compilation is broken is the example I already
> quoted:
>
> """
> $SYSROOT/usr/bin/i586-linux-gcc --sysroot=$SYSROOT/usr/i586-buildroot-
> linux-musl/sysroot CheckSymbolExists.c.o -o cmTC_cb8f6 -Wl,-
> rpath,/usr/lib32 -rdynamic $SYSROOT/usr/i586-buildroot-linux-
> musl/sysroot/usr/lib32/libmbedtls.so
> """
>
> If libmbedtls is linked with libz, the linker tries to link the target
> libmbedtls with host libz, which fails:
>
> """
> $SYSROOT/usr/i586-buildroot-linux-musl/bin/ld: warning:
> libc.so.6, needed by /usr/lib32/libz.so.1, not found (try using -rpath
> or -rpath-link)
> /usr/lib32/libz.so.1: undefined reference to `strcpy@GLIBC_2.0'
> /usr/lib32/libz.so.1: undefined reference to `free@GLIBC_2.0'
> /usr/lib32/libz.so.1: undefined reference to `fseeko64@GLIBC_2.1
> """
>
> Note, that Buildroot does not use a /sysroot/usr/lib64 symbolic link.
> Therefore, this behavior was not exposed before the commit.
>
> For me, it looks like there is a problem how the rpath is created when
> cross-compiling. Maybe the logic should check, if /sysroot/usr/lib32 is
> a symlink to an implicit runtime search path?
>
> However, I am not very familiar with CMake and the insights I described
> where gathered by some hours of debugging the CMake code. Maybe I
> missed something?
>
>> > My suggestion is to set FIND_LIBRARY_USE_LIB32_PATHS and
>> > FIND_LIBRARY_USE_LIB64_PATHS to FALSE when cross-compiling on
>> > Linux.
>>
>> These are set on by default in `Modules/Platform/UnixPaths.cmake` but
>> disabled on Debian by `Modules/Platform/Linux.cmake` except when
>> cross compiling.  If a toolchain file specifies CMAKE_SYSTEM_NAME
>> such that a custom `Platform/MySystem.cmake` file is loaded then
>> the latter can set them as needed for the target platform.
>
> Thanks for the hint. We are discussin

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

[Ray Donnelly]

The PR Is closed pending me writing a test-case, but I just now
updated to the my latest version and rebased on top of master:

https://gitlab.kitware.com/mingwandroid/cmake/commit/b937ff949d8fdaab7d8b812d503f67f8cef69532


Cheers.


On Tue, Feb 7, 2017 at 8:37 AM,  <joerg.krause@embedded.rocks> 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
>> it unfortunately.
>
>
> Do you have a link to the PR?
>
>> On Feb 6, 2017 11:16 PM, "Jörg Krause" <joerg.krause@embedded.rocks>
>> wrote:
>>
>>> On Mon, 2017-02-06 at 22:22 +0100, Jörg Krause wrote:
>>>>
>>>> Hi,
>>>>
>>>> On Sun, 2017-02-05 at 23:03 +0100, Jörg Krause wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> when using CHECK_{SYMBOL,FUNCTION}_EXISTS in a cross-compilation
>>>>> environment, CMake passes the host rpath to the linker:
>>>>>
>>>>> """ CMakeOutput.log
>>>>>
>>>>> /home/joerg/host/usr/bin/i586-linux-gcc
>>>>> --sysroot=/home/joerg/host/usr/i586-buildroot-linux-musl/sysroot
>>>>> -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
>>>>> -Os -
>>>>> DNDEBUG CMakeFiles/cmTC_cb8f6.dir/CheckSymbolExists.c.o -o
>>>>> cmTC_cb8f6 -Wl,-rpath,/usr/lib32 -rdynamic
>>>>> /home/joerg/host/usr/i586-
>>>>> buildroot-linux-musl/sysroot/usr/lib32/libmbedtls.so
>>>>> /home/joerg/host/usr/i586-buildroot-linux-
>>>>> musl/sysroot/usr/lib32/libmbedx509.so /home/joerg/host/usr/i586-
>>>>> buildroot-linux-musl/sysroot/usr/lib32/libmbedcrypto.so
>>>>>
>>>>> """
>>>>>
>>>>> This leads to a linker error if mbedtls is linked with zlib, as
>>>
>>> the
>>>>>
>>>>> linker tries to link with the host zlib and does not find the
>>>
>>> host
>>>>>
>>>>> libc:
>>>>>
>>>>> """ CMakeError.txt
>>>>>
>>>>> /home/joerg/host/usr/i586-buildroot-linux-musl/bin/ld: warning:
>>>>> libc.so.6, needed by /usr/lib32/libz.so.1, not found (try using
>>>>> -rpath
>>>>> or -rpath-link)
>>>>> /usr/lib32/libz.so.1: undefined reference to `strcpy@GLIBC_2.0'
>>>>> /usr/lib32/libz.so.1: undefined reference to `free@GLIBC_2.0'
>>>>> /usr/lib32/libz.so.1: undefined reference to `fseeko64@GLIBC_2.1
>>>>> [..]
>>>>>
>>>>> """
>>>>>
>>>>> I did not find any solution which allows me to remove the rpath
>>>>> from
>>>>> the check. Setting CMAKE_SKIP_RPATH does not change the build
>>>>> behaviour of the check_symbol_exists macro.
>>>>>
>>>>> From my understanding, the rpath flag should not be used when
>>>
>>> the
>>>>>
>>>>> sysroot flag is passed to the linker, right?
>>>>>
>>>>> For reference, I added a minimal example which uses Buildroot
>>>
>>> for
>>>>>
>>>>> cross-compilation.
>>>>>
>>>>> """ CMakeLists.txt
>>>>>
>>>>> cmake_minimum_required(VERSION 2.8.12)
>>>>>
>>>>> project(test)
>>>>>
>>>>> list(APPEND CMAKE_MODULE_PATH
>>>
>>> "${CMAKE_CURRENT_SOURCE_DIR}/cmake")
>>>>>
>>>>>
>>>>> find_package(MbedTLS)
>>>>> if(MBEDTLS_FOUND)
>>>>> message(STATUS "Using mbedTLS")
>>>>> endif()
>>>>>
>>>>> """
>>>>>
>>>>> """ FindMbedTLS.cmake
>>>>>
>>>>> include(CheckSymbolExists)
>>>>>
>>>>> find_path(MBEDTLS_INCLUDE_DIRS
>>>>> NAMES mbedtls/ssl.h
>>>>> PATH_SUFFIXES include
>>>>> )
>>>>>
>>>>> find_library(MBEDTLS_LIBRARY NAMES mbedtls)
>>>>> find_library(MBEDX509_LIBRARY NAMES mbedx509)
>>>>> find_library(MBEDCRYPTO_LIBRARY NAMES mbedcrypto)

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

[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 it
unfortunately.

On Feb 6, 2017 11:16 PM, "Jörg Krause"  wrote:

> On Mon, 2017-02-06 at 22:22 +0100, Jörg Krause wrote:
> > Hi,
> >
> > On Sun, 2017-02-05 at 23:03 +0100, Jörg Krause wrote:
> > > Hi,
> > >
> > > when using CHECK_{SYMBOL,FUNCTION}_EXISTS in a cross-compilation
> > > environment, CMake passes the host rpath to the linker:
> > >
> > > """ CMakeOutput.log
> > >
> > > /home/joerg/host/usr/bin/i586-linux-gcc
> > > --sysroot=/home/joerg/host/usr/i586-buildroot-linux-musl/sysroot
> > > -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
> > > -Os   -
> > > DNDEBUGCMakeFiles/cmTC_cb8f6.dir/CheckSymbolExists.c.o  -o
> > > cmTC_cb8f6 -Wl,-rpath,/usr/lib32 -rdynamic
> > > /home/joerg/host/usr/i586-
> > > buildroot-linux-musl/sysroot/usr/lib32/libmbedtls.so
> > > /home/joerg/host/usr/i586-buildroot-linux-
> > > musl/sysroot/usr/lib32/libmbedx509.so /home/joerg/host/usr/i586-
> > > buildroot-linux-musl/sysroot/usr/lib32/libmbedcrypto.so
> > >
> > > """
> > >
> > > This leads to a linker error if mbedtls is linked with zlib, as the
> > > linker tries to link with the host zlib and does not find the host
> > > libc:
> > >
> > > """ CMakeError.txt
> > >
> > > /home/joerg/host/usr/i586-buildroot-linux-musl/bin/ld: warning:
> > > libc.so.6, needed by /usr/lib32/libz.so.1, not found (try using
> > > -rpath
> > > or -rpath-link)
> > > /usr/lib32/libz.so.1: undefined reference to `strcpy@GLIBC_2.0'
> > > /usr/lib32/libz.so.1: undefined reference to `free@GLIBC_2.0'
> > > /usr/lib32/libz.so.1: undefined reference to `fseeko64@GLIBC_2.1
> > > [..]
> > >
> > > """
> > >
> > > I did not find any solution which allows me to remove the rpath
> > > from
> > > the check. Setting CMAKE_SKIP_RPATH does not change the build
> > > behaviour of the check_symbol_exists macro.
> > >
> > > From my understanding, the rpath flag should not be used when the
> > > sysroot flag is passed to the linker, right?
> > >
> > > For reference, I added a minimal example which uses Buildroot for
> > > cross-compilation.
> > >
> > > """ CMakeLists.txt
> > >
> > > cmake_minimum_required(VERSION 2.8.12)
> > >
> > > project(test)
> > >
> > > list(APPEND CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cmake")
> > >
> > > find_package(MbedTLS)
> > > if(MBEDTLS_FOUND)
> > > message(STATUS "Using mbedTLS")
> > > endif()
> > >
> > > """
> > >
> > > """ FindMbedTLS.cmake
> > >
> > > include(CheckSymbolExists)
> > >
> > > find_path(MBEDTLS_INCLUDE_DIRS
> > > NAMES mbedtls/ssl.h
> > > PATH_SUFFIXES include
> > > )
> > >
> > > find_library(MBEDTLS_LIBRARY NAMES mbedtls)
> > > find_library(MBEDX509_LIBRARY NAMES mbedx509)
> > > find_library(MBEDCRYPTO_LIBRARY NAMES mbedcrypto)
> > >
> > > if(MBEDTLS_LIBRARY AND MBEDX509_LIBRARY AND MBEDCRYPTO_LIBRARY)
> > > set(CMAKE_REQUIRED_INCLUDES ${MBEDTLS_INCLUDE_DIRS})
> > > set(CMAKE_REQUIRED_LIBRARIES ${MBEDTLS_LIBRARY}
> > > ${MBEDX509_LIBRARY} ${MBEDCRYPTO_LIBRARY})
> > > check_symbol_exists(mbedtls_ssl_init "mbedtls/ssl.h"
> > > MBEDTLS_V2)
> > > endif()
> > >
> > > """
> > >
> > > """ toolchainfile.cmake
> > >
> > > string(REPLACE "/usr/share/buildroot" "" RELOCATED_HOST_DIR
> > > ${CMAKE_CURRENT_LIST_DIR})
> > >
> > > set(CMAKE_SYSTEM_NAME Linux)
> > > set(CMAKE_SYSTEM_PROCESSOR i586)
> > >
> > > set(CMAKE_C_FLAGS_DEBUG "" CACHE STRING "Debug CFLAGS")
> > > set(CMAKE_CXX_FLAGS_DEBUG "" CACHE STRING "Debug CXXFLAGS")
> > > set(CMAKE_C_FLAGS_RELEASE " -DNDEBUG" CACHE STRING "Release
> > > CFLAGS")
> > > set(CMAKE_CXX_FLAGS_RELEASE " -DNDEBUG" CACHE STRING "Release
> > > CXXFLAGS")
> > >
> > > # Build type from the Buildroot configuration
> > > set(CMAKE_BUILD_TYPE Release CACHE STRING "Buildroot build
> > > configuration")
> > >
> > > # Buildroot defaults flags.
> > > set(CMAKE_C_FLAGS "-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
> > > -D_FILE_OFFSET_BITS=64 -Os" CACHE STRING "Buildroot CFLAGS")
> > > set(CMAKE_CXX_FLAGS "-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
> > > -D_FILE_OFFSET_BITS=64 -Os" CACHE STRING "Buildroot CXXFLAGS")
> > > set(CMAKE_EXE_LINKER_FLAGS "" CACHE STRING "Buildroot LDFLAGS for
> > > executables")
> > >
> > > set(CMAKE_INSTALL_SO_NO_EXE 0)
> > >
> > > set(CMAKE_PROGRAM_PATH "${RELOCATED_HOST_DIR}/usr/bin")
> > > set(CMAKE_SYSROOT "${RELOCATED_HOST_DIR}/usr/i586-buildroot-linux-
> > > musl/sysroot")
> > > set(CMAKE_FIND_ROOT_PATH "${RELOCATED_HOST_DIR}/usr/i586-buildroot-
> > > linux-musl/sysroot")
> > > set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
> > > set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
> > > set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
> > > set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
> > > set(ENV{PKG_CONFIG_SYSROOT_DIR} "${RELOCATED_HOST_DIR}/usr/i586-
> > > buildroot-linux-musl/sysroot")
> > >
> > > # This toolchain file can be used 

Re: [CMake] NO_SYSTEM_ENVIRONMENT_PATH globally?

[Ray Donnelly]

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 local patches, they're
>> fairly minor, except the qt5-static one, and I don't think they are
>> likely related to this:
>> https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-cmake)
>>
>> MSYS2 has two shells .. actually it's 3 or 4, but for simplicity we'll
>> ignore the 32-bit ones and pretend there's only 2 64-bit shells, one
>> launched with msys2_shell.bat and one launched with mingw64_shell.bat.
>> Under msys2_shell.bat, the "/mingw64/bin" folder doesn't appear at all
>> in PATH, while under mingw64_shell.bat, it appears at the very front,
>> before "/usr/bin" (which contains the msys2 software).
>>
>> When running CMake to configure the build for libclang, it tries to
>> see if if can find libdl with "find_library (DL_LIBRARY_PATH dl)".
>> Unfortunately it finds the msys-2.0.dll-linked libdl.a in /usr/lib
>> because NO_SYSTEM_ENVIRONMENT_PATH isn't set, which isn't then in
>> /mingw64/bin/g++.exe's linker search path (and even if it was, we
>> don't want to link msys-2.0.dll software into native software!).
>
>
> Hi Ray:
>
> I only have indirect experience with MinGW-w64/MSYS2 (i.e., reading detailed
> build reports from a tester of PLplot on that platform), but my
> understanding is
> to build software for that platform you would normally
> always use mingw64_shell.bat (or mingw32_shell.bat for the 32-bit
> case).  And if /mingw64/bin is first on the PATH for that shell my
> understanding is that if libdl is in the correct location in /mingw64,
> then it should normally and automatically be found by CMake for
> /mingw64/bin/g++.exe when NO_SYSTEM_ENVIRONMENT_PATH is not set.

Hi Alan,

I'm one of the founders of MSYS2 (not that that means I know what I'm
talking about mind you!) .. You are right, that normally for building
mingw-w64 x86_64 software on MSYS2 you'd use mingw64_shell.bat, but
when building MSYS2 packages via makepkg-mingw, you'd run
msys2_shell.bat instead since that builds both the 32-bit and 64-bit
variants setting the correct environment up beforehand each time.

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 msys2, so
there'll never be a /mingw{64,32}/lib/libdl.a or
/mingw{64,32}/lib/libdl.dll.a, but there is a /usr/lib/libdl.a. When
building mingw-w64 software, the front of PATH will be
"/mingw64/bin:/usr/bin" or "/mingw32/bin:/usr/bin" and that causes
CMake to find /usr/lib/libdl.a due to NO_SYSTEM_ENVIRONMENT_PATH.

I think the best I can do is to edit each of our CMake using PKGBUILD
scripts to set PATH to a clean value just before invoking CMake. This
is something I didn't really want to have to do.

To my mind, this rummaging around the user's system path feature seems
too prone to randomness and a large source of build variance. Some of
this comes from my liking for reproducible builds where environmental
differences are kept out of the equation.

>
> However, it appears that is not the find result you are getting and
> you have responded by trying to find a way to set
> NO_SYSTEM_ENVIRONMENT_PATH globally.  But I think it would be better
> instead to explore the case where the NO_SYSTEM_ENVIRONMENT_PATH
> command is not used to figure out how to get that scenario to
> correctly find libdl.
>
> Therefore, I suggest you make a simple test
> project which uses "find_library (DL_LIBRARY_PATH dl)" (without
> NO_SYSTEM_ENVIRONMENT_PATH) to find dl, and fiddle with your PATH (and
> also CMake version just in case it turns out you are fighting against
> some recently introduced find_library regression) to see what the
> results are.  And if nothing works for any cmake version with
> /mingw64/bin at the very front of your PATH, then you can always fall
> back to setting the -DCMAKE_LIBRARY_PATH:PATH cmake option to force
> finding the correct version of libdl.
>
> Note in your tests above you might also want to try both the "Unix
> Makefiles" and "MSYS Makefiles" generators.  Our PLplot experience is
> that choice does make a difference for one find module (wxwidgets) on
> MinGW-w64/MSYS2, and I suppose it is possible it might also make a
> difference to the results from a single find_library command as well.
>

"MSYS Makefiles" should be the correct choice on MSYS2 if you are
compiling with native compilers. If you are using cross compilers then
"Unix makefiles" should be the correct choice

Re: [CMake] NO_SYSTEM_ENVIRONMENT_PATH globally?

[Ray Donnelly]

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 ran into a problem on MSYS2 recently building llvm+clang for
>>> mingw-w64 using CMake 3.4.1 (we carry a few local patches, they're
>>> fairly minor, except the qt5-static one, and I don't think they are
>>> likely related to this:
>>> https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-cmake)
>>>
>>> MSYS2 has two shells .. actually it's 3 or 4, but for simplicity we'll
>>> ignore the 32-bit ones and pretend there's only 2 64-bit shells, one
>>> launched with msys2_shell.bat and one launched with mingw64_shell.bat.
>>> Under msys2_shell.bat, the "/mingw64/bin" folder doesn't appear at all
>>> in PATH, while under mingw64_shell.bat, it appears at the very front,
>>> before "/usr/bin" (which contains the msys2 software).
>>>
>>> When running CMake to configure the build for libclang, it tries to
>>> see if if can find libdl with "find_library (DL_LIBRARY_PATH dl)".
>>> Unfortunately it finds the msys-2.0.dll-linked libdl.a in /usr/lib
>>> because NO_SYSTEM_ENVIRONMENT_PATH isn't set, which isn't then in
>>> /mingw64/bin/g++.exe's linker search path (and even if it was, we
>>> don't want to link msys-2.0.dll software into native software!).
>>
>>
>> Hi Ray:
>>
>> I only have indirect experience with MinGW-w64/MSYS2 (i.e., reading detailed
>> build reports from a tester of PLplot on that platform), but my
>> understanding is
>> to build software for that platform you would normally
>> always use mingw64_shell.bat (or mingw32_shell.bat for the 32-bit
>> case).  And if /mingw64/bin is first on the PATH for that shell my
>> understanding is that if libdl is in the correct location in /mingw64,
>> then it should normally and automatically be found by CMake for
>> /mingw64/bin/g++.exe when NO_SYSTEM_ENVIRONMENT_PATH is not set.
>
> Hi Alan,
>
> I'm one of the founders of MSYS2 (not that that means I know what I'm
> talking about mind you!) .. You are right, that normally for building
> mingw-w64 x86_64 software on MSYS2 you'd use mingw64_shell.bat, but
> when building MSYS2 packages via makepkg-mingw, you'd run
> msys2_shell.bat instead since that builds both the 32-bit and 64-bit
> variants setting the correct environment up beforehand each time.
>
> 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 msys2, so
> there'll never be a /mingw{64,32}/lib/libdl.a or
> /mingw{64,32}/lib/libdl.dll.a, but there is a /usr/lib/libdl.a. When
> building mingw-w64 software, the front of PATH will be
> "/mingw64/bin:/usr/bin" or "/mingw32/bin:/usr/bin" and that causes
> CMake to find /usr/lib/libdl.a due to NO_SYSTEM_ENVIRONMENT_PATH.
>
> I think the best I can do is to edit each of our CMake using PKGBUILD
> scripts to set PATH to a clean value just before invoking CMake. This
> is something I didn't really want to have to do.

Replying to myself; first sign of something --good .. but I've thought
immediately of a case where I can't modify PATH like I suggested. We
have some packages (e.g. hlsl2glslfork) that use bison and flex, and
those packages use msys2 flex and bison. For those to work, I can't
remove /usr/bin from PATH for all PKGBUILDs that invoke CMake as I had
planned, so how should I proceed here? (I wouldn't be surprised if
clang/llvm also call bison and flex).

>
> To my mind, this rummaging around the user's system path feature seems
> too prone to randomness and a large source of build variance. Some of
> this comes from my liking for reproducible builds where environmental
> differences are kept out of the equation.
>
>>
>> However, it appears that is not the find result you are getting and
>> you have responded by trying to find a way to set
>> NO_SYSTEM_ENVIRONMENT_PATH globally.  But I think it would be better
>> instead to explore the case where the NO_SYSTEM_ENVIRONMENT_PATH
>> command is not used to figure out how to get that scenario to
>> correctly find libdl.
>>
>> Therefore, I suggest you make a simple test
>> project which uses "find_library (DL_LIBRARY_PATH dl)" (without
>> NO_SYSTEM_ENVIRONMENT_PATH) to find dl, and fiddle with your PATH (and
>> also CMake version just in case it turns out you are fighting against
>> some recently introduced find_library regression) to

Re: [CMake] NO_SYSTEM_ENVIRONMENT_PATH globally?

[Ray Donnelly]

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 msys2, so
>> there'll never be a /mingw{64,32}/lib/libdl.a or
>> /mingw{64,32}/lib/libdl.dll.a, but there is a /usr/lib/libdl.a. When
>> building mingw-w64 software, the front of PATH will be
>> "/mingw64/bin:/usr/bin" or "/mingw32/bin:/usr/bin" and that causes
>> CMake to find /usr/lib/libdl.a due to NO_SYSTEM_ENVIRONMENT_PATH.
>
>
> Hi Ray:
>
> Did you mean "due to NO_SYSTEM_ENVIRONMENT_PATH _not_ being set"? That is
> the only way that sentence makes sense to me and is also
> consistent with the subject line, but I may be missing something.

Sure, that's what I meant.

>
> So if my interpretation of what you said is correct, your special
> build problem on the MinGW-w64/MSYS2 platform is you want to reject
> msys2 variants of the libraries (thus avoiding a dependency on the
> msys2 dll) while still using msys2 build tools.

Exactly.

>
> Assuming I have stated the problem correctly, then the solution
> normally is to put /mingw{64,32} first on your PATH (like the
> appropriate shell does as you have discussed) and that should
> guarantee the /mingw{64,32} version of the library is found.  However,
> for the special case where there is no /mingw{64,32} version of the
> library (from what you said above libdl is an example of this special
> case) the CMake-based build systems will incorrectly find the msys2
> version of the library (because msys2 is necessarily on the PATH
> because you need access to those build tools) rather than your desired
> result that CMake finds no library at all for this special case.
>
> I believe the MinGW-w64/MSYS2 distribution should address this problem
> in general by making sure that /mingw{64,32} does provide all
> libraries that msys2 provides if at all possible.  However, whenever
> there is some absolutely ironclad reason not to provide a
> /mingw{64,32} variant (as appears to be the case for libdl although
> you may want to review that reason to make sure it is really ironclad)
> then you must patch all build systems for software packages that have
> a soft dependency on libdl to simply ignore any libdl that is found on
> the MinGW-w64/MSYS2 platform.  My impression is that build system
> patches are required quite often for distributions of free software to
> help enforce some policy decisions they have made so it appears that
> MinGW-w64/MSYS2 is also not immune to such a requirement.  Of course,
> this is not a very good solution if there are tonnes of such package
> build systems to patch, but my guess is that patches for just a
> handful of packages would be required to deal completely with this
> special libdl case.

Generally speaking msys2 software is POSIX-y and mingw-w64 software is
Windows-y, so the library setup doesn't overlap very much and we won't
force it (actually we try to limit msys2 packages since Cygwin exists
to fill that need). We also want to apply as light a touch as possible
when it comes to patching software, but of course will when necessary.
For this issue, I think I've figured out what to do:

PATH=${MINGW_PREFIX}/bin:/usr/bin cmake -DCMAKE_SYSTEM_IGNORE_PATH=/usr/lib

>
> By the way, you will be glad to know that I have a strong spectator
> interest in MinGW-w64/MSYS2 because it turns out (thanks to the
> testing reports sent to me by Greg Jung which allowed me to adjust the
> PLplot build system to work properly for the MinGW-w64/MSYS2 case)
> that has recently become one of our most powerful and reliable PLplot
> platforms on Windows.
>

Great to hear. Hopefully MSYS2 can continue to prove useful and gain momentum.

>
> Alan
> __
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __
>
> Linux-powered Science
> __
-- 

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

[CMake] NO_SYSTEM_ENVIRONMENT_PATH globally?

[Ray Donnelly]

Hi,

I ran into a problem on MSYS2 recently building llvm+clang for
mingw-w64 using CMake 3.4.1 (we carry a few local patches, they're
fairly minor, except the qt5-static one, and I don't think they are
likely related to this:
https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-cmake)

MSYS2 has two shells .. actually it's 3 or 4, but for simplicity we'll
ignore the 32-bit ones and pretend there's only 2 64-bit shells, one
launched with msys2_shell.bat and one launched with mingw64_shell.bat.
Under msys2_shell.bat, the "/mingw64/bin" folder doesn't appear at all
in PATH, while under mingw64_shell.bat, it appears at the very front,
before "/usr/bin" (which contains the msys2 software).

When running CMake to configure the build for libclang, it tries to
see if if can find libdl with "find_library (DL_LIBRARY_PATH dl)".
Unfortunately it finds the msys-2.0.dll-linked libdl.a in /usr/lib
because NO_SYSTEM_ENVIRONMENT_PATH isn't set, which isn't then in
/mingw64/bin/g++.exe's linker search path (and even if it was, we
don't want to link msys-2.0.dll software into native software!).

I wondered what the recommended approach is for handling this
scenario? Clearly we need msys2 software to be in our PATH (ls, bash,
etc, etc), but it seems CMake is keen to look in a lot of places to
find libraries (AFAICT, it takes each element in PATH and appends
../lib to it then looks in there with the usual prefix/suffix rules)
..

>From our perspective, as MSYS2 is a distro employing a prefix, we'd be
happy for only that to be searched in for libraries. Is there
something that can accommodate for this already? Clearly, patching
each occurrence of find_library isn't something I can entertain, so
I'd like to make a change to how CMake itself behaves 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 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

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

[Ray Donnelly]

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

[Ray Donnelly]

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

[Ray Donnelly]

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

[Ray Donnelly]

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

[Ray Donnelly]

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)

[Ray Donnelly]

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

[Ray Donnelly]

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

[Ray Donnelly]

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

[Ray Donnelly]

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

Re: [CMake] Mixed linking

[Ray Donnelly]

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 to specify the correct link flags
 yourself'.

 That is, it's 'fine' in the same way that other static libraries which don't
 provide any cmake files at all are 'fine' and leave everything to you.


Right, thanks Steve. When/if I get time, I might try to make some new
patches for this for Qt5 and CMake that aren't reliant on MSYS2's many
Qt5 patches and test them on OS X and GNU/Linux.

 Thanks,

 Steve.


 --

 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
-- 

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

[CMake] Mixed linking

[Ray Donnelly]

Hi,

Apologies that this won't tread correctly (and for directly CC'ing the
three participants); I only signed up to the mailing list after I saw
this conversation. I'm an MSYS2 developer (and I occasionally hack on
Qt build system issues). I've spent a lot of time working on our qt5
and qt5-static packages and a little time working on our cmake
packages, so I'm quite familiar with the CMake and Qt5 static issues
you are discussing, in fact it's the most recent thing I've hacked on
for these packages. My patches can be found at:

https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-qt5-static
[patches 33 .. 41 are mostly cmake related]
.. and:
https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-cmake
[qt5-static-plugin-support.patch]

Stephen Kelly wrote:
 Ghyslain Leclerc wrote:

  Here are a few questions for the list (hoping someone more knowledgable
  than me will read this and help):
 
  1) Am I right when I say CMake, Qt and static linking don’t mix ?

 They should mix fine.

.. actually, you did submit a patch to Qt5 for this:
https://codereview.qt-project.org/#/c/33193/
.. but then you reverted it:
https://codereview.qt-project.org/#/c/37307/

I un-reverted it for MSYS2, with the logic given in my commit message.
I'll not paste it here as you can read it there, but please correct me
if I'm wrong regarding INTERFACE_LINK_LIBRARIES:
https://github.com/Alexpux/MINGW-packages/commit/fe1c58d6baf5ca98cf6697a41e8e98349a7e81d8

Norbert Pfeiler wrote:
 Currently you have to define »QT_STATIC«

You shouldn't need to do this. If you use MSYS2's
mingw-w64-{i686,x86_64}-qt5-static then that will be defined for you.

 and explicitly include your required plugins in the code to get it working

More on this below.

Norbert Pfeiler wrote:

 For Windows it’s like this:

 #if defined(Q_OS_WIN)  defined(QT_STATIC)
 #include QtPlugin
 Q_IMPORT_PLUGIN(QWindowsIntegrationPlugin)
 #endif

Again, if you use MSYS2's mingw-w64-{i686,x86_64}-cmake then you
should not need to do this either, because of
https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-cmake/qt5-static-plugin-support.patch

Stephen Kelly wrote:

 CMake 3.1 learned a new feature specifically so that this would become
 easier in the future:

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7970

 qmake generates a file like the above for you and compiles it and links it
 into your application for you in the static version.

 With

 http://www.cmake.org/cmake/help/v3.1/prop_tgt/INTERFACE_SOURCES.html

 Qt can do the same, but someone would have to patch Qt to do so. Something
 for the future... :)

.. so I guess that overall, my patches are far from ideal (still they
achieve their goal for us!), in particular I didn't like adding code
to cmQtAutoGenerators.cxx as that seems like something that shouldn't
be hard-coded into a general purpose build system, but I'm pleased to
read that the plan is to generalise this kind of thing going forward
(I think that's the gist - clearly I'm no expert in CMake).

As a side node, I actually tried to use a Digia-provided (I think) Qt
static build for something work-related about a year ago, and because
it requires a specific version of the msvc++ runtime I don't think it
fits any useful definition of 'static'. 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 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