On Tue, 16 Apr 2019 at 01:01, Andrew Maclean wrote:
>
> In build.ninja all the requested linker libraries are there e.g.
> /usr/local/lib/libboost_date_time.so>
> Boost 1.70
> When using Boost 1.70 all I get in the CMakeLists.txt file are entries like:
> //The directory containing a CMake config
Has anyone else got issues using Boost 1.70 in their code.
I'm using CMake 3.14.2
I have done the usual build/install of Boost in linux and everything seems
to be installed Ok in /usr/local/include and /usr/local lib.
The problem is the no linker libraries are being found.
I use this in my CMakeLi
Hi Craig,
thanks for the clarification.
Best,
Michele
On Mon, Apr 15, 2019 at 2:09 AM Craig Scott wrote:
>
>
> On Wed, Apr 3, 2019 at 11:10 AM Michele Rosso wrote:
>
>> Hello,
>> according to the doc for CMake 3.14, target_sources() interprets relative
>> source file paths as being relative t
Hi,
I'm currently testing CMake 3.14.2's iOS support with our build system
and ran into a problem with try_compile() not finding the binary. Here
is an example while trying to configure libjpeg-turbo 2.0.2 (I've
shortened the paths to make this easier to read):
--- SNIP ---
-- Check size of
What is the proper way to handle the case where find_program() needs
match "program-name" or "program-name.exe" depending on wether the host
system is running a unix like OS or Windows?
A project I'm looking at uses CMAKE_EXECUTABLE_SUFFIX for the target, so
I assume that can't be used.
A si
On Wed, Apr 3, 2019 at 11:10 AM Michele Rosso wrote:
> Hello,
> according to the doc for CMake 3.14, target_sources() interprets relative
> source file paths as being relative to the current source directory, i.e.
> it should
> prepend CMAKE_CURRENT_SOURCE_DIR to the relative paths given by the u
