On Jun 27, 2011, at 10:26 PM, Hendrik Sattler wrote:
> Am Montag, 27. Juni 2011, 18:40:19 schrieb Todd Gamblin:
>>
>>
>> I *think* Michael's concern here is that if you have a project that uses
>> C99, it should fail as fast as possible, e.g. when it knows that the
>> detected/provided compiler
Am Montag, 27. Juni 2011, 18:40:19 schrieb Todd Gamblin:
> On Jun 26, 2011, at 7:12 AM, Owen Shepherd wrote:
> > On 25/06/2011 07:30, "Michael Hertling" wrote:
> >> On 06/24/2011 04:16 PM, Owen Shepherd wrote:
> >>> I think the appropriate solution here is a project-specific dialect
> >>> flag -
>
I've just spent several hours chasing down a problem that was related to
cmake makefiles not detecting a change in a header in /usr/local. I would
build a new version of a library, run 'make install' which would put it into
/usr/local, then rebuild my project. I mistakenly assumed that if one of
On 06/27/2011 02:39 PM, Raphael Münster wrote:
> enable_language (Fortran)
>
> set(CMAKE_Fortran_COMPILER "mpif90")
Set the compiler variable *before* enabling the language. The enable_language
command does a whole bunch of introspection of the compiler.
-Brad
__
If anyone is interessted, I think I found a solution:
git submodule update --init --recursive
Instead of both lines
Best Regards
Am 27.06.2011 um 19:56 schrieb NoRulez :
> Hi,
>
>
>
> currently I use the following to update git submodules during the ctest:
>
>
>
> if (EXISTS "${CTE
Hello,
I ran into some trouble trying to link a mixed language Fortran/C++
program.
I used a CMakeLists.txt that looks about like this:
# cmake version
cmake_minimum_required(VERSION 2.8)
# name of the project
PROJECT(Q2P1)
enable_language (Fortran)
set(CMAKE_Fortran_COMPILER "mpif90")
# a
On 6/27/2011 11:57 AM, Gabriel Petrovay wrote:
Hi Bill,
I have no exception. I only know that Cmake generates a wrong Include
attribute for a element (first in a series of cmake
generated filed). This generated file also does not have a .rule file
generated for it like for all the others in the
Hi,
currently I use the following to update git submodules during the ctest:
if (EXISTS "${CTEST_SOURCE_DIRECTORY}/.gitmodules")
execute_process (COMMAND ${GIT_EXECUTABLE} submodule init
WORKING_DIRECTORY ${CTEST_SOURCE_DIRECTORY})
# Update
Michael Hertling wrote:
> SET_SOURCE_FILES_PROPERTIES(${CMAKE_BINARY_DIR}/c89.c
> PROPERTIES COMPILE_FLAGS ${CMAKE_C_DIALECT_C89})
> SET_SOURCE_FILES_PROPERTIES(${CMAKE_BINARY_DIR}/c99.c
> PROPERTIES COMPILE_FLAGS ${CMAKE_C_DIALECT_C99})
> ADD_LIBRARY(c89 c89.c)
> ADD_LIBRARY(c99 c99.c)
>
On Jun 26, 2011, at 7:12 AM, Owen Shepherd wrote:
> On 25/06/2011 07:30, "Michael Hertling" wrote:
>
>> On 06/24/2011 04:16 PM, Owen Shepherd wrote:
>>> I think the appropriate solution here is a project-specific dialect
>>> flag -
>>> perhaps one taking options in the GNU format since it seems
On Jun 24, 2011, at 11:30 PM, Michael Hertling wrote:
> On 06/23/2011 06:20 PM, Jed Brown wrote:
>> On Thu, Jun 23, 2011 at 17:50, Michael Hertling wrote:
>>
>>> You need to use a C99 compiler for your project
>>
>>
>> This is already a problem. C99 introduces new keywords (e.g. restrict) and
The CMake 2.8.5 release candidate stream continues! You can find the
source and binaries here: http://www.cmake.org/files/v2.8/?C=M;O=D
I hope this will be the last release candidate for CMake 2.8.5. We'll build
and release 2.8.5 this week unless somebody reports a "must fix" major
regression from
For variables like CMAKE_C_FLAGS one can append to them like this:
set(CMAKE_C_FLAGS "${CMAKE_CFLAGS} -some_option")
For target properties like LINK_FLAGS I was using this command:
set_property(TARGET myDLL APPEND PROPERTY LINK_FLAGS
/NODEFAULTLIB:"LIBCMT")
to do the append. However, w
On 6/25/2011 11:40 AM, Gabriel Petrovay wrote:
(Using Cmake 2.8.4)
I think this was something I just fixed. There were some cases where
the rule files were not be created. If you could post a small example I
could take a look and see if it is fixed now.
Also, please try the most current
On 06/27/2011 12:00 PM, Maxime Lecourt wrote:
>
>
> 2011/6/27 Michael Wild mailto:them...@gmail.com>>
>
> On 06/27/2011 11:31 AM, Maxime Lecourt wrote:
> > Hello,
> >
> > I'm using CMake to build OCaml libraries.
> > For that, I use a macro that I call in my CMakeLists.txt
>
2011/6/27 Koecher, Rene :
> Hi,
>
Hi,
while making excessive use of the RPM generator in CMake 2.8.5 I came
across a requirement
it could not match out of the box: per-component spec headers.
As it is it seems not to be possible to add to or replace spec-file
headers o
Hi,
>>> Hi,
>>> while making excessive use of the RPM generator in CMake 2.8.5 I came
>>> across a requirement
>>> it could not match out of the box: per-component spec headers.
>>> As it is it seems not to be possible to add to or replace spec-file
>>> headers on a
>>> component basis. The Patch
On Mon, Jun 27, 2011 at 4:35 AM, Johan Knutzen wrote:
> Hey!
>
> Thank you for your reply. I tried unsetting
> CMAKE_XCODE_ATTRIBUTE_INSTALL_PATH
> but since it is not defined until the generator actually runs it does
> nothing. An interesting not is that if I do:
> set(CMAKE_XCODE_ATTRIBUTE_INSTA
[quoting repaired]
>> Hi,
>> while making excessive use of the RPM generator in CMake 2.8.5 I came
>> across a requirement
>> it could not match out of the box: per-component spec headers.
>> As it is it seems not to be possible to add to or replace spec-file
>> headers on a
>> component basis. Th
Small update - TMP_RPM_* fields need to be reset for different components or
they'll add up.
> Hi,
> while making excessive use of the RPM generator in CMake 2.8.5 I came across
> a requirement
> it could not match out of the box: per-component spec headers.
> As it is it seems not to be possibl
2011/6/27 Michael Wild
> On 06/27/2011 11:31 AM, Maxime Lecourt wrote:
> > Hello,
> >
> > I'm using CMake to build OCaml libraries.
> > For that, I use a macro that I call in my CMakeLists.txt
> >
> > As I have dependencies between my different libraries, I wrote my
> > CMakeLists.txt so the buil
Hi,
while making excessive use of the RPM generator in CMake 2.8.5 I came across a
requirement
it could not match out of the box: per-component spec headers.
As it is it seems not to be possible to add to or replace spec-file headers on a
component basis. The Patch below will add this support to C
On 06/27/2011 11:31 AM, Maxime Lecourt wrote:
> Hello,
>
> I'm using CMake to build OCaml libraries.
> For that, I use a macro that I call in my CMakeLists.txt
>
> As I have dependencies between my different libraries, I wrote my
> CMakeLists.txt so the build happens in the right order, but when
Hello,
I'm using CMake to build OCaml libraries.
For that, I use a macro that I call in my CMakeLists.txt
As I have dependencies between my different libraries, I wrote my
CMakeLists.txt so the build happens in the right order, but when building,
libraries are built depending on alphabetical orde
Hey!
Thank you for your reply. I tried unsetting CMAKE_XCODE_ATTRIBUTE_INSTALL_PATH
but since it is not defined until the generator actually runs it does nothing.
An interesting not is that if I do:
set(CMAKE_XCODE_ATTRIBUTE_INSTALL_PATH "test")
all INSTALL_PATH entries in xcode become test, so t
25 matches
Mail list logo
