On 23 April 2015 at 18:04, Nils Gladitz nilsglad...@gmail.com 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.
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,
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, next has been updated
via a0e83f77711e3f3f4d698099fba7cd7283474f18 (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, next has been updated
via bb64e2206a4455ea7d9be55f315187c87ad62fd7 (commit)
via
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
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
On 23 April 2015 at 17:20, Nils Gladitz nilsglad...@gmail.com 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
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.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
On 23 April 2015 at 16:57, Nils Gladitz nilsglad...@gmail.com 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
On 23 April 2015 at 17:50, Nils Gladitz nilsglad...@gmail.com 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
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
On 23 April 2015 at 20:58, Klaim - Joël Lamotte mjkl...@gmail.com 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
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=15530
==
Reported By:Bill Torpey
Assigned To:
20150423)
+set(CMake_VERSION_PATCH 20150424)
#set(CMake_VERSION_RC 1)
---
Summary of changes:
Source/CMakeVersion.cmake |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
hooks/post-receive
--
CMake
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
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 ebb54e02c4bfd9ef8ffb92a49afb873a0af58f2a (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 ad247d82b1fad2fe94ab3bf985a1685b04bfd67b (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 b03063b904648c960b91c63ef1f54b43977b8dc8 (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 9fd1f5494f3650cddf949335ed3cfdfe10e0f984 (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 46098b0676383590691137acd73defba848a318d (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 195a724c57bfe13f286525e0f8a7f2578768c77e (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, next has been updated
via ffb4ce1de59ae26253e504e292c568fa6b1134e3 (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, next has been updated
via 43d929112275e2edac4ab1cdcaa0c6012a8cc4bf (commit)
via
Should I rebased on a2d36e3?
The patch doesn't contain allot of changes so even if you don't the
merge will be trivial so it's up to you.
Regards,
Domen
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware
Le 22/04/15 23:46, Domen Vrankar a écrit :
Hi,
I just installed a virtual machine running Debian 7.8.0, and everything
worked like a charm from the first run. I did that in the two following way:
- sourced my branch
https://github.com/raffienficiaud/CMake/tree/cpack_deb_refactoring
- I also
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
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
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
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:
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
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
I don't understand what the error is here, but here are some comments:
(1)
CMAKE_INSTALL_PREFIX=$INSTALL_DIR
The $ is unnecessary and incorrect in this context. The literal string
INSTALL_DIR is the thing that ExternalProject will substitute when
it is processed into custom commands...
(2)
ONLY
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 need to
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
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
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
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
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.
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
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
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
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 cmake@cmake.org
À: typ1232 dummdoof-d...@web.de
Cc: cmake@cmake.org
Envoyé: Jeudi 23 Avril 2015
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 dlrd...@aol.com
À: Cedric Doucet cedric.dou...@inria.fr
Cc: cmake@cmake.org
Envoyé: Jeudi 23 Avril 2015
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
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})
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
Yes, I am really sorry for the noise! :-/
- Mail original -
De: David Cole dlrd...@aol.com
À: Cedric Doucet cedric.dou...@inria.fr
Cc: typ1232 dummdoof-d...@web.de, cmake@cmake.org
Envoyé: Jeudi 23 Avril 2015 13:58:27
Objet: Re: [CMake] Do build after GIT_TAG changed in
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 cedric.dou...@inria.fr 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
50 matches
Mail list logo
