Please open an issue at https://gitlab.kitware.com/cmake/cmake/issues
to request support for this.
Kyle
On Tue, Oct 29, 2019 at 9:58 AM Nicolas Desprès
wrote:
>
> Hi there,
>
> Generator expressions are allowed in the FILES/PROGRAMS and DESTINATION part
> of an install command.
>
> Would that b
On Fri, 2019-09-13 at 22:08 +0530, Tushar Maheshwari wrote:
> Hi,
>
> I am a C++ developer and a modern-C++ enthusiast. In the interest of
> modernizing the codebase, I propose using smart pointers to handle
> dynamically allocated memory. I would like to get the feedback from
> the developers if
On Fri, 2019-08-30 at 19:01 +0300, Eugene Karpov wrote:
> Not working too.
> The failed lines in a generated make file looks like this
> ---
> CMakeFiles/mkflags_test:
> /usr/bin/cmake -DDEFINITIONS=-
> DAPI=__attribute__((visibility("default"))) -
> DFILENAME=/home/ekar
On Fri, 2019-08-30 at 17:54 +0300, Eugene Karpov wrote:
> I've tried this. But then it fails to compile due to `INTERFACE
> API=${API_EXPORT_MACRO}` target compile definition.
Ah right, you want the file contents to be escaped while the compile
flags are not. My next suggestion was going to be to
On Fri, 2019-08-30 at 17:36 +0300, Eugene Karpov wrote:
> Hello all,
>
> I'm working on a cross platform project. On Ubuntu I would like to
> save all the compiler options, definitions and other complier related
> stuff to a generated file to use it later for precompiled header
> generation.
> My
All,
I am pleased to announce that we are now offering Ubuntu builds of the
CMake release candidates, in addition to the production releases. The
first available release candidate build is 3.15.0~rc1-0kitware2.
If you would like to receive release candidate builds, follow the
instructions at http
On Sat, 2019-04-06 at 10:56 +0200, Rolf Eike Beer wrote:
> Nice!
>
> The magic spell for TravisCI is:
>
> addons:
> apt:
> sources:
> - sourceline: 'deb https://apt.kitware.com/ubuntu/ xenial main'
> key_url: 'https://apt.kitware.com/keys/kitware-archive-2019.a
> sc'
> pac
All,
I am pleased to announce that Kitware is now offering an
officially-supported set of Ubuntu packages for CMake. These CMake
packages can be installed with apt-get, just like other Ubuntu
packages. We currently support Ubuntu 16.04 and 18.04.
The following packages are available:
* cmake - C
On Fri, 2019-01-25 at 14:06 -0800, Venedict Tchistopolskii wrote:
> Could you clarify on saving the build-directory section?
>
> I'm not sure how it knows which cache or build directory to load. In
> my setup here the issue I noted applies even if build directory is
> generated on both projects/et
On Fri, 2019-01-25 at 13:23 -0800, Venedict Tchistopolskii wrote:
> Get 2 CMake projects.
>
> Get CMake GUI to 'configure' one of them. Close/re-open and it will
> automatically point to this configured project source and build
> locations, regardless of what build/version/cmake-gui.exe you use.
On Fri, 2019-01-25 at 12:55 -0800, Venedict Tchistopolskii wrote:
> Cherry picked and tested. Works great, thank you!
Great, glad to hear it!
> Now, if only the source/build path would stick around, without requiring
> config to be triggered. :P
Can you clarify what you mean by this?
Kyle
>
--
Venedict,
Currently, cmake-gui only lets you specify a build or source directory,
not both.
I've opened https://gitlab.kitware.com/cmake/cmake/merge_requests/2863
to add explicit -S and -B options to cmake-gui, which will allow you to
specify both.
Kyle
On Fri, 2019-01-25 at 08:10 -0800, Venedict
On Fri, 2019-01-25 at 09:18 +0100, Gößwein Matthias / eeas gmbh wrote:
> However, the manual does not describe this behavior, maybe it should
> be
> mentioned there.
> (https://cmake.org/cmake/help/v3.13/manual/cmake-gui.1.html)
Even better, perhaps we should add explicit -B and -S options the way
On Thu, 2019-01-24 at 12:31 -0800, Venedict Tchistopolskii wrote:
> Nevermind, fixed the cmake-gui.
Ah OK, then disregard my response.
> Would be nice to know how to triger the proper install/release config from
> VStudio, atm I do this:
> cmake . --target install --config Release
This looks corre
On Thu, 2019-01-24 at 12:25 -0800, Venedict Tchistopolskii wrote:
> The install command auto-installs release right?
> How do I trigger this 'install' from VStudio?
> Is building in VStudio enough before install?
> e.g. generate solution -> build in VStudio -> run install
> command in CLI?
Ye
On Thu, 2019-01-24 at 12:36 -0500, Kyle Edwards wrote:
> cmake --build . --target install
> windeployqt C:/Path/To/Where/I/Want/To/Install/bin/cmake.exe
Oops - this should obviously be
C:/Path/To/Where/I/Want/To/Install/bin/cmake-gui.exe.
Kyle--
Powered by www.kitware.com
Please keep messages o
On Thu, 2019-01-24 at 09:27 -0800, Venedict Tchistopolskii wrote:
> Er, lemme clarify.
>
> Can cmake-gui.exe be built along with cmake if using the install path
> setting? I currently use windeployqt to handle gui dependencies.
Yes, like I mentioned, just build with BUILD_QtDialog=ON. You can then
On Thu, 2019-01-24 at 09:23 -0800, Venedict Tchistopolskii wrote:
> I was building it via VStudio and generating the solution via CMake,
> is that wrong?
Nope! You're building it just fine. The only problem is in the
installation - you were installing cmake.exe without all of the
external files it
I forgot to mention - building it this way doesn't require the use of a
toolchain file - it was in response to this:
> Trying to do so because building CMake without toolchain gives me the
below; After I move cmake.exe to another directory:
If you build it as I laid out below, you won't need a too
Venedict,
To relocate cmake.exe, it's not sufficient to just copy the executable
- you have to install all of the modules along with it. You do this by
running the "install" target.
Given a path to where you want to put CMake, you would build it like
this:
cmake C:/Path/To/CMake/Source
-DCMAKE_INST
On Sun, 2018-12-30 at 13:09 -0800, Saleem Abdulrasool wrote:
> Hi,
>
> I was looking at supporting Swift as a language in CMake. I know
> that CMake has some preliminary support that assumes that you are
> building on macOS with Xcode. I am trying to support building swift
> libraries and execut
On Sat, 2018-12-22 at 16:57 +0100, Torsten Robitzki wrote:
> What I’m still missing is support to define dependencies between
> different targets (build by different toolchains), so that I can
> describe that I require a tool that is build with the HostToolChain,
> to generate a file that is requir
On Tue, 2018-12-18 at 20:53 -0500, frodak17 wrote:
> I have thought about it which is why I asked. The original
> assumption of one toolchain per CMake project is being extended. So
> why not think of extending the build type. Sure it's simpler to
> ignore the build type. However, it doesn't make
On Tue, 2018-12-18 at 16:12 -0500, frodak17 wrote:
> So it would be something like project( [TOOLCHAIN
> [LANGUAGES] [...]) where TOOLCHAIN
> and its supported languages can be repeated for each tool chain. i.e
> project(whatever TOOLCHAIN default LANGUAGES cpp TOOLCHAIN cross
> LANGUAGES c)
I thi
On Tue, 2018-12-18 at 14:10 -0500, frodak17 wrote:
> How does this work with multiple languages and the project() command
> and enable_language() commands?
Both project() and enable_language() could be extended with an optional
TOOLCHAIN argument.
> For instance you want to use the host c++ compile
On Tue, 2018-12-18 at 06:14 -0500, frodak17 wrote:
> What first cross my mind with '"utilities" needed for build' is when
> you have to build the cross-compiler in the first place before you
> build anything for the target.
> If so how do you handle verification of the tool-chain can build a
> work
Eric,
Thanks for the feedback. See comments below.
On Mon, 2018-12-17 at 22:06 +0100, Eric Noulard wrote:
> > This has some common design issue as my proposal:
> > enable_cross_target(...)
> > for which Eike has valuable doubt:
> > https://cmake.org/pipermail/cmake-developers/2018-November/030919.h
Hello everyone,
One of the things that's long been requested of CMake is the ability to
have multiple toolchains - for instance, one host toolchain and one
cross toolchain, so that "utilities" needed for build can be built with
the host toolchain and then the "real" software can be built with the
28 matches
Mail list logo
