Hi,
you have to differ here:
lintian is for checking packaging policy of distribution packages for Debian
and derivatives like Ubuntu.
Cpack does not necessarily create packages according to these policies but
still valid packages. If dpkg eats it without errors, it's ok for
out-of-distribution
IMHO the cmake documentation is about 5x too terse.
I wish for lots and lots of short examples and user-texted descriptive text.
--
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 supp
From what I can glean online, I’ve tried this:
set_source_files_properties(foo.bar PROPERTIES LANGUAGE CXX)
add_executable(foo foo.bar)
set_target_properties(foo PROPERTIES LINKER_LANGUAGE CXX)
but it doesn’t work.
What am I missing?
0 Mon 20:16:15 yost
1181 Z% cat CMakeLists.txt
cmak
Hi
I have generated a DEB package with cpack, but the analysis with lintian in
Ubuntu reveals still some errors:
E: at: changelog-file-missing-in-native-package
E: at: control-file-has-bad-owner md5sums b/users != root/root
E: at: no-copyright-file
E: at: extended-description-is-empty
E: at: mai
On Sat, Mar 14, 2015 at 9:51 PM, Roman Bolshakov wrote:
> Here's an example function which addresses 1.
> It creates a string of generator expressions for direct and indirect
> dependencies of a target recursively.
> When all recursive invocations are done, it spits -deps
> file in the CURRENT_BI
On Mon, Mar 16, 2015 at 7:48 PM, Stephen Kelly wrote:
> Klaim - Joël Lamotte wrote:
>
> > I am looking for a (hopefully simple) way to do the following:
> > 1. gather a list of paths of all the binaries associated with a target,
> > that is all the linked dll/so and executable the target link
On Mon, Mar 16, 2015 at 7:36 PM, Stephen Kelly wrote:
> There might be space for a first class feature in cmake for 'make something
> that looks like the install tree at build time'. Please file an issue to
> track it.
>
> Thanks,
>
Done: http://public.kitware.com/Bug/view.php?id=15450
So there
On Mon, Mar 16, 2015 at 7:11 PM, Roman Bolshakov wrote:
> > I'm not totally sure install() does exactly what I need.
> > My use case is that I need to debug each executable in an installed-like
> > context (with data), which imply that each time it is compiled it should
> be installed too.
> > Ac
I am working on Raspberry pi B+. I am using the normal Raspbian, Debian
Wheezy. I have installed owcapi lib on the Raspberry pi (sudo apt-get
install libow-dev). I have read the rootfs bnack to the host machine, Ubuntu
14.04 LTS using rsync. These files are stored under /opt/pi/rootfs.
Now my prob
Scott Aron Bloom wrote:
> I have found I can disable it project by project, but I cant seem to
> disable it, globally for every project
>
> Is there a way (or point in the cmake flow) to disable it globally?
It is disabled by default. It is defaulted to on for targets following the
setting
Richard Taylor wrote:
>
http://www.cmake.org/Wiki/CMake/Tutorials/How_to_create_a_ProjectConfig.cmake_file
>
Prefer the official documentation instead of the wiki wherever official
documentation exists (especially if it is well-formatted; that means it's
probably recent and maintained).
http
Klaim - Joël Lamotte wrote:
> I am looking for a (hopefully simple) way to do the following:
> 1. gather a list of paths of all the binaries associated with a target,
> that is all the linked dll/so and executable the target link or depend
> on.
Apparently I starting thinking about a genex to
Klaim - Joël Lamotte wrote:
> Actually 2 and 3 are the same, I just put the files in a specific place in
> the
> build directory so that it looks like installed, but I do this when the
> binary is
> built so that it's always up to date while debugging.
> Now, I use post-build command (add_custom_c
> I'm not totally sure install() does exactly what I need.
> My use case is that I need to debug each executable in an installed-like
> context (with data), which imply that each time it is compiled it should be
> installed too.
> Actually 2 and 3 are the same, I just put the files in a specific p
Oh, shoot, it turns out I was using our ancient 2.6.4 install by
accident. It works fine for me in cmake 3.1.3.
Sorry for the noise,
B.
On 03/14/2015 10:54 AM, David Cole wrote:
Works for me with CMake 3.2.1 on Windows. What version of CMake are you using?
C:\dev\dcole> type args.cmake
forea
Hello, I'm a CMake newbie trying to build a chain of libraries on windows,
let's call them A, B and C
A is a standalone shared library
B is a shared library that depends on A in its headers & implementation
C is a shared library that depends on B (and so implicitly depends on A)
All three export
Based on what was posted.. I was able to get this working without much
difficulty.
For all of my libraries, I use the technique borrowed from my qmake days, so
all headers (and source) are stored as a variable ${project_H} and if it's a qt
based header ${qtproject_H}
So I added to every CMakeL
Hi Andreas,
> Why do you want to use one library per header? I think, it would be
> sufficient to have one cc-file per header and one library per folder.
Then I can test also for single headers.
> Why do you worry about large build directories?
Because for slow file systems like Windows it take
Hi Brad,
attached is an updated patch.
Roman
From ea75cb1a3d866d923b6711c9e0c0bbf1f66d7dbf Mon Sep 17 00:00:00 2001
From: Roman Wüger
Date: Fri, 13 Mar 2015 09:18:19 +0100
Subject: [PATCH] WCDH: Fix cxx_nullptr for compilers which doesn't support
C++11
---
Modules/WriteCompilerDetectionHead
19 matches
Mail list logo
