_VERSION_MINOR 8)
-set(CMake_VERSION_PATCH 20170424)
+set(CMake_VERSION_PATCH 20170425)
#set(CMake_VERSION_RC 1)
---
Summary of changes:
Source/CMakeVersion.cmake |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
hooks/
On 4/24/2017 3:56 PM, Chris Russo wrote:
Greetings-
Well this should be simple right? I have Windows 10 64 bit. Visual
Studio Community 2015. It shows that my version on a certain build is
cmake 3.6.2. I have tried to download the latest and greatest set the
path and no luck.
where is,
Greetings-
Well this should be simple right? I have Windows 10 64 bit. Visual
Studio Community 2015. It shows that my version on a certain build is
cmake 3.6.2. I have tried to download the latest and greatest set the
path and no luck.
where is, which, find, search looking all over the file
On Mon, Apr 24, 2017 at 19:58:52 +0100, Roger Leigh wrote:
> While you can install as many of the runtime packages as you like, the
> headers go into /usr/include and so they conflict with each other,
> limiting you to a single development package at one time (checked the
> behaviour to verify
On 24/04/2017 19:30, Ben Boeckel wrote:
On Mon, Apr 24, 2017 at 19:17:39 +0100, Roger Leigh wrote:
Sounds like that's exactly the problem. You can only have one libpng
*development* package installed at once. You probably want the regular
"libpng-dev" package installed if you want to build
On Mon, Apr 24, 2017 at 19:17:39 +0100, Roger Leigh wrote:
> Sounds like that's exactly the problem. You can only have one libpng
> *development* package installed at once. You probably want the regular
> "libpng-dev" package installed if you want to build against the standard
> libpng.
Ah,
On 24/04/2017 15:54, Robert Dailey wrote:
Sorry to bump; any info on this? I'm completely blocked :-(
On Fri, Apr 21, 2017 at 4:48 PM, Robert Dailey wrote:
I'm running CMake 3.8.0 on Ubuntu 14. I invoke the following:
find_package(PNG REQUIRED)
Which gives me the
On Mon, Apr 24, 2017 at 12:20:27 -0500, Robert Dailey wrote:
> -- The C compiler identification is GNU 4.9.4
> -- The CXX compiler identification is GNU 4.9.4
> -- Check for working C compiler: /usr/bin/gcc-4.9
> -- Check for working C compiler: /usr/bin/gcc-4.9 -- works
> -- Detecting C compiler
On Mon, Apr 24, 2017 at 12:20:27 -0500, Robert Dailey wrote:
> -- The C compiler identification is GNU 4.9.4
> -- The CXX compiler identification is GNU 4.9.4
> -- Check for working C compiler: /usr/bin/gcc-4.9
> -- Check for working C compiler: /usr/bin/gcc-4.9 -- works
> -- Detecting C compiler
Try adding this to your toolchain file:
set( CMAKE_C_LIBRARY_ARCHITECTURE "i386-linux-gnu" )
set( CMAKE_CXX_LIBRARY_ARCHITECTURE "i386-linux-gnu" )
From: rcdai...@gmail.com on behalf of Robert Dailey
Sent: April
Interestingly, the changes to my toolchain made below work:
set( CMAKE_SYSTEM_NAME Linux )
set( CMAKE_SYSTEM_VERSION 1 )
set( CMAKE_SYSTEM_PROCESSOR i386 )
set( CMAKE_C_COMPILER gcc-4.9 )
set( CMAKE_CXX_COMPILER g++-4.9 )
set( CMAKE_C_COMPILER_ARG1 -m32 )
set( CMAKE_CXX_COMPILER_ARG1 -m32 )
The output is:
x86_64-linux-gnu
How can I tell CMake to look for 32-bit libraries? I would like to
force this from my toolchain file (which I posted a few minutes ago)
On Mon, Apr 24, 2017 at 10:16 AM, Andrew Fuller wrote:
> Where did the library get installed on your
On Mon, Apr 24, 2017 at 10:02 AM, Ben Boeckel wrote:
> On Mon, Apr 24, 2017 at 09:54:18 -0500, Robert Dailey wrote:
>> On Fri, Apr 21, 2017 at 4:48 PM, Robert Dailey
>> wrote:
>> > I'm running CMake 3.8.0 on Ubuntu 14. I invoke the following:
On Mon, Apr 24, 2017 at 10:02 AM, Ben Boeckel wrote:
> On Mon, Apr 24, 2017 at 09:54:18 -0500, Robert Dailey wrote:
>> On Fri, Apr 21, 2017 at 4:48 PM, Robert Dailey
>> wrote:
>> > I'm running CMake 3.8.0 on Ubuntu 14. I invoke the following:
Where did the library get installed on your system? What's the value of
CMAKE__LIBRARY_ARCHITECTURE?
Since you're on a 64-bit system, I'd expect CMake to be looking for 64-bit
libraries unless you've told it otherwise.
From: CMake on
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, release has been updated
via 627288fe23dd99aa14b6ca82e17634513765b32c (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 3cb7048b521395fdc863dacacb85c6f7f28a1bc7 (commit)
via
On Mon, Apr 24, 2017 at 09:54:18 -0500, Robert Dailey wrote:
> On Fri, Apr 21, 2017 at 4:48 PM, Robert Dailey
> wrote:
> > I'm running CMake 3.8.0 on Ubuntu 14. I invoke the following:
> >
> > find_package(PNG REQUIRED)
> >
> > Which gives me the output in CMake:
> >
>
On Mon, Apr 24, 2017 at 09:54:18 -0500, Robert Dailey wrote:
> On Fri, Apr 21, 2017 at 4:48 PM, Robert Dailey
> wrote:
> > I'm running CMake 3.8.0 on Ubuntu 14. I invoke the following:
> >
> > find_package(PNG REQUIRED)
> >
> > Which gives me the output in CMake:
> >
>
Sorry to bump; any info on this? I'm completely blocked :-(
On Fri, Apr 21, 2017 at 4:48 PM, Robert Dailey wrote:
> I'm running CMake 3.8.0 on Ubuntu 14. I invoke the following:
>
> find_package(PNG REQUIRED)
>
> Which gives me the output in CMake:
>
> Could NOT find
Sorry to bump; any info on this? I'm completely blocked :-(
On Fri, Apr 21, 2017 at 4:48 PM, Robert Dailey wrote:
> I'm running CMake 3.8.0 on Ubuntu 14. I invoke the following:
>
> find_package(PNG REQUIRED)
>
> Which gives me the output in CMake:
>
> Could NOT find
On 04/24/2017 10:09 AM, Daniel Pfeifer wrote:
> Brad, can you share what the current status is on this? If I
> remember correctly, then libuv cannot be built yet on all
> necessary compilers. Is that still the case? This sounds like
> the biggest impediment.
Yes, though I've been making some
On Mon, Apr 24, 2017 at 3:03 PM, Brad King wrote:
> On 04/23/2017 01:30 AM, Konstantin Podsvirov wrote:
> > Where execute_process INPUT_CONTENT or INPUT_VARIABLE?
> >
> > This would be very convenient for a small input.
> >
> > Why should I always write a file for input?
>
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 80362f7e31233c2525f47a954084b89e320c38fa (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 dc6632b9da0b804e6c00b71f06b26f561475858d (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 aaeb01ef9bfa600e072be79792be53186c395a8c (commit)
via
Hi!16:05, 24 April 2017 г., Brad King :On 04/23/2017 01:30 AM, Konstantin Podsvirov wrote: Where execute_process INPUT_CONTENT or INPUT_VARIABLE? This would be very convenient for a small input. Why should I always write a file for input?I agree that the options should be
On 04/21/2017 05:45 PM, Christian P. wrote:
> Is this a good/bad idea or is there any way to do this in a proper fashion?
> The idea of adding an actual target to a Find module seems wrong to me,
> but I’m not seeing any way of doing it otherwise.
I think we'll have to expose this requirement to
On 04/23/2017 01:30 AM, Konstantin Podsvirov wrote:
> Where execute_process INPUT_CONTENT or INPUT_VARIABLE?
>
> This would be very convenient for a small input.
>
> Why should I always write a file for input?
I agree that the options should be there but they can't be easily
implemented without
I've found the culprit, in boringssl/crypto CMakeLists.txt there is:
enable_language(ASM_NASM)
If I remove this (since I don't use asm), it works on both x86 and amd64 (!)
> -Original Message-
> From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Robert
> Bielik
> Sent: den 24
Hi all,
I've come to a problem with Ninja on Windows, but only when building for MSVC
amd64 toolchain. With x86, it works OK. The error I get is:
CMake Error: Error required internal CMake variable not set, cmake may be not
be built correctly.
Missing variable is:
CMAKE_ASM_NASM_COMPILE_OBJECT
31 matches
Mail list logo