Le mer. 15 août 2018 à 10:32, Damir Porobic a
écrit :
> Hi Folks,
>
>
> I'm trying to write a shared library and run into an issue where I can't
> find any clues to where the problem is.
>
> I have a project with following structure:
>
>
> src/
>
> dir1/
>
> file1.h
>
>
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
Hi,
I'm trying to create a header file containing version number details but
am not sure if the following behaviour is expected or a bug.
Simplified example has 2 files
==> CMakeLists.txt <==
cmake_minimum_required(VERSION 3.11)
project (
VersionTest
VERSION 1.0.4
)
configure_file (
I suppose it all depends on if there are situations where you don’t want
those variables set? To me, it doesn’t make sense to ever not have version
numbers set so I would use #define.
-Caleb
On Wed, Aug 15, 2018 at 8:32 AM Ian Cullen
wrote:
> Hi,
>
> I'm trying to create a header file
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
Le mer. 15 août 2018 à 10:57, Ray Donnelly a
écrit :
> 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.
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,
>
>
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
Why isn‘t it enough to install the SDK and NDK?
Regards
Roman
> Am 09.08.2018 um 09:02 schrieb Roman Wüger :
>
> Hello,
>
> is it somehow possible to build an Android project with CMake and Visual
> Studio without the Nsight Tegra Visual Studio Edition? Because the
> installation of NVIDIA
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,
conda-build maintainer here. I agree that having conda/conda-build as a
provisioner for general-purpose build environments would be helpful. I'm
afraid I don't understand what's missing or otherwise needs to change here,
though. If you have concrete suggestions (and better, PRs) for how to make
> cannot find CUDA likely as CUDA was not installed after 2017
The CUDA language support requires the CUDA MSBUILD extensions, which
will require you to run the CUDA installer again ( it only installs
the msbuild extensions for versions that are currently installed ).
> I would like it to load
I cannot use conda-build if I am developing. Consider that I will be
editing the sources, compiling and running tests constantly. Going through
the conda-build process every time I need to check some changes would be
too much overhead. conda-build does a lot of things, it creates multiple
new
Yes I know all about the bit about having to reinstall CUDA (been using it
since the 2.0 days) for 2017 (using VS since 2005) if only I could get
CMake to call VS2013... ya know the version that already has cuda 8.0
installed and configured and the extensions from C:\Program Files\NVIDIA
GPU
It does have unit tests and an executable which I use for testing, all that
works fine.
I have the feeling that something with the CMakeList config is not alright. Is
there any tutorial that explains how to correctly create a shared library?
From: CMake on
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
-- Forwarded message -
From: Eric Noulard
Date: mer. 15 août 2018 à 17:13
Subject: Re: [CMake] Problem with creating shared library
To:
May be check the list of symbol in the lib.
KImageAnnotator::KImageAnnotator(QPixmap const&)
may really not be there (only declared in some
Am 15. August 2018 17:45:46 MESZ schrieb Brian Davis :
>Can CMake defer to what the user ultimately wants? .. say the correct
>version of VS. I mean that is what I thought I specified.
Do you actually read the answers?
You can configure that in the Windows explorer like it you wanted to open
Hi Folks,
I'm trying to write a shared library and run into an issue where I can't find
any clues to where the problem is.
I have a project with following structure:
src/
dir1/
file1.h
file1.cpp
dir2/
file2.h
file2.cpp
Now I have this
You are mixing the config file and the targets file.
The config file is a template that you normally put in cmake/
FooConfig.cmake.in
You copy the template into the binary dir:
include(CMakePackageConfigHelpers)
set(INSTALL_CONFIGDIR lib/cmake/Foo)
configure_package_config_file(
Ah, I see that FIND_PACKAGE_HANDLE_STANDARD_ARGS prints
-- Find Foo: (found version "")
I guess my function is not necessary, I can just put inside FooConfig.cmake
find_package_message(Foo
"Found Foo: ${CMAKE_CURRENT_LIST_FILE} (found version
\"@PACKAGE_VERSION@\")"
So here's some more odd bits. Due to CMake (originally I only wanted to
upgrade VS) I have now entered the version upgrade cascade and upgraded to
cuda 9.0 (yes the one with 4 patches, but the only one that works
TensorFlow on windows due to cuDNN.dll... sigh) in hopes to get VS2017 to
work
The MSVC / CUDA support recently has been very challenging to keep track
of. In general CUDA will only support a single patch release of MSVC, and
given how MSVC 2017 doesn't easily allow rollbacks and has a pretty
aggressive update policy ( compared to older MSVC versions ) causes lots of
pain.
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".
The branch, master has been updated
via a6f7a01f3acb97f9e7fd48705aca33a19564671f (commit)
via
Hi,
I was curious about Bullseye coverage integration with CDash and thought to
remember that this was available on CMake's Dashboard at some point.
Currently I see a "Linux-bullseye-cov" build but no entry under "Coverage".
Is that expected or did this break at some point?
Nils
--
Powered
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".
The branch, master has been updated
via ca2e781703dab42f309bf31189011d69e37b954f (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".
The branch, master has been updated
via 349f8bfb25349892fb2c4e5a9942e4bd63f86f49 (commit)
via
This is the mailing list for CMake developers. Please send your query to
the CDash mailing list, which you can find here:
https://www.cdash.org/mailing-lists/
On Thu, Aug 16, 2018 at 5:52 AM, Vasquez, Justin
wrote:
> Hi,
>
> I'm using CDash 2.4.0 to test my builds nightly. If I go to my
Hi,
I'm using CDash 2.4.0 to test my builds nightly. If I go to my project and
navigate to Settings -> Groups -> Current BuildGroups, there are three tabs
for Nightly, Continuous, and Experimental builds. When I click any of the
email preferences (normal, summary, or no email) and save the
My dislike against these functions is probably known, and now I would like to
bring this to a new level: I would like to formally deprecate these functions.
I don't think they serve any useful purpose anymore, given that now even the
pkg-config module can (and does) return absolute paths to the
t a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index b7641ff..92e5552 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,5 +1,5 @@
# CMake version number components.
set(CMake_VERSION_MAJOR 3)
set(CMake_VERSION_MINOR 12)
-set(CMake_VERSION_PATCH 20180815)
+set(CMake_VER
31 matches
Mail list logo
