Hi,
I'm trying to use cmake with the Cray Fortran compiler. The compiler is wrapped
through a script called ftn.
When I have the PrgEnv-pgi (pgi compiler) or the PrgEnv-gnu modules loaded, it
works with no issue.
But, when I have it set to PrgEnv-cray, it doesn't work.
I manually compiled th
Hi,
I'm trying to use cmake with the Cray Fortran compiler. The compiler is wrapped
through a script called ftn.
When I have the PrgEnv-pgi (pgi compiler) or the PrgEnv-gnu modules loaded, it
works with no issue.
But, when I have it set to PrgEnv-cray, it doesn't work.
I manually compiled th
2011/3/4 Laszlo Papp :
> On Fri, Mar 4, 2011 at 3:05 PM, Eric Noulard wrote:
>> 2011/3/4 Laszlo Papp :
>>> Hi,
>>>
>>> Can I create an rpm package with cpack in order to not deal with spec files
>>> ?
>>
>> Yes you can CPackRPM is meant to do that:
>> http://www.cmake.org/Wiki/CMake:CPackPackageG
On Friday, March 04, 2011 11:59:07 am kent williams wrote:
> To use Qt in my projects with CMake, up until now all it seemed to
> require was this:
>
> find_package(Qt4 REQUIRED)
> include(${QT_USE_FILE})
>
> But then I tried to use QTcpServer and QTcpSocket, and the compiles
> failed because it
> > Is there some reason that couldn't be a property as well? Or
possibly a
> > Policy?
>
> 2) why does ALL_BUILD need to be the default project
>
> - This one I can't answer. I don't understand why it even is the
default
> startup project anyhow. As such, it's useless. It seems to me
To use Qt in my projects with CMake, up until now all it seemed to
require was this:
find_package(Qt4 REQUIRED)
include(${QT_USE_FILE})
But then I tried to use QTcpServer and QTcpSocket, and the compiles
failed because it couldn't find the include files.
Then I read through the FindQt4.cmake fil
On Fri, Mar 4, 2011 at 12:25 PM, wrote:
> > It is (forced by backwards compatibility requirements) by design.
>
> >
>
> > Here is the source code where I wanted to assign it to the
> CMakePredefinedTargetsFolder:
>
> >
>
> > #if 0
>
> > // Can't activate this code because we want ALL_BUILD
> It is (forced by backwards compatibility requirements) by design.
>
> Here is the source code where I wanted to assign it to the
CMakePredefinedTargetsFolder:
>
> #if 0
> // Can't activate this code because we want ALL_BUILD
> // selected as the default "startup project" when
On Fri, Mar 4, 2011 at 12:09 PM, John Drescher wrote:
> On Fri, Mar 4, 2011 at 11:50 AM,
> wrote:
> > Hi All,
> >
> >
> >
> > I was just trying out the Target folders stuff in 2.8.4. The ALL_BUILD
> > target doesn’t seem to be affected by the PREDEFINED_TARGETS_FOLDER
> > property.
> >
> >
> >
On Fri, Mar 4, 2011 at 11:50 AM, wrote:
> Hi All,
>
>
>
> I was just trying out the Target folders stuff in 2.8.4. The ALL_BUILD
> target doesn’t seem to be affected by the PREDEFINED_TARGETS_FOLDER
> property.
>
>
>
> Is that by design or an oversight?
>
I see that here since I started using So
Hi All,
I was just trying out the Target folders stuff in 2.8.4. The ALL_BUILD
target doesn't seem to be affected by the PREDEFINED_TARGETS_FOLDER
property.
Is that by design or an oversight?
Aaron Meadows
Software Engineer
Thomson Reuters
Phone: 314.468.3530
Mobile: 636.541.6139
aar
Yeah I was aware of that, I forgot to state that on the comment for the
function. This was made on purpose since I don't want the pain of adding every
file to CMake and I certainly don't want CMake running automatically.
Thanks,
Pablo Zurita.
PS: the sourceFiles argument must be removed from th
Hi everyone,
Is there a better way to check whether the platform support symlink
than this one:
if(WIN32)
if(CYGWIN)
set(HAVE_SYMLINK TRUE)
else(CYGWIN)
set(HAVE_SYMLINK FALSE)
endif(CYGWIN)
else(WIN32)
set(HAVE_SYMLINK TRUE)
endif(WIN32)
Regards,
--
Nicolas Desprès
___
One other thing. You may try using the "NMake Makefiles" generator if you
must use the VS10 compiler: the dependencies definitely work via the
makefiles. I just tried it out...
On Fri, Mar 4, 2011 at 10:15 AM, David Cole wrote:
> Using:
>
> UPDATE_COMMAND ""
>
> is perfectly correct, and is w
Using:
UPDATE_COMMAND ""
is perfectly correct, and is working as intended.
You should see text like this in your output, which verifies that
UPDATE_COMMAND "" is working:
1> No update step for 'SAF-ext'
1> No patch step for 'SAF-ext'
However, this seems to be some sort of "Visual Studio 10"
Hi Alexey,
Usually there are 2 ways: 1) put them into separate directories (like Debug
and Release), probably specifying different output directories or 2) use
different file names, say adding suffixes like D, or d8.
BTW, what's the point to have different configurations in the same workspace
(d
2011/3/4 Alexey Livshits :
>> I am not a Visual Studio user so I may be missing your point here
>> but why having foo_1 and foo_2 ending up in the same workspace is a problem?
>>
>> As long as the lib/dll end up in separate dirs (using *_OUTPUT_DIRECTORY).
>
> Workspaces become too large, so I woul
> I am not a Visual Studio user so I may be missing your point here
> but why having foo_1 and foo_2 ending up in the same workspace is a problem?
>
> As long as the lib/dll end up in separate dirs (using *_OUTPUT_DIRECTORY).
Workspaces become too large, so I would like make'em smaller.
> Should
2011/3/4 Laszlo Papp :
> Hi,
>
> Can I create an rpm package with cpack in order to not deal with spec files ?
Yes you can CPackRPM is meant to do that:
http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#RPM_.28Unix_Only.29
The fastest path is to try:
$ cd /path/to/builddir
$ cpack -G RPM
>
Hi,
Can I create an rpm package with cpack in order to not deal with spec files ?
We did not need to put any debian/{changelog,rules,control} files
related implementation into the project so that to build a debian
package for arm with cpack.
https://projects.kde.org/projects/playground/games/gluo
2011/3/4 Alexey Livshits :
>> You can definition two different library target
>> and use OUTPUT_NAME property to adjust the name
>>
>> add_library(foo1 ${foo_source})
>> set_target_properties(foo1 PROPERTIES
>> OUTPUT_NAME foo)
>>
>> add_library(foo2 ${foo_sour
On 03/04/2011 01:56 PM, Orcun Gokbulut wrote:
> Hi everybody,
>
> I came across two problems when I was porting our project build system to
> cmake.
>
> The first program that I encounter is I can not compile generated source
> files with extension other than default c/c++ extensions.
>
>
> I h
> You can definition two different library target
> and use OUTPUT_NAME property to adjust the name
>
> add_library(foo1 ${foo_source})
> set_target_properties(foo1 PROPERTIES
> OUTPUT_NAME foo)
>
> add_library(foo2 ${foo_source})
> set_target_properties(foo2 P
On 04.03.11 14:56:14, Orcun Gokbulut wrote:
> While I was investigating the problem I came across another problem; I can
> not read default values of a source property. In more generic terms value of
> a source file property (I don't known whether this applies to
> target/directory/global propertie
Hi everybody,
I came across two problems when I was porting our project build system to
cmake.
The first program that I encounter is I can not compile generated source
files with extension other than default c/c++ extensions.
I have tried;
set_property (SOURCE ZEPortalMap.h.zpp PROPERTY LANGU
add_definitions( -DSTORE="XYZ" )
should do what you want.
If you have a cmake_minimum_required of at least version 2.6, then the
cmake_policy call is unnecessary -- it is simply implied by the minimum
required version of CMake for 2.6 and later.
What version of CMake are you using?
What OS and c
Dear All,
Sorry to repost but I am still stuck with this, would anyone have suggestions?
Anyone had the same experience with the UPDATE_COMMAND not working?
Thanks,
Yves
From: Yves Martelli
Sent: lunes, 21 de febrero de 2011 15:00
To: 'cmake@cmake.org'
Subject: EXTERNALPROJECT_ADD and AlwaysCreat
27 matches
Mail list logo
