On Thu, Feb 23, 2012 at 10:33 PM, John Drescher wrote:
>> You probably want to do some type of file GLOBBING for that
>>
> Here is an example of file globbing (along with its pitfalls):
>
> http://www.cmake.org/pipermail/cmake/2010-September/039558.html
>
I am sorry. It does not look like the cod
> You probably want to do some type of file GLOBBING for that
>
Here is an example of file globbing (along with its pitfalls):
http://www.cmake.org/pipermail/cmake/2010-September/039558.html
--
John M. Drescher
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http:
On Thu, Feb 23, 2012 at 9:57 PM, Oliver Smith wrote:
> So it's late, and suddenly I find I can't remember how to configure cmake to
> compile any .xml file in a specific directory with an xml-to-header script
> we have. More importantly, I can't think of the right terms to find an
> answer, so I'v
So it's late, and suddenly I find I can't remember how to configure
cmake to compile any .xml file in a specific directory with an
xml-to-header script we have. More importantly, I can't think of the
right terms to find an answer, so I've spent a frustrating hour googling
to no end.
Is there
>>> On 23/02/2012 02:00, Jean-Christophe Fillion-Robin wrote:
Hi François,
Would the use of function be helpful ?
See http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:function
and http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:set
"If PARENT_SCOPE is present, the variab
On 2012-02-23 17:49-0500 Bill Hoffman wrote:
On 2/23/2012 5:18 PM, Alan W. Irwin wrote:
make commands. One is called MinGW/bin/mingw32-make.exe and is used
by the "MinGW Makefiles" generator while the other is called
MinGW/msys/1.0/bin/make.exe and is used by the "MSYS Makefiles"
generator. I
On Thu, Feb 23, 2012 at 6:19 PM, Yang, Jinzhong wrote:
> Hi All,
>
>
>
> I was trying to configure InsightApplications in CMake with USE_FLTK turned
> on, but I continuously got the error message:
>
>
>
> CMake Error at CMakeLists.txt:128 (INCLUDE):
>
> include called with wrong number of argument
On 2/23/2012 4:55 PM, Bill Hoffman wrote:
On 2/23/2012 6:20 AM, Andrea Crotti wrote:
So well I thought I could just use the MSYS Makefiles instead, but
reconfiguring and with the same target that doesn't work:
Scanning dependencies of target cleanup_system
process_begin: CreateProcess(NULL, /c
On 2/23/2012 3:50 PM, Alan W. Irwin wrote:
Both the "MSYS Makefiles" and "MinGW Makefiles" generators have worked
for me for a fairly recent version (20110802) of MinGW + MSYS
installed with the automatic installer. For the latter case I renamed
sh.exe to something else to keep sh.exe off the PA
On 2/23/2012 6:20 AM, Andrea Crotti wrote:
So well I thought I could just use the MSYS Makefiles instead, but
reconfiguring and with the same target that doesn't work:
Scanning dependencies of target cleanup_system
process_begin: CreateProcess(NULL, /c/python25/python.exe
h:/git_projs/PSI_Hambu
On 2/23/2012 3:02 PM, Bill Hoffman wrote:
On 2/23/2012 3:40 PM, Kenneth Boyd wrote:
On 2/23/2012 1:46 PM, Bill Hoffman wrote:
Right. Unfortunately, I have MingW installed from official tarballs,
rather than the MSYS executable installer; the MSYS installer *.exe
critically failed for me back
On 2/23/2012 5:18 PM, Alan W. Irwin wrote:
make commands. One is called MinGW/bin/mingw32-make.exe and is used
by the "MinGW Makefiles" generator while the other is called
MinGW/msys/1.0/bin/make.exe and is used by the "MSYS Makefiles"
generator. I presume those two executables correspond to va
On 2012-02-23 16:02-0500 Bill Hoffman wrote:
Seems to me there are
only two [MinGW/MSYS] cases regardless of how it was installed:
1. you have /bin/sh in your PATH and gmake runs commands via /bin/sh
2. you do not have /bin/sh in your PATH and gmake runs commands via the
native windows shell.
On 2012-02-23 14:40-0600 Kenneth Boyd wrote:
On 2/23/2012 1:46 PM, Bill Hoffman wrote:
gmake behaves differently if /bin/sh is in the PATH. The makefiles for
MinGW Makefiles are written for gmake running in the mode where it does not
have /bin/sh. The makefiles for Msys Makefiles are writ
On 2/23/2012 3:40 PM, Kenneth Boyd wrote:
On 2/23/2012 1:46 PM, Bill Hoffman wrote:
Right. Unfortunately, I have MingW installed from official tarballs,
rather than the MSYS executable installer; the MSYS installer *.exe
critically failed for me back in 2001, so once I got a working install
pr
On 2/23/2012 2:40 PM, Kenneth Boyd wrote:
On 2/23/2012 1:46 PM, Bill Hoffman wrote:
A patch that found different make.exe or make-mingw and then tested
them would not be rejected. I still don't see how we can avoid
having separate generators for MinGW and Msys, and I certainly don't
think a
On 2/23/2012 1:46 PM, Bill Hoffman wrote:
gmake behaves differently if /bin/sh is in the PATH. The makefiles
for MinGW Makefiles are written for gmake running in the mode where it
does not have /bin/sh. The makefiles for Msys Makefiles are written
so that they work with /bin/sh mode of gma
On Thu, Feb 23, 2012 at 2:46 PM, Bill Hoffman wrote:
> On 2/23/2012 2:12 PM, Kenneth Boyd wrote:
>>
>> On 2/23/2012 5:20 AM, Andrea Crotti wrote:
>>>
>>> I have MinGW installed in my system and today I added the bin
>>> directory to the path, so I was able to
>>> run all the commands also from a s
On 2/23/2012 2:12 PM, Kenneth Boyd wrote:
On 2/23/2012 5:20 AM, Andrea Crotti wrote:
I have MinGW installed in my system and today I added the bin
directory to the path, so I was able to
run all the commands also from a standard shell.
But now CMake complains:
CMake Error at c:/Program Files/C
On 2/23/2012 5:20 AM, Andrea Crotti wrote:
I have MinGW installed in my system and today I added the bin
directory to the path, so I was able to
run all the commands also from a standard shell.
But now CMake complains:
CMake Error at c:/Program Files/CMake
2.8/share/cmake-2.8/Modules/CMakeMi
On 2/23/2012 10:46 AM, elhadj meljane wrote:
Hi all
I am trying to cmake a CMakeLIsts.txt and I am getting the following error
CMake Error at CMakeLists.txt:50 (VTK_WRAP_PYTHON):
Unknown CMake command "VTK_WRAP_PYTHON"
here is the line that the cmake does not like in the CMakeLists file
VTK_W
On 02/23/2012 11:11 AM, Andrea Crotti wrote:
> On 02/23/2012 06:20 AM, Michael Hertling wrote:
>>
>> The point is that ${SCRIPT} is substituted in the Makefile by
>>
>> (1) a macro specified on the command line
>> (2) a macro specified in the Makefile
>> (3) an environment variable
>>
>> in that or
On 02/23/2012 04:52 PM, Michael Wild wrote:
On 02/23/2012 04:08 PM, Andrea Crotti wrote:
I really physically suffer using case-insensitive languages,
Seriously? You must be an annoyingly happy person if that's your biggest
problem in life! ;-)
It's a quite minor problem, but I think it's not
BuildSetup.cmake is called from the command line:
cmake.exe -G "Visual Studio 2008" -C BuildSetup.cmake -Wdev
-Original Message-
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of
Hashim Mir
Sent: February-23-12 11:52 AM
To: David Cole
Cc: cmake@cmake.org
Subject
On 02/23/2012 04:08 PM, Andrea Crotti wrote:
> I really physically suffer using case-insensitive languages,
Seriously? You must be an annoyingly happy person if that's your biggest
problem in life! ;-)
> but is
> there any convention to decide
> at least when to use upper and when to use a lower
Nope, I am not running it with -P.
My BuildSetup.cmake sets the flags that are passed in to the compiler
ex: set(CMAKE_CXX_FLAGS ...)
-Original Message-
From: David Cole [mailto:david.c...@kitware.com]
Sent: February-23-12 11:45 AM
To: Hashim Mir
Cc: John Drescher; cmake@cmake.org
Subje
On 02/23/2012 04:48 PM, John Drescher wrote:
Just to make you laugh I found the source of the problem.
Apparently if you try to run an installer from a directory which is on a
shared directory (with the virtualbox
sharing) it just won't run :D
Copying it somewhere else works perfectly, quite ama
> Just to make you laugh I found the source of the problem.
> Apparently if you try to run an installer from a directory which is on a
> shared directory (with the virtualbox
> sharing) it just won't run :D
>
> Copying it somewhere else works perfectly, quite amazing issue.
>
Thanks for reporting
On Thu, Feb 23, 2012 at 10:58 AM, Hashim Mir wrote:
> There is a PROJECT() at the top of my CMakeLists.txt file.
>
> However, I am trying to access the variable from within my BuildSetup.cmake
> file, so it is considered even before the CMakeLists.txt file.
>
> -Original Message-
> From:
On 02/23/2012 03:56 PM, Andrea Crotti wrote:
It appears it's really a problem of NSIS, even trying the a small
example (directly with makensis) from the website produces an
installer that doesn't work, I'll investigate in that direction then.
Just to make you laugh I found the source of
There is a PROJECT() at the top of my CMakeLists.txt file.
However, I am trying to access the variable from within my BuildSetup.cmake
file, so it is considered even before the CMakeLists.txt file.
-Original Message-
From: John Drescher [mailto:dresche...@gmail.com]
Sent: February-23-12
On 02/23/2012 02:32 PM, Andrea Crotti wrote:
So I'm still struggling to get an actual installer.
I copied almost the same example from the book:
cmake_minimum_required(VERSION 2.6)
project (Prova)
add_executable(prova a.c)
install(
TARGETS prova RUNTIME DESTINATION bin
)
include(CPack)
c
On Thu, Feb 23, 2012 at 10:39 AM, Hashim Mir wrote:
> Hi,
>
>
> I am trying to control the flow of my program based on the value of a cmake
> variable called CMAKE_SIZEOF_VOID_P.
>
>
>
> To start off, I wanted to just see what value this variable took under
> multiple different configurations, by
Hi all
I am trying to cmake a CMakeLIsts.txt and I am getting the following error
CMake Error at CMakeLists.txt:50 (VTK_WRAP_PYTHON):
Unknown CMake command "VTK_WRAP_PYTHON"
here is the line that the cmake does not like in the CMakeLists file
VTK_WRAP_PYTHON(cpptrackingPython PYTHON_SOURCES ${W
Hi,
I am trying to control the flow of my program based on the value of a cmake
variable called CMAKE_SIZEOF_VOID_P.
To start off, I wanted to just see what value this variable took under multiple
different configurations, by issuing the following command in my cmakelists.txt
file:
message(${
I really physically suffer using case-insensitive languages, but is
there any convention to decide
at least when to use upper and when to use a lower case?
For example user defined variables should be upper or lower case?
Or what happens if I hide by mistake a CMake-defined variable? (are they
Reading the documentation in add_custom_target I see this:
Dependencies listed with the DEPENDS
argument may reference files and outputs of custom commands created
with add_custom_command() in the same directory (CMakeLists.txt
file).
But this actually works just fine
add_custo
Is there a way to get some more information from "make help"?
I can already add a COMMENT to a custom target which will appear when I
build that target,
but it does not appear if I do make help..
Cheers,
Andrea
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://
So I'm still struggling to get an actual installer.
I copied almost the same example from the book:
cmake_minimum_required(VERSION 2.6)
project (Prova)
add_executable(prova a.c)
install(
TARGETS prova RUNTIME DESTINATION bin
)
include(CPack)
cmake does all its job, the package is created
I have this simple CMakeLists.txt:
add_custom_target(deptest ALL DEPENDS files.out)
add_custom_command(OUTPUT foo.x COMMAND touch foo.x DEPENDS foo.cpp)
add_custom_command(OUTPUT bar.x COMMAND false DEPENDS bar.cpp)
add_custom_command(OUTPUT files.out COMMAND touch files.out DEPENDS foo.x
bar.x)
I have MinGW installed in my system and today I added the bin directory
to the path, so I was able to
run all the commands also from a standard shell.
But now CMake complains:
CMake Error at c:/Program Files/CMake
2.8/share/cmake-2.8/Modules/CMakeMinGWFindMake.cmake:20 (MESSAGE):
sh.exe wa
On 02/23/2012 05:18 AM, Michael Hertling wrote:
There is a possibility to dynamically reconfigure/rebuild the project
without an intermediate manual step and in a way that you'll have one
target per egg, but that approach is disadvantageous in other regards
and possibly won't work with generator
On 02/23/2012 06:20 AM, Michael Hertling wrote:
The point is that ${SCRIPT} is substituted in the Makefile by
(1) a macro specified on the command line
(2) a macro specified in the Makefile
(3) an environment variable
in that order, or with (2) and (3) reversed if Make is invoked with the
"-e"
43 matches
Mail list logo