there's a 64 bit generator...
used to be a separate generator "visual studio 12 2013 Win64" but it
doesn't show in the list of generators now...
On Thu, Apr 23, 2015 at 11:27 PM, Xi Shen wrote:
> Hi,
>
> I am using cmake 3.1.1 on my Windows 7 64bit system. I have Visual Studio
> 2013 installed.
What is your cmake generator being used?
For Visual Studio 2013, you will need to use
cmake –G “Visual Studio 12 2013 Win64”
Scott
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Xi Shen
Sent: Thursday, April 23, 2015 11:28 PM
To: cmake@cmake.org
Subject: [CMake] cmake 3.1.1 does not
Hi,
I am using cmake 3.1.1 on my Windows 7 64bit system. I have Visual Studio
2013 installed.
The project I created with cmake works and can build with msbuild. But it
only build the x86 version. If I try:
msbuild /property:Platform=x64 myproj.vcproj
I got error says that the x64 profile does
I've used ExternalProject_Add to trick CMake into supporting two
compilers to build my project.
Part of my project needs OpenMP, but other parts do not. So, on
MacOS, I would prefer to build most of the project with CLang, but the
OpenMP requiring part with gcc.
I have CMake set up to detect whe
On 23 April 2015 at 20:58, Klaim - Joël Lamotte wrote:
> I believe that this issue is with Boost not having a way to specify which
> target architecture is the build,
> which prevent any CMake script to be able to identify which build is
> installed.
Joel,
Thanks for confirming what's the issue.
I believe that this issue is with Boost not having a way to specify which
target architecture is the build,
which prevent any CMake script to be able to identify which build is
installed.
Assuming that the build arch is the same than the OS is not useful on
Windows where most applications
still nee
On 23 April 2015 at 18:04, Nils Gladitz wrote:
> On 23.04.2015 18:00, Mateusz Loskot wrote:
>>
>> It's better, indeed, but what about
>>
>> "This is set to the size of a pointer on the target machine for which
>> the (machine) code is generated."
>
>
> Hm that is in my opinion too redundant.
> The
On 23.04.2015 18:00, Mateusz Loskot wrote:
It's better, indeed, but what about
"This is set to the size of a pointer on the target machine for which
the (machine) code is generated."
Hm that is in my opinion too redundant.
There is only one target machine as far as cmake is concerned and there
On 23 April 2015 at 17:50, Nils Gladitz wrote:
> On 23.04.2015 17:32, Mateusz Loskot wrote:
>>
>> So, the documentation is imprecise in this regard, isn't it?
>>
>> Best regards,
>
>
> Is this better?
> http://www.cmake.org/cmake/help/git-next/variable/CMAKE_SIZEOF_VOID_P.html
It's better, indeed
On 23.04.2015 17:32, Mateusz Loskot wrote:
So, the documentation is imprecise in this regard, isn't it?
Best regards,
Is this better?
http://www.cmake.org/cmake/help/git-next/variable/CMAKE_SIZEOF_VOID_P.html
Nils
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMa
On 23 April 2015 at 17:20, Nils Gladitz wrote:
> On 23.04.2015 17:08, Mateusz Loskot wrote:
>>
>> I know this trick, but this is not what I'm looking for, unless I
>> misread the documentation.
>>
>> The doc says:
>>
>> "This is set to the size of a pointer on the machine"
>>
>> but not size of po
On 23.04.2015 17:08, Mateusz Loskot wrote:
I know this trick, but this is not what I'm looking for, unless I
misread the documentation.
The doc says:
"This is set to the size of a pointer on the machine"
but not size of pointer on *target* architecture of a build.
I believe I formulated my qu
On 23 April 2015 at 16:57, Nils Gladitz wrote:
> On 04/23/2015 04:54 PM, Mateusz Loskot wrote:
>>
>> Hi,
>>
>> Surprisingly, I'm having trouble to figure out how to determine,
>> that in Linux 64-bit OS, I'm building a project with -m32 specified.
>> IOW, any CMake variable or macro to tell me tar
On 04/23/2015 04:54 PM, Mateusz Loskot wrote:
Hi,
Surprisingly, I'm having trouble to figure out how to determine,
that in Linux 64-bit OS, I'm building a project with -m32 specified.
IOW, any CMake variable or macro to tell me target architecture
of a build that is being configured is 32 or 64
Hi,
Surprisingly, I'm having trouble to figure out how to determine,
that in Linux 64-bit OS, I'm building a project with -m32 specified.
IOW, any CMake variable or macro to tell me target architecture
of a build that is being configured is 32 or 64 bit?
Best regards,
--
Mateusz Loskot, http://
Hi,
Here is the situation outlined:
- project has Boost as optional dependency
- running CMake on Linux 64-bit to build 32-bit binaries
- CXXFLAGS=-m32 is specified
- Boost 64-bit binaries are installed
- Boost 32-bit binaries are *not* installed
Expected result:
- Boost 32 is not found, Boost is
Eigen is just an example of an external library which is very fast to download
and install with ExternalProject_Add.
It is convenient here to let you check that you have the same problem as mine
on your machine.
However, I have other external libraries which have to be compiled.
- Mail or
> > Does the extracted eigen source tree look like it's a proper un-tarred
> > eigen source directory?
Yes, everything seems ok.
> > Does this simple example work for you? (copied/pasted from another
> > recent CMake mailing list discussion...)
Yes, it works!
> > Silly question, but do you ne
I don't know why but providing my own STAMP_DIR seems to solve the problem:
STAMP_DIR ${EXTERNAL_DIR}/eigen/stamp
Hope it helps!
Cédric
- Mail original -
> De: "David Cole"
> À: "Cedric Doucet"
> Cc: cmake@cmake.org
> Envoyé: Jeudi 23 Avril 2015 13:56:36
> Objet: Re: [CMake] Don't d
Yes, I am really sorry for the noise! :-/
- Mail original -
> De: "David Cole"
> À: "Cedric Doucet"
> Cc: "typ1232" , cmake@cmake.org
> Envoyé: Jeudi 23 Avril 2015 13:58:27
> Objet: Re: [CMake] Do build after GIT_TAG changed in ExternalProject_Add
>
> I think you meant to reply on th
I think you meant to reply on the other thread with this one...
:-)
D
On Thu, Apr 23, 2015 at 7:55 AM, Cedric Doucet wrote:
>
> I don't know why but providing my own STAMP_DIR seems to solve the problem:
>
> STAMP_DIR ${EXTERNAL_DIR}/eigen/stamp
>
> Hope it helps!
>
> Cédric
>
>
> - Mail o
It looks correct. I don't understand what the error is. It looks like
the download and extract succeeds, but then it simply doesn't move on
to the next step of trying to configure with CMake...
Does the extracted eigen source tree look like it's a proper un-tarred
eigen source directory?
Does thi
I don't know why but providing my own STAMP_DIR seems to solve the problem:
STAMP_DIR ${EXTERNAL_DIR}/eigen/stamp
Hope it helps!
Cédric
- Mail original -
> De: "David Cole via CMake"
> À: "typ1232"
> Cc: cmake@cmake.org
> Envoyé: Jeudi 23 Avril 2015 13:51:06
> Objet: Re: [CMake] D
Hmm. I am seeing the same behavior you are, even with the older
CMake 2.8.12.2 -- the update step does run, but steps after that,
which are supposed to depend on update, are not re-running.
I think your intuitive expectation is correct, and that
configure/build/install should run after changin
On 2015-04-23 13:32+0200 Nils Gladitz wrote:
On 23.04.2015 13:19, Alan W. Irwin wrote:
Is there a standard way such a function could be used officially as
part of CMake? In other words, are there some official CMake
functions now that are not written in C++ but are instead written as
CMake la
Of the modules, many of the "non-Find*" modules are exactly that. Of
the list here:
http://www.cmake.org/cmake/help/v3.2/manual/cmake-modules.7.html
The ones that pop out to me as obvious "CMake language function
providers" are ExternalProject, GetPrerequisites, BundleUtilities,
ProcessorCount. M
On 2015-04-23 04:19-0700 Alan W. Irwin wrote:
On 2015-04-23 06:47-0400 David Cole wrote:
Should it be configure_file(GENERATE or file(CONFIGURE_AND_GENERATE ??
The first (or configure_file_generate, see below) would be my preference.
In the meantime, while it is certainly clumsy to do the
On 23.04.2015 13:19, Alan W. Irwin wrote:
Is there a standard way such a function could be used officially as
part of CMake? In other words, are there some official CMake
functions now that are not written in C++ but are instead written as
CMake language functions
Many (mostly those that don
Thank you very much.
Your remarks are very helpful to me to understand how it works.
I hope the following file is now correct:
==
project (example CXX)
set(CMAKE_VERBOSE_MAKEFILE ON)
include(ProcessorCount)
ProcessorCount(N)
if(NOT N EQUAL 0)
set(CMAKE_BUILD_FLAGS -j${N})
end
"5." is more work, but a good idea...
And since your recent activity on the mailing list rivals my own,
you'd never hear me calling you "an outsider". ;-)
I tend to think things like this (problems without an obvious, easy,
code-it-right-up solution...) should be slept on for a few
nights/weeks b
I hope you don't mind an outsider chipping in with a potential 5th
possibility:
5. parse the file to be configured to discover which variables will be
necessary for the configuration, and save only *their* values. For any but
the most insane configure_file() calls, that should be a tiny subset of
On 2015-04-23 06:47-0400 David Cole wrote:
Should it be configure_file(GENERATE or file(CONFIGURE_AND_GENERATE ??
The first (or configure_file_generate, see below) would be my preference.
In the meantime, while it is certainly clumsy to do the two separate
commands everywhere, you could writ
I don't understand what the error is here, but here are some comments:
(1)
CMAKE_INSTALL_PREFIX=$
The $ is unnecessary and incorrect in this context. The literal string
is the thing that ExternalProject will substitute when
it is processed into custom commands...
(2)
ONLY the DOWNLOAD_DIR param
There's also a fourth possibility:
4. Delay the configure processing for these "configure and generate"
files with the final variable values at the END of the configure (*at*
generate time).
Then there are no memory or temp file issues, but you have a mismatch
with the existing (and reasonably ex
Hello David,
I am using CMake 3.2.2.
I installed CMake from the sources because I use "modules" to manage my
libraries.
But it's ok now: I modified the installation so that to support https.
Unfortunately, I still have a problem. :(
Maybe you could help me!
Here is my CMakeLists.txt:
==
Should it be configure_file(GENERATE or file(CONFIGURE_AND_GENERATE ??
In the meantime, while it is certainly clumsy to do the two separate
commands everywhere, you could write a CMake language
function(configure_file_generate ...) that takes the same args as
configure_file, but does the two step
On 04/23/2015 12:13 PM, Alan W. Irwin wrote:
I think your idea of configure_file(GENERATE...) (where configure_file
occurs at configure-time without GENERATE to be backwards compatible,
but it occurs at generate-time if the new GENERATE signature is used)
is an excellent way to allow users to rep
On 2015-04-21 15:54-0400 David Cole wrote:
I can only imagine that would cause IMMENSE problems.
Good point about keeping backwards compatibility, but your shift key
got stuck. :-)
I depend on configure_file being an immediate action in many many many
places. (i.e. -- the very next line of
Hi,
i have a project in the path D:\folder1\folder2\prj1, all sources and
CMakeLists.txt are in this folder 'prj1'.
CMake generates for the Codeblocks project file in which the source
files are located in a virtual folders with the path not corresponding
to the root folder of the project 'prj1
39 matches
Mail list logo
