With CMake, you can control compilation and link flags with the following
environment variables:
* CC: specify C compiler
* CFLAGS: C compiler flags
* CXX: specify C++ compiler
* CXXFLAGS: C++ compiler flags
* LDFLAGS: linker flags
And to finish you can overload make command
Hi all,
I'm working on using CMake to create a build system that targets an
incredibly hard-to-deal-with IDE/build system, used for doing some embedded
programming (Xilinx's Vivado suite).
One of the pieces I need to get working is a conditional dependency between
two files (a project-file genera
On 12/10/2015 12:19 AM, Igor Sobinov wrote:
igor 5460 0.0 0.0 101152 972 pts/3 S+ 08:10 0:00 | \_ make build_release -j5
igor 5466 0.0 0.0 106096 1164 pts/3 S+ 08:10 0:00 | \_ /bin/sh -c cd
/home/igor/build_root/release_target; make release
igor 5467 0.0 0.0 101184 1060 pts/3 S+ 08:10 0:00 | \_ m
I've got a Debug build of current 'master' on Windows, and the problem is
also evident with my build:
C:\dev\dcole\tmp\variable_watch_problem\b1> "C:\dev\repos\My Tests\cmake
Win32-ninja-cl12-Debug\bin\
cmake.exe" -G Ninja ..
-- The CXX compiler identification is MSVC 18.0.31101.0
-- Check for wo
Hello,
I use the ExternalProject_Add command to manage third-party libraries.
In the same time, I need to overcome some compatibility problems between GCC 4
and GCC 5 (strings are not defined in the same way in the STL).
The solution I use is the one given here:
http://stackoverflow.com/ques
is '.' in your LD_LIBRARY_PATH and/or /etc/ld.config?
otherwise 'LD_LIBRARY_PATH=. ./LLAPI_TestApp' should work... or export
LD_LIBRARY_PATH=. for a more semi-permanent solution?
On Thu, Dec 10, 2015 at 4:38 AM, Nikita Barawade
wrote:
>
>
> Hi,
>
> getting following error when trying to run LLAP
Hi all.
I'm in trouble with wxWidgets 3 and Visual Studio 10 express.
I need to change the type of libraries depending on the configuration
compiler
If I compile in debug mode I need wxbase30ud.lib, while in release mode
wxbase30u
But if I generate the project for VS2010Express the wxbase30u.l
Am Donnerstag, 10. Dezember 2015 um 12:38:11, schrieb Nikita Barawade
>
> Hi,
>
> getting following error when trying to run LLAPI_TestApp
>
> ./LLAPI_TestApp: error while loading shared libraries: libLLAPI.so: cannot
> open shared object file: No such file or directory
>
> Both LLAPI_TestAp
Hi Ruslan,
Thanks, this is good to know.
I absolutely agree that one needs to avoid using "&&" in the commands
themselves. As it also causes problems when you try to use
CTEST_USE_LAUNCHERS=1. (I myself ran into that issue...)
But I did not have any issues so far with putting "whatever" into a
Hi,
getting following error when trying to run LLAPI_TestApp
./LLAPI_TestApp: error while loading shared libraries: libLLAPI.so: cannot open
shared object file: No such file or directory
Both LLAPI_TestApp and libLLAPI.so are present in same directory Bin/Wind.
CMakeLists.txt for LLAPI_Test
On 10-Dec-15 12:52, Attila Krasznahorkay wrote:
Hi QP,
Probably not the intended solution, but what I’m doing in such cases is that in
a patch step I create a shell script that does the configuration for me. With
all the environment settings and everything. Like:
PATCH_COMMAND ${CMAKE_COMMAND
After commenting out the call there is no error output:
-- The CXX compiler identification is MSVC 17.0.61030.0
-- Check for working CXX compiler using: Visual Studio 11 2012 Win64
-- Check for working CXX compiler using: Visual Studio 11 2012 Win64 --
works
-- Detecting CXX compiler ABI i
Out of curiosity, what output do you get (with 3.4.1) when you comment out
your call to variable_watch? Do you still get error output, but without
strange symbols in it? Or is there no error output in that case?
On Thursday, December 10, 2015, Yves Frederix
wrote:
> Hi all,
>
> I am experiencin
Hi all,
I am experiencing problems during the CMake configure step when using
the function variable_watch. Consider the following minimal CMakeLists
file:
cmake_minimum_required(VERSION 3.4)
project(test CXX)
function(myhook _variable _access _value _current_list_file _stack)
if("${_va
On Thu, Dec 10, 2015 at 12:15 AM, Petr Kmoch wrote:
> Hi,
>
> Side note: you probably shouldn't be using the -l prefix with arguments to
> target_link_libraries(). The arguments are normally supposed to be either
> CMake target names, or full paths to the libraries you want to link. No need
> to p
that's actually a good point. Currently as I am developing this i am doing
an out of source build and just testing it from there but eventually what I
want is a shared library that can be used by other programs.
currently though my other programs is just a simple main.c that includes
the main libr
Hi Owen,
Sorry to jump into the discussion, but what you're talking is
something I was thinking of just recently...
I think the choice between this:
On Thu, Dec 10, 2015 at 3:48 PM, Owen Alanzo Hogarth
wrote:
> set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
> set(CMAKE_LIBRARY_OUT
Hi,
yes, that is indeed expected behaviour. target_link_libraries() takes a
CMake list of arguments - one library per argument. When you surround the
thing with quotes, it's a single argument (containing some spaces). So for
this call:
target_link_libraries(Debug "${VTK_LIBRARIES} -lsri-spatialff
oh cool
adding target_include_directories(lib1 PUBLIC
${CMAKE_CURRENT_SOURCE_DIR}/headers)
and then I can just use #include "lib1" where needed. No more of those very
static paths!
Thank you very much!
On Thu, Dec 10, 2015 at 4:08 PM, iosif neitzke <
iosif.neitzke+cm...@gmail.com> wrote:
> I wo
I would think
add_library( lib1 SHARED lib1/lib1.c )
target_include_directories( lib1 PUBLIC lib1/headers )
is simpler. Are the generator expressions needed for target export
install commands, and is exporting targets at install preferred to
add_subdirectory() ?
On Thu, Dec 10, 2015 at 1:48 AM,
20 matches
Mail list logo